Why python?(linuxjournal.com)
linuxjournal.com
Why python?
http://www.linuxjournal.com/article/3882
41 comments
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...
Writing has historically been very important for recognition, especially current writing.
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.
An old friend. Previous discussions:
http://news.ycombinator.com/item?id=1822376
http://news.ycombinator.com/item?id=297683
Lots of comments on each. Before commenting here it might be worth reading those earlier discussions.
http://news.ycombinator.com/item?id=1822376
http://news.ycombinator.com/item?id=297683
Lots of comments on each. Before commenting here it might be worth reading those earlier discussions.
> So I dived into Programming Python with one question uppermost in my mind: what has this got that Perl does not?
Readability.
Readability.
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 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.
for i in xrange(1, 10000000000000): print i
for i in range(1, 10000000000000): print i
(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.
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 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.
(though list comprehensions really are awesome!)
There's a danger here: add too many "simplifications" and you get something complex.
(though list comprehensions really are awesome!)
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 find list comprehensions to be far more natural and more readable than the equivalent for loop.
> 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.
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.
Python is just undergoing the natural trend.
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.
Python is just undergoing the natural trend.
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.
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.
An 11 year old article... Great.
I still have the issue of Linux Journal with this article in it, lying around somewhere. That was ESR's heyday.
I still have the issue of Linux Journal with this article in it, lying around somewhere. That was ESR's heyday.
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:
http://www.ibiblio.org/pub/linux/search/keeper-1.54.tar.gz
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.
http://www.ibiblio.org/pub/linux/search/keeper-1.54.tar.gz
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.
Ah, great, I was not able to find that.
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.
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.
Downvotes are not informative.
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?
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:
http://www.catb.org/~esr/intercal/software.html
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:
http://www.catb.org/~esr/intercal/software.html
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.
That is certainly a fair opinion, although sometimes conventional wisdom is wrong :)
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.
Hi masterzora,
Thank you for clarifying. I appreciate it.
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.
Thank you for clarifying. I appreciate it.
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.
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.
Aha, okay I totally get that. Thank you.
> 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 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 meant only to say that gigantic (untestable) scripts are passé at least for the language in question.
[deleted]
This and PG's Python Paradox have been discussed umpteen times on HN already.
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)
By the way, when you post an old article, the convention is to append the year to the title, eg:
Why Python? (2000)Oh,I had no clue it was old before the first comment, but I'll be sure to keep that in mind.
You're the first hacker I've come across on HN who likes Dimmu(apart from me) :D
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.