Last night I was talking with someone about the pros and cons of various programming languages and frameworks for data analysis. One of the pros of Python is its elegance. The primary con is that it can be slow.
The conversation reminded me of an apocryphal exchange between Winston Churchill and Bessie Braddock.
Braddock: Winston, you are drunk.
Churchill: Yes I am. And you, Bessie, are ugly. But I shall be sober in the morning, and you will still be ugly.
Python can be slow, though there are ways to improve its performance. But ugly code is just ugly, and there’s nothing you can do about it.
15 thoughts on “Winston Churchill, Bessie Braddock, and Python”
Elegance as defined as?
I ask because I don’t see it in python, at least in my definition of elegance.
Nick: I think elegance is maybe not the right word. That is, John is contrasting “elegant” code with “ugly” code. But I don’t think those are natural opposites in programming languages. For example, Lisp is often elegant and always ugly.
It may be clearer to say Python’s *syntax* is elegant, as opposed to the language itself (since the language is more than just syntax). But even better, I think it’s just better to say that Python code is cleaner and minimizes boilerplate. The syntax, along with community convention, discourages obfuscated code. Do you disagree with that?
Nick – But I do think that if you don’t see *any* elegance in Python even as a language, then (1) your definition of elegance is very odd, or (2) you haven’t looked very hard (or at all).
Nice analogy. I have the same feeling about Python although I didn’t have any performance issues with it so far. I also notice that people who criticize Python for being slow usually refer to CPython and ignore faster implementations such as PyPy.
That is why syntax is the most important part of a language, and syntactic elegance is the most important part of it. The rest is implementation details.
That’s why I hate comments that dismiss syntactic sugar. Syntactic sugar is everything,… in the long run.
Syntactic sugar can make things harder to read, e.g. sed.
Semantic elegance is important, too.
The lambda calculus is elegant. Lisp s-expressions are elegant. Python… not so much.
1.)beauty is in the eye of the beholder.
2.)practicality or FALSIFICATION Popper is important
3.)sure more elegance for semantics for HASKELL, but Python may
still be more practical – in my opinion.
my opinion is biased because I have MORE experience in PYTHON
4.)criticism – from quality statistics viewpoint – DRUNK is far worse due
to high variation of DEVIATION from standard. naturally and always
for example, English has plenty of ambiguities and strange idioms
5.)use the paradigm of STUCK CLOCK at one time. every 24 hours it
is HIGHLY PRECISE AND ACCURATE. IN general, it is ‘wrong.’
compare to clock with jitter and usually only about 1 – 2 minutes off.
ALWAYS WRONG, but generally within the plus/minute estimate.
6.)most language idioms and famous sayings tend to have flaws.
How about – Other syntaxes are ugly, but they evolve (and you can improve readability of your code), while Python will be as slow tomorrow.. ;)
It took me a while to stop chuckling before writing this comment: I had never before seen that quote (one of my favorites) used to describe code.
What I like about Python is its similarity to clay: You start with a messy lump, using your hands trying to craft it to match the vision in your head. As you get closer to the goal it hardens, allowing you to use tools with greater precision. When it’s done, it gets glazed and fired to make it pretty, durable and fast (Pypy, Psyco, etc.).
What amazes me again and again is how Python allows me to start with dynamic investigation/exploration in the lab (I write embedded communication, control and analysis systems), and once I start getting the desired behavior, my efforts shift to refactoring and improving efficiency and reliability. The resulting code soon becomes simple and elegant, despite starting out as a plate of spaghetti.
I’ve found no other language that permits me this degree of design debauchery, ease of evolution, and resulting robustness. (Though I do have great hopes for Julia, since Pypy can’t shed enough of its ancestral warts.)
With persistence (and surgery), even ugliness can be cured.
Aren’t we relying on Moors Law to keep giving us faster computers then though? Ok, so we can make a language like Python, Ruby, Lua, Lisp, etc, that is really elegant and clean, but runs more slowly, because we don’t really care if we waste a few percent of an ever increasing number of computer cycles. But logically, at some point we are going to hit a wall were we can’t just keep throwing more circuits at the problem, right? Or, we will hit a situation, such as mobile computing, where perhaps it isn’t a good idea to trade off computer cycles for elegance.
Has anyone tried to make a language that is less arcane then C, but still compiles in the same way, just has a nicer syntax for doing the same things? Like, gone over language X, found what parts of it confuse people into making mistakes and fixed those things? Have there been studies were people look at the cause of bugs and determined what caused them?
Canageek: We don’t have to wait for Moore’s Law to make Python faster. It has a variant, Cython, that is essentially Python with a little extra information that allows a compiler to turn it into C code. So once your code is debugged and profiled, you can convert the performance-critical parts to Cython.
Google’s Go langauge is sorta what you describe in your second paragraph. The new Julia language is also promising.
As for the cause of bugs, Code Complete quotes a lot of studies on probabilities of bugs under various circumstances.
Actually, Python has remained rather slow for a couple of decades now, and while there were/are many efforts to speed it up, none is mature enough to give us a faster Python out of the box.
Contrast that to C++ which was and is fast while getting increasingly less ugly (at least as judged by many; I think it’s an abomination and can only look superficially pretty until you start wondering what the program actually does, but that’s my opinion).
What I’m saying is that it’s not clear what’s more likely to happen in the morning – speed or beauty or neither; being slow is a rather more permanent condition to being drunk – perhaps sometimes it’s more like being an alcoholic… Certainly the very large amounts of Python code “addicted” to dynamic features that perhaps aren’t strictly necessary but are already there and are rather widely used make a more speedy Python much less likely.
Awesome example. I have the same sensation about Python although I did not have any performance problems with it so far. I also observe that individuals who criticize Python for being slowly usually consult CPython and neglect quicker implementations such as PyPy.
I do not think apocryphal statements of any speaker should be published. What is the point of quoting them? This statement shows Churchill being simply rude and, I would guess, entirely out of character.