

Why python? - chunky1994
http://www.linuxjournal.com/article/3882

======
cypherpunks
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.

~~~
kahawe
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...

~~~
sesqu
Writing has historically been very important for recognition, especially
current writing.

------
ColinWright
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.

------
pavel_lishin
> So I dived into Programming Python with one question uppermost in my mind:
> what has this got that Perl does not?

Readability.

~~~
zygen
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.

~~~
zukhan
that.is.not.true.

~~~
prakashk
How so? Can you elaborate?

------
samuel
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.

~~~
Ixiaus
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.

~~~
samuel
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.

~~~
Ixiaus
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.

------
adaml_623
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.

------
sgt
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.

------
rjbond3rd
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.

~~~
rjbond3rd
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?

~~~
famousactress
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.

~~~
rjbond3rd
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>

~~~
famousactress
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.

~~~
rjbond3rd
That is certainly a fair opinion, although sometimes conventional wisdom is
wrong :)

------
dimmuborgir
This and PG's _Python Paradox_ have been discussed umpteen times on HN
already.

~~~
chunky1994
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)

~~~
mambodog
By the way, when you post an old article, the convention is to append the year
to the title, eg:

    
    
        Why Python? (2000)

~~~
chunky1994
Oh,I had no clue it was old before the first comment, but I'll be sure to keep
that in mind.

