> A few years later one of the newer employees on the customer support team started spouting off about "python" and how it was so easy to learn. He was always blabbing about terms I'd never heard of like "generators", "list comprehensions", "decorators", etc. I looked them up and learned they were just abstract constructs with fancy names that are supported in most any language. So I just figured he was some idiot that didn't really know anything. Otherwise, why would you be blabbing about abstract constructs?
> I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious.
Not to speak for the OP, but I'm pretty sure that was the point -- he was making fun of himself, especially when he noted that the guy quickly moved on to Google and he himself later started working in Javascript!
With my friend that left for google, I was annoyed at him somehow thinking python was advanced just because he was using stuff you could do in any language only he thought more highly of it because of the names. He saw the light of having a clean syntax, I did not, but now I do.
If you look at the history of python, it is an "engineered" language. It was based off of ABC which was a product of a large team of engineers in the early 1980's. Also some of Modula-3 as well. ABC was based off of ALGOL 68 and Pascal. The point is, a lot of money flowed into the design of these languages and python borrowed largely off of that base.
I used to know perl's history quite well, but I'm fuzzy on that now (and stopped caring). I know Larry was quite skilled at whipping up compilers and parsers from scratch, and he was heavily involved in linguistics, but I feel he sort of just did his own thing. The reason to make perl6 in the first place was to make a "proper" language. All of the lexer and parser code in perl5 are purely custom and intertwined. There's no way to change the parser or add an AST without just starting from scratch. That is what perl6 tried to do. But with python, these steps were from the beginning in proper "layers" and that helped the language to evolve with the times better as well as just having a cleaner VM source code which was easier to work on (the trade off being it was slower than perl in many cases).
The end result is python is "syntax with training wheels", you can't deviate too far before it fails to compile. While perl will compile just about anything as long as your semi-colons aren't missing. For me that made python harder to learn. You couldn't just write anything and expect it to work. For me, I looked at the python docs a lot more than perl docs when learning it. There's no reason why you can't do while y = t.pop: ... in python other than it won't let you. That was something that made me put it off for a long time as it felt it was just full of more rules than syntax. I see the light now though. But the point of my rant here is not that python is beautiful code (which I've always found as an annoying "advantage"), but that the perl community it self if just out of touch with what the current market wants (and needs). And that was the point about the 50 year old perl dev I was making. You can certainly code like it is 1995, but it is not what most people want to pay for (and it certainly is not something we need more of).
> All of the lexer and parser code in perl5 are purely custom and intertwined.
I had given myself a torture by taking a look at perl5/toke.c [1]. Among dozens of lexical analyzers I've ever seen, it is the only tokenizer that uses a probablistic estimator to determine the extent of the current token (grep for the comment "this is terrifying, and it works"). Perl 5 is my go-to language for counterexamples in programming language grammers and syntaxes.
Oh and I forgot to also say when comparing the languages, you have to also look at the authors too. Guido from the get go was more of a "software engineer" type whereas Larry seemed to be more involved in sysadmin and/or systems programming. I think the languages show that as well.
Pythons "there is only way" is too stiff for me. It may sound nice but in reality does not work, on top of my head - package managers, slots, itertools vs array comprehension, discouraged lambda, and whole python 2 or 3.
A sample of Google Python code I've tried to fix recently [1]. A ton of nothingness. You can produce it in any language.
You are too harsh on Perl design. I thought ruby was popular because it is great language. Nope. Cool kids moved to server side JavaScript. And tried to hide prototype oriented origins, they've added class friends privates now and a ton of other questionable features.
It is all about version 5 dead. I've red Perl 6 Apocalypses, I'd ship. Too bad there was no smooth transition path.
> I can understand how a 50 year old perl dev (the typical age) would hate javascript and instead put as much code in the back end using all kinds of horrid html templates and never ending form post/refresh/repopulate cycles... I can see the "why should I learn javascript if i know perl" ideology, but what blew me away is a constant "why should I learn SQL if I know perl" ideology. Yes I'm serious.
You don't see how this is the same thing?