
Why Python? - ryanwaggoner
http://www.linuxjournal.com/article/3882/#
======
Tycho
Fascinating statement:

 _Ugly programs are like ugly suspension bridges: they're much more liable to
collapse than pretty ones, because the way humans (especially engineer-humans)
perceive beauty is intimately related to our ability to process and understand
complexity. A language that makes it hard to write elegant code makes it hard
to write good code._

~~~
fnl
A bit wired but its really a fun read that many years later - although the
truth is, his reasons for the swap in the end were probably the same as mine
(although even later, because my team then wasn't using Python). And I still
think Python beats any other in syntactic beauty by simplicity. Although Lua
is a nice solution, too - I just don't like the end.

------
silentbicycle
I wonder how much of this is still true. Python was a very compact language a
decade ago (when I started using it), but gradually acquired bloat (perhaps
because people switching from Java demanded it - decorators* ? tuples AND
dicts AND lists?). I later switched to Lua, which on the whole is very
similar, but has constraints that have made it _stay_ compact.

* Seriously - downvoters, explain. What do decorators actually add that wouldn't come free with non-broken lambdas? I've tried to make sure I'm not missing something, but they seem like a gratuitous workaround.
    
    
        @dec
        def somefunc(x, y):
            blabla
    

vs.

    
    
        somefunc = dec(fun (x, y)
            blabla)

~~~
rwmj
Don't know about decorators. The real issues with Python that I find working
at Red Hat (unfortunately Python and Ruby are popular choices here):

\- generally poor choices for implementation: inefficient storage of values

\- 64 bit version approximately doubles the size of all data

\- interpreted, no code generator so it's very slow

\- lack of type safety is a constant source of bugs that just wouldn't appear
in other languages

\- whitespace layout screws up patches silently

Edit: don't downvote, comment on what I have to say.

~~~
viraptor
\- 64 bit issue is going to be the same for all languages. Twice the pointer
size, twice the data size (unless you're using a very specific type)

\- No code generators? You could complain that they're not good enough, don't
support some specific extensions, don't play nice with threading, or something
else, but there are many versions of python which work as compilers. Just
google a bit.

\- Lack of type safety is there by design. If you want type checking, why are
you even looking at duck-typed scripting languages? It's a basic design
decision, not something that could be changed / improved.

\- Why is whitespace even an issue in patches? If anyone submits a patch, they
should use exactly the same style as the rest of the file. If they don't,
patch should be rejected. The same thing happens in projects where indentation
doesn't really matter. Also, it's hard to "silently" screw up code covered by
tests. Any big enough project should have those...

~~~
rwmj
Thanks for replying.

The 64 bit issue is definitely not the "same for all languages". Programs get
slightly bigger, but don't double in size as happens for Python programs. Most
Linux 64 bit C programs will be using 32 bit 'int'. Python consumes 24 bytes
to store any single int on 64 bit.

Code generators: I mean ones which anyone uses.

Lack of type safety: it may well be "by design", but it's a dumb design which
causes lots of problems. Search Bugzilla for Python tracebacks and you'll see
hundreds of bugs caused by lack of basic compile-time type checks. It's _easy_
for a compiler to check that a function you're calling requires 3 arguments of
type foo, bar and baz, and not doing that simply causes lots of errors.

The whitespace issue is also real: if/else changes its meaning completely if
you're not hyper-careful about how you apply patches (especially when you have
to make manual fixes to patches to get them to apply).

~~~
jshen
I've been doing python and ruby full time for the past 8 years. In that time I
can count on one hand the number of bugs which got into production because of
a lack of static typing. The gain in productivity from using dynamic languages
in that time far far exceeds the cost of those few bugs.

~~~
rwmj
Well Red Hat have suffered from thousands and thousands of such bugs. Don't
believe me? Check for yourself:

[http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+...](http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+%22traceback%22+%22AttributeError%22)

[http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+...](http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+%22traceback%22+%22NameError%22)

[http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+...](http://www.google.co.uk/search?q=site%3Abugzilla.redhat.com+%22traceback%22+%22ValueError%22)

(There are many more searches of this type you can do).

~~~
jshen
There are a few conclusions that we can draw.

Red hat engineers suck (I know this isn't true)

I'm a genius (this isn't true either)

Different types of software have different needs and we shouldn't generalize
about all software development based on our particular niche. Writing code
that runs on other peoples systems is much harder than writing code that will
run on servers I control. Python and ruby are great for the latter. I've never
done the former at the scale of redhat. Writing code with a lot of
collaborators is harder than writing it with a few collaborators.

What language do you prefer for your type of work?

~~~
rwmj
OCaml

------
henning
Ah, vintage, pre-batshit crazy ESR. Not a single instance of referring to
anyone and everyone who disagrees with him as an "idiotarian."

------
alexyoung
"Perl still has its uses. For tiny projects (100 lines or fewer) that involve
a lot of text pattern matching, I am still more likely to tinker up a Perl-
regexp-based solution than to reach for Python."

I liked this comment because it sounds a bit like he was saying Perl was long
in the tooth. 10 years later, Perl still has its uses, and it's still used
commercially.

It's also possible to enjoy languages other than your One True Favourite-Ever
Language. I'm aware this might sound insane, but I'm going to leave this
Python script I'm writing to fix some bugs in a Ruby gem I'm working on, and
then go back to writing a daemon in Node JavaScript. Because they all have
their uses and you don't need to troll/defend your favourite at every
opportunity.

------
hartror
This is pretty much my experience of learning Python but I had had drastically
less coding experience than Eric Raymond did when he learnt.

------
Estragon
I came over here to say this article is about 10 years late, then noticed it
was written in 2000, so I guess it was a tiny bit ahead of its time.

With python so mainstream today, I am not sure what its contemporary interest
is, though.

------
Macsenour
As I struggle to figure out which language to use for my Facebook game... this
is not helping. :)

~~~
silentbicycle
Don't let the perfect be the enemy of the good.

The concerns of people designing programming languages are different from
people who want to write stuff _today_. Python is a reasonable choice.

------
bokchoi
In the year 2000.

