

What Python Fixes - garret
http://paulgraham.com/pythonfix.html

======
RyanMcGreal
Python is like a piano: anyone can sit down and tap out Three Blind Mice
within a few minutes, but a virtuoso can play Rachmaninoff's Symphony No. 2.

The language is well designed; the barrier to entry is low; the language
allows for progressive discovery of its advanced features; it is powerful and
flexible enough to allow an arbitrary combination of imperative, object
oriented and functional programming; and the large, mature ecosystem of third
party libraries means it can already do about 80% of just about any problem
you can think to throw at it.

~~~
tumult
Piano is actually somewhat notorious for being excessively baroque and
difficult to play at the higher skill levels, the keyboard having been
originally designed to play only in a single key with a different tuning
system.

~~~
armandososa
I didn't know that and that sounds interesting to me. Can you elaborate? (I
know this is an article about Python, but I love pianos)

~~~
tumult
Sure. It's actually pretty interesting, and involves math.

<http://en.wikipedia.org/wiki/Just_intonation>
<http://en.wikipedia.org/wiki/Equal_temperament>
<http://en.wikipedia.org/wiki/Well_temperament>

Basically, when you play music aloud naturally with your voice or acoustic
instruments where you have complete control of the pitch, people tend towards
using whole numbers for representing harmony, like 3:2, since it sounds the
best. Unfortunately there are 12 notes in an octave in the Western music
system so you end up with bad ratios if you want to use instruments which are
tuned to play anything more than a single key. If you are in complete control
of your pitch, like with voice or violin or other stringed instruments, the
all of the players can adjust their intonation on the fly when the keys
change, and still keep the nice whole number ratios.

Enter church organs, which are huge, expensive, and can't be tuned while
they're being played. But they're very nice and impressive. So they were tuned
to play in only one key -- C. That's why the keys representing the scale of C
major on a keyboard are all white, and the other (less important) notes are
smaller black keys. You won't be pressing these very often, better to get them
out of the way.

Then along came some math people who calculated tables of compromises that
ended up giving a pretty decent sound to harmonies, but was laid out in a way
so that you could play different keys without having to adjust your tuning or
intonation. There were different systems, but they were referred to as having
temperament. Hence the name "Well-Tempered Clavier" in the famous composition
for keyboard instruments, which made ample use of the newfound ability to
change keys whenever one pleases.

So now there are a bunch of keyboard players who can suddenly play in any key
they want with the new tuning systems. But the keyboard layout is still same
one used for playing only in C. That all happened hundreds of years ago, but
we're still stuck with the original layout for keyboards.

~~~
armandososa
Wow! That's fascinating. I'd lke to see more music related posts 'round here

~~~
RyanMcGreal
This was posted to HN a month and a half ago:

<http://news.ycombinator.com/item?id=1283523>

------
parfe
Python is not static

Python is not monkey-patched

Python is not multiple coding styles

Python is not enterprise

Python is not overly verbose

Python is not overly concise

Python is not lacking in libraries

Python is not a dialect

Python is not manual memory management

Python is not hard to learn

Python is not a roadblock to writing code quickly

And really the only important issue: Python is not a pain to use.

~~~
stcredzero
Not all of these things are 100% true, but those that aren't are _true enough_
to make Python less painful to use than a lot of the alternatives.

Python is not multiple coding styles - not entirely true, but probably true
enough.

Python is not monkey-patched - again not entirely true, but maybe true enough.

Python is not overly concise - mostly true, though I've seen abuses of array
slicing and passing/storing/calling functions.

Python is not overly verbose - pretty much at the mercy of whoever is writing
code, but again, seems to be true enough.

Python seems to be pretty good or good enough in a lot of ways, and deserves
credit for this. The far-sighted view will recognize it as a local maxima,
however.

(A "perfect" language is like a perfect predator. A tireless, scentless,
invisible, silent, indestructible, ultra-fast killing machine would probably
wreck its environment. Considered in the context of evolutionary change, it's
practically impossible for such a thing to come about.)

~~~
parfe
I agree completely. Python isn't perfect but, for me, it solves the issues I
listed. I don't like Java and Perl can be the Pit of Despair. I don't have to
worry about 4.days working depending on if I loaded a library that loaded
another library that properly patched the integer class and the Scheme/Lisp
(perceived by me) clusterfuck of libraries, reader macros, slight
incompatibilities etc is just non-existent.

I would drop python in an instant of a better language came along. For me, the
question isn't what it fixes, but what it succeeds at. It makes my
professional life less painful and that's really the only reason I need.

edit: Also would like to not that the original article seemed fairly
pointless. It's not really saying anything of substance.

------
jacobian
Python fixes maintenance.

You know that sinking feeling when you crack open 3-year-old code written by
your predecessor's predecessor and realize it's a load of garbage and that
you'll never be able to fix the bug?

Yeah, well, with Python that doesn't happen. At least, not at all frequently.

Python forces you to spend a bit more time up-front and then saves you time
each and every time you need to read, edit, or improve your code. People
choose Python for the same reasons they choose good testing practices.
Python's a mature language for mature developers who want to produce mature
software.

~~~
bad_user
> _well, with Python that doesn't happen. At least, not at all frequently._

That's a bold statement. It happened to me just last week.

The difference from Perl is that common tasks are standardized ... stuff like
OOP is built-in, so you don't have to chose or stay in touch with several
frameworks for doing OOP, and you could care less about integration issues
between modules that use different OOP systems.

It also has a clean syntax, which makes (good code, written by good
developers) readable ... but that's not what bugs me about Perl ... after all,
why should you read text in some language (natural or not) if you haven't
bothered to learn it?

That's about it. Otherwise I'm beginning to hate Python's limitations.

~~~
jacobian
_> > well, with Python that doesn't happen. At least, not at all frequently._

 _> That's a bold statement. It happened to me just last week._

Look, different strokes for different folks: I'm not trying to suggest that
_you_ should use Python; I'm explaining why _I_ do.

That said, anecdote ≠ data. Your cited experience doesn't match up with what
I've seen in a decade as a Python developer, and, more importantly, it doesn't
match up with the data I've seen [1] suggesting that Python code takes 1/2 to
1/4 as much time to maintain as other comparable languages.

When I choose Python, it's because I know that the vast majority of my time is
spent maintaining code (mine and other people's), not writing new code. I
choose Python because, of all the languages I've tried in my career, it's the
one that makes this task easiest.

[1] To forestal the obvious questions: no none of this data is publicly
available (at least to my knowledge). I can share some rough details --
contact me privately if you want them -- but you'll pretty much have to either
believe that I'm reliable or decide that I'm full of shit. I don't much care
either way -- again, this is about my choices, not evangelism.

~~~
xenomachina
>>> well, with Python that doesn't happen. At least, not at all frequently.

>> That's a bold statement. It happened to me just last week.

>Look, different strokes for different folks: I'm not trying to suggest that
you should use Python; I'm explaining why I do.

You made a pretty definitive assertion, and when someone points out that they
had an experience to the contrary you say "different strokes for different
folks"? Seriously?

I like Python a lot. I've been using it for about 12 years now. My experience
doesn't really line up with yours.

I've found that Python is _great_ for writing small (<2000 loc) programs.
However, every single time I've seen a large project written in Python it's
ended up collapsing under its own weight.

I'm sure I'll get flamed for saying this, but I think part of the problem is
Python's dynamic nature. Python is the dynamic language I have the most
experience with, so perhaps I'm over-generalizing, but the problem I've seen
with large Python projects is that they get to a point where a major
refactoring is needed and it's impossible to pull it off because of the
dynamic nature of the language. Perhaps with 100% test coverage things would
be easier, but in the real world that's rare/nonexistent. (Also, I find that
more tests are necessary in Python than in a static language because you end
up having to test a lot of the same things your static language would have
been proving for you.) In the bigger Python projects I've seen they eventually
rewrote the whole system in a static language.

------
iainduncan
For me, Python is the only language that addresses the _human_ side of
programming well. You just plain make fewer mistakes with Python, and it's way
easier to reload code into your brain after not looking at it for a while. The
readability and obvious syntax has vastly more far reaching effects than one
thinks it will when first learning it. It's amazing how much more productive
one is in a language that is easy to read, easy to type, and easy to figure
out what the most likely way to do something is. I reach for pdb more than a
manual because most of the time I can guess what an api will be, and if not, 5
seconds of introspection reveals it. Ruby is well designed for computers, but
Python is better designed for us fallible humans who have to type into
computers. ;-)

~~~
iainduncan
Further to this, as fallible humans, we usually get the design wrong on the
first try. The truly multi-paradigm nature of python has for me made it a
really great language for refactoring and iteratively arriving on a good
design. You can write proto-types really fast, and turn them into more formal
architectures very smoothly.

------
j_baker
I think that Python "fixes" reliance on language features. Sure, Python has a
lot of neat features compared to say C# or Java, but as a dynamic language it
really isn't anything _that_ great.

But Python is probably the best example in recent history of a language that
made it big not because it was anything radically new or innovative, but
because it has a great standard library and a solid, mature implementation.

~~~
samps
Agreed. In many ways, Python is the most "boring" of the modern dynamic
languages, in the sense that it trades exciting features and hip syntax for
predictability and elegance. So it gets a lot of the productivity,
conciseness, and power of other dynamic languages without nearly as much
cognitive dissonance for people familiar with C or Java.

------
samratjp
Obligatory: <http://norvig.com/python-lisp.html>

Python to me is the new world where any immigrant has a niche for whatever he
seeks.

------
jayruy
SciPy+NumPy+MatplotLib == Matlab ($2k+) returns true for most applications

That's good enough for me to not bother with any other scripting language.

~~~
wwortiz
Sadly matlab still is much easier to use and understand for engineers, which
is one of its, if not the, primary market(s).

~~~
levesque
I agree that numpy python programming is nowhere near matlab for ease of use.

I prefer using python for machine learning tho. I dislike the libraries
written in matlab.

Is numpy+python faster than matlab?

~~~
wwortiz
To be honest I have no reason to conclude that one is faster than the other
but I would hope that given its age and girth matlab is more optimized.

The main reason I say matlab is better for engineers is that its documentation
is beyond amazing, if you think of something you need you search in the help
browser and there is a good chance it is there with substantial information
(something that is much harder with the math/science python libraries) also if
you know a functions name you just type: help function and get plenty of
information which helps when you forget how to use something and need a quick
lookup.

I have done some things with scipy but nothing more than solving some odes and
I must say even with all the pains of matlab with writing separate files to
solve odes and other such things plus some syntax grievances it is still the
easiest solution for me.

~~~
masterj
Since both (I assume) are calling the same BLAS and LAPACK libraries
underneath the scripting niceness, it's likely they're very similar in speed.

~~~
hugh3
Of course it depends what you're trying to do. I'm pretty sure that
numpy/scipy have a lot more overhead than Matlab for everything that _isn't_
just a blas/lapack call, but I don't have the numbers to back it up.

I do know that I tried rewriting one of my C++ codes using scipy/numpy and it
was about a hundred times slower for that particular task (which did happen to
involve very large matrices, approaching the limits of memory).

~~~
infinite8s
From experience that kind of slowdown for pure numeric algorithms happens when
your numpy/scipy code is structured in a way that it makes extra unnecessary
copies.

------
tumult
Python is a Lisp where the interface to everything is a domain-specific
language that visually resembles simple imperative programming.

If Python has fixed anything, it has been because of its roots as a teaching
language, with a culture for treating the structure of the language as a tool.
Blur the lines between syntax and semantics, and your only option is to create
things that can be expressed in both realms at the same time.

~~~
Xurinos
_Python is a Lisp_ \- I do not understand this. Howso?

~~~
tumult
Garbage collection, syntax modification, runtime code evaluation.

~~~
jpr
> syntax modification

Hmm, have I missed something? What features are you talking about?

~~~
tumult
I guess you do not know very much about Python.

~~~
chromatic
Do you mean decorators? How about metaclasses?

------
mkramlich
Simple things are simple. Hard things are doable and still easy to read and
maintain. Concise but not so much that it looks like line noise later. An
application often has about as many characters as the pseudo-code used when
designing it. The language syntax is so minimal and flexible that, unlike
Ruby, you do not want to create a true DSL but rather plain old modules,
functions and classes in order that you keep the readability & extensibility
high by having a common language syntax.

~~~
zephyrfalcon
Hmm. Python isn't a really big language, but it isn't as small as it used to
be, not by far, and it never was as small or minimalistic as e.g. Scheme or
Io.

------
Kilimanjaro
Python could be improved a bit, just remove the damn underscore from it.

Everything else is love.

------
jpr
To me as a Lisp user, Python breaks more than it fixes. Lexical scoping? Nope,
can't have it. Code as data, data as code? Not really. Literals for data?
Compilation to native code? Compiler/interpreter warnings? Warnings for name
collisions when importing? Standard for the language? Nope.

And I don't really buy the argument that Python is simple and clean. It has
multiple inheritance, metaclasses, operator overloading, decorators and
whatnot. Also the type system is broken, a deriving class can define an
overriding method that has incompatible signature, rendering isinstance
powerless (yes, I know you probably shouldn't use isinstance much anyway, but
dammit, it should at least mean something).

~~~
stcredzero
_And I don't really buy the argument that Python is simple and clean._

Yes, but consider the competition. Python is a significant margin above
average, but this says as much about the sorry state of computer languages in
general as it says about Python.

Heck, English is considered an "easy to learn" language among human languages,
and _it's a mess!_

Really the problem is with human beings.

~~~
queensnake
(More specifically, English is said to be "easy to learn, hard to master"
(because as you say, it's a mess).)

------
hackermom
Wholeheartedly without trolling, but admittedly with some bitterness, and with
much experience in Python, Perl, PHP, Java, C/++ and more, another thing that
Python will fix for you is the problem of having a too fast processor on your
deployment platform: Python effectively eliminates this problem in most cases,
way better than most other languages will. There's always another side of
every coin, and it shouldn't ever be ignored.

~~~
j_baker
Bear in mind that this is only applicable if your code is very CPU-bound. If
it's IO-bound as many applications are these days, then this is for all
intents and purposes a non-issue.

~~~
swolchok
This is a non-statement -- if the code is IO-bound, then of _course_ CPU
performance is not a problem (except for things like, say, power usage, but
we'll ignore that). The "power" of Python is to make code that should be IO-
bound CPU-bound.

Speaking as someone who loves Python and uses it all the time, but has spent a
lot of time learning to love Cython in recent months. A nice feature of Cython
(psychologically speaking, at least) that is missing in Python is the power to
say that dammit, certain constants are _constant_ , will never be changed, and
can be inlined instead of having a hash table lookup every single time.

~~~
j_baker
I think it's more accurate to say that it's a truism. Unfortunately, it's one
that a lot of people forget.

