I'm not sure if I trust much be ESR. He's extremely eloquent, so what he writes always sounds convincing. In practice, he's a pretty bad developer, or at least he was at the time he wrote most of his stuff (at the time, the most serious technical accomplishment he had under his belt was a refactoring of fetchmail). When I've applied the things he's written, more often than not, they've lead me astray. He has, more often than not, messed up in contexts involving technical interaction with other people (e.g. CML2). This is in stark contrast to e.g. RMS, who usually puts people off, but whose writing tends to be dead-on correct (if you don't believe me, read almost anything he wrote 10-30 years ago, and see how it panned out -- the guy's almost a prophet, cursed to know the truth but not be able to convince people). So I take everything ESR writes with a very large, maybe unhealthy degree of skepticism. It's too easy to be convinced of something incorrect (many eyes make bugs shallow, negative attitude towards RMS, etc.).
I'm looking at his page now, and he appears to have written or contributed to more software since, so I'm not sure if this still applies. I suspect it does, but I'm not ready to pass judgment until I read his more recent essays.
I never understood where his "claim to fame" really came from? Apart from publishing and then maintaining a pre-existing dictionary on his website, publishing one of MANY books on Open Source and cursing admins with fetchmail, he hardly contributed to or founded any REALLY big projects or coded a lot like Linus or RMS did or did anything of real substance - but esr was always one of THOSE names during his heyday and he would go to great lengths telling everyone how "the community" selected him to be some sort of open source Keanu Reeves/Neo...
He's an exceptionally good communicator and has very strong soft skills, and applies them to self-promotion. He's also good at politics (as in convincing crowds of people -- not so much at interacting and making long-term connections with individuals). A lot of this has to do with feeling out crowds, and telling them what they want to hear. He's also got a slightly underdeveloped moral compass, which always helps (he was willing to be a little bit sleazy and subtly undermine competitors). That's mostly what it takes to get famous. He was also the only person, after RMS, who was arrogant enough to take credit for the whole movement.
Perl is perfectly readable, and in many cases elegant. The creator is even a trained linguist. Sure it's possible to write unreadable perl, just like it's possible to make a mess in any language, but I'd say perl is as readable in general as python.
I started to use Python not much after this article(2002?), and I wonder how much of those days' simplicity holds true. "Modern Python" is full of list comprehensions, generators and decorators. Not that's intrinsically bad, but it's not "executable pseudocode" anymore. Books as "Collective Intelligence" require you to know Python intricacies in order to understand it.
You really think Python is losing its simplicity? List comprehensions are much easier to read than a multi-line for loop (obviously, though, nesting list comprehensions is A Bad Thing for readability) - they are much simpler. Generators don't add simplicity!? Do you even know why you would use a generator, why does this run:
for i in xrange(1, 10000000000000): print i
and this doesn't:
for i in range(1, 10000000000000): print i
To make the range() example run, you have to use generative behavior anyway, in some form or another. Generators are a simple way of expressing that kind of algorithmic behavior.
(for the record, this little example is being ran on a machine with 2GB of ram)
I know that is a very silly use case for generators, particularly when range() is going to become xrange() anyways - but it is a perfect example of why generative behavior can make things simpler. The trade off is memory vs computation - range() builds the whole list then iterates over it; xrange() generates the next item in the list; use normal list construction when the list is knowably going to be small, use generative behavior when the list is going to be big!
Decorators make the language less simple????? A decorator gives you the ability to modify a function/class at runtime. Decorators have made my python code (where they are useful) much much simpler!! Decorators have given me another dimension to follow DRY with!! Decorators do make the implementation more complex but they make the code you write simpler - the trade off is very clear and the cons are almost non-existent.
If you think decorators are cool, try picking up Common Lisp or Scheme - Macros will rock your socks off.
I do understand and use that features. My point it's that they aren't obvious. One of Python strengths was that any programmer could look at it and know what was going on, and, for newbies, it was much easier to learn.
I'm among the few unimpressed by list comprehensions. I use them because they're "idiomatic", but I'm equally comfortable with good old map(), which, I admit, it may be equally foreign for imperative-only programmers.
About the xrange() example, IIRC the iterator protocol predates generators, and probably is easier to grasp since the state is handled explicitely.
Decorators, as Lisp macros, are powerful but, if not handled with care, the source of very subtle bugs, because the thing you're looking at(the decorated function) doesn't do what it seems to do.
Anyway I'm not arguing against this artifacts, just pointing that, some of the merits of Python that were true a decade ago, aren't anymore.
Simplicity doesn't always make something more learnable or more readable. Scheme (R5RS) is a good example of a minimalist language that isn't necessarily easy to read when compared with Python's readability; same is said about its "learnability".
I nitpicked those features because while I would agree list comprehensions aren't as readable/learnable to a new user, they do make the language simpler in that it increases the expressiveness of the language for a common pattern. To each his own, I like both list comprehensions and map() - not sure if I really take a side on either one...
My example of xrange() in arguing for generators was a bad one because you're right, it is an iterator. I still feel like generators increase the expressivity of the language and therefore make it "simpler" - but again I will agree with you that new users will find it less readable and less learnable (to begin with though!).
Decorators I will completely agree, are new user unfriendly and are a complex language feature - I suppose I was arguing for reduced program complexity rather than language simplicity in the context of the decorator addition.
I doubt people will argue that these features are useful, but they do increase Python's overall complexity by adding to the sum total one must learn to grok python.
There's a danger here: add too many "simplifications" and you get something complex.
I can agree with that (add too many simplifications...); that's why I've really fell for data-as-code in Scheme; the simplifications in that language are so broad that you don't have to /add/ simplifications. Whereas, with Python's (or any language that isn't homoiconic) "baked" syntax, you do have to add "simplifications" or "features".
> I started to use Python not much after this article(2002?), and I wonder how much of those days' simplicity holds true.
I started learning Python in 2003, I was really a programming newby, by I managed to get my first full-time programming job just 2 years later because Python made it that easy for a neophyte to get from 0 experience to getting paid to write code. List comprehensions are cool, and not that hard to grasp, but I agree, I sort of started losing track once people started using "generator that" or "decorator this" for every damn problem you threw at them.
That's hardly surprising, Minimalistic tools haven't been able to survive for a long time.
Problems change, programmers needs change. What was not necessary yesterday, might be very important today. You will have no option but to keep adding on things as they are needed.
I started out with vi, then found out I was better off using emacs. Its rather better to use something designed to be big from the scratch, than to be using some thing invented to be minimal but bloated later just to compete with others.
I thought initially that an article this old would be full of historical and probably obsolete information.
But I've realised that the second half of it is actually quiet interesting and worth a read for people who are thinking about the strengths and weaknesses of different programming languages.
It sounds like ESR was writing that old-fashioned single-script non-OO stuff, relying on big nested data structures which were indeed often messy and confusing. OO changed all that.
One example of ESR's Perl code isn't even that interesting. It's just a monolithic script full of the global variables, repetition, useless busy work, and inconsistencies you'd expect from someone who didn't know the language very well:
It's slightly better than what you'd have downloaded from any one of hundreds of "FREE PERL SCRIPT" sites in the late '90s, if only because ESR understood Unix better than most.
Well no wonder he expressed frustration. That would be unwieldy in any language. No disrespect to esr (obviously) because that was a million years ago in Internet time.
Do people really disagree that huge, non-OO scripts were the dominant style back in the 1990's? Or that people tried to solve problems with huge data structures instead of classes? And that these practices gave Perl a less than stellar reputation?
Or is it that people don't realize that Perl apps are virtually always written in clean, well-factored OO these days?
My guess is that it just came off as unnecessarily (and unproductively) defensive, as it amounts to the argument that it's not impossible to write clean applications in Perl. Perl's problem has never been that it's impossible to write 'clean, well-factored' programs.
Thank you! I appreciate that you took the time to explain.
ESR is apparently saying (true at the time) that Perl can be hard to maintain. But by "Perl," I speculate that he was talking about coding in monolithic non-OO scripts which would be a drag in any language.
So his criticism of the language was fair in the 1990's, but only for that style of procedural coding.
I tried to look at his source, but his own links to his Perl stuff are broken:
So, yeah.. you can write hard-to-maintain code in any language, but I think many (including myself) would argue that it's much easier to do in Perl than many other languages. It's built into Perl ('more-than-one-way'), and explicitly avoided in python wherever possible. Bottom line: all things being equal, I'd argue you're more likely to end up with a Python codebase that's a pleasure to maintain than a Perl one.
I was not one of the downvoters, but I was not surprised to see the downvotes. I can't figure out in what way that comment added to the discussion. "I am assuming he was Doing It Wrong" with no additional commentary on what this affects or the implications therein. Regardless of the truth of the comment, it just doesn't seem to be a very useful one.
No, not doing it wrong -- he was almost certainly doing it in the predominant style of the language in the 1990's, which was procedural / scripty, e.g., hashes of references to arrays of references etc. Pre-OO.
And his remarks are certainly fair for the time period, but isn't it also fair to note that this style of coding is not practiced anymore? I think so but I'm interested in any viewpoint.
Sure, it is fair to note, and I think it's actually a pretty good point now that you've clarified it a bit. (I speak as someone who's currently using Python at work but Perl for my own things.)
However, it's a manner of how you present the comment. As you originally stated it, it pretty much sounded like "He's Doing It Wrong", which didn't add very much to the discussion. In my opinion, a much better way to go about it would have been something closer to "I think it's worth contextualising his comments. It is likely that the style in which was coding was more in line with earlier styles that are not used as often in 2011. While Perl is obviously still Perl, more recent styles do help alleviate some of his concerns."
Now, this clearly still isn't a perfect comment, but it, or something more like it, would serve both to clarify your position and to allow for discussion based on it, if people were up for such discussions.
But, again, I feel the need to reiterate that I was not one of the people who downvoted you, so I'm only guessing as to the most likely reason for the downvotes.
> Do people really disagree that huge, non-OO scripts were the dominant style back in the 1990's?
I don't know python, but "OO changed all that" implies that data-centric approaches are somehow passé, to which I'd reply "yeah, but FP changed all that". Maybe they are in Python though.
I'm sorry, I just found it interesting. Some of the new members may not have seen it, so I guess it might just bring about some fresh opinions.
(And completely unrelated, if this is improper etiquette please forgive me, but I see you like Dimmu Borgir! Pretty cool)
I'm looking at his page now, and he appears to have written or contributed to more software since, so I'm not sure if this still applies. I suspect it does, but I'm not ready to pass judgment until I read his more recent essays.