Add to Technorati Favorites

Python: looks great, stays wet longer

Wet clayI should be coding, not blogging. But a friend noticed I hadn’t blogged in a month, so in lieu of emailing people, here are a couple of comments on programming in Python. There are many things that could be said, but I just want to make two points that I think aren’t so obvious.

1. Python looks great

In Python, indentation is used to delimit code blocks. I like that a lot – you would indent your code anyway, right? It reduces clutter. But apart from that, Python is very minimalistic in its syntax. There are rather few punctuation symbols used, and they’re used pretty consistently. As a result, Python code looks great on the page. It’s not painful to edit, and I mean that figuratively and literally. This is worth noting because when you write complex code it’s nice if the language you’re doing it in is very clean. That’s important because code can become hard to understand and unpleasant to work with. If you have pieces of code that you dread touching, that may be in part because the code is really ugly and complex on the page. Perl is a case in point – there’s tons of punctuation symbols, and in some cases the same thing (e.g., curly braces) is used in multiple (about 5!) different ways to mean different things. If the language is pleasant to look at for longer, you are more willing to work on code that might be more forbidding when expressed in other languages. Esthetics is important. Actively enjoying looking at code simply because the language is so clean is a great advantage—for you, and for the language.

This might not seem like a big point, but it’s important to me, it’s something I’ve never encountered before, and it’s a nice property of Python. BTW, people always make fun of Lisp for its parentheses. But Lisp is the cleanest language I know of in terms of simplicity on the page. The parens and using prefix operators in S-expressions removes the need for almost all other punctuation (and makes programmatically generating code an absolute breeze).

2. Python stays wet longer

I don’t like to do too much formal planning of code. I much prefer to sit down and try writing something to see how it fits. That means I’ll often go through several iterations of code design before I reach the point where I’m happy. Sometimes this is an inefficient way to do things, particularly when you’re working on something very complex that you don’t really have your head around when you start. But I still choose to do things this way because it’s fun.

Sometimes I think of it like pottery. You grab a lump of wet clay and slap it down on the wheel. Then you try out various ideas to shape whatever it is you’re trying to create. If it doesn’t work, you re-shape it—perhaps from scratch. This isn’t a very accurate analogy, but I do think it’s valid to say that preferring to work with real code in an attempt to understand how best to shape your ideas is a much more physical process than trying to spec everything out sans code. I find I can’t know if code to implement an idea or solve a problem is going to feel right unless I physically play with it in different forms.

For me, Python stays wet longer. I can re-shape my code really easily in Python. In other languages I’ve often found myself in a position where a re-design of some aspect involves lots of work. In Python the opposite has been true, and that’s a real pleasure. When you realize you should be doing things differently and it’s just a bit of quick editing to re-organize things, you notice. I might gradually be becoming a better programmer, but I mainly feel that in using Python I simply have better quality clay.


You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

12 Responses to “Python: looks great, stays wet longer”

  1. I thought your blog was dead: glad that it is not.

  2. I thought your blog was dead: glad that it is not.

  3. As they say, great minds think alike:

    “When you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.”

    The Python Paradox – Paul Graham, August 2004
    http://www.paulgraham.com/pypar.html

  4. As they say, great minds think alike:

    “When you program, you spend more time reading code than writing it. You push blobs of source code around the way a sculptor does blobs of clay. So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor.”

    The Python Paradox – Paul Graham, August 2004
    http://www.paulgraham.com/pypar.html

  5. That’s interesting. I read most of Paul Graham’s essays, but don’t remember that one. Or maybe I did read it, internalized it, and then forgot it – only to regurgitate it…

    Anyway, thanks!

  6. That’s interesting. I read most of Paul Graham’s essays, but don’t remember that one. Or maybe I did read it, internalized it, and then forgot it – only to regurgitate it…

    Anyway, thanks!

  7. In fact I did read that essay. So the clay analogy was already planted in my mind.

  8. In fact I did read that essay. So the clay analogy was already planted in my mind.

  9. Performance worried me, for a while, but then not so much.

    It is interesting that one of the arguments for the performance of Microsoft’s .Net is that developer productivity it more important than software performance, because it is cheaper to buy more hardware than it is to pay developers – but this isn’t an argument I particularly like, it just seems, I don’t know, lazy?

    Given that this is what Microsoft claims, it is telling that I managed to re-write one of my apps from C#, into Python with a 70% reduction in LOC and and less than half the time. Some of this I put down to familiarity with the problem domain, and I don’t doubt being new to Python it took me longer to write than it should have.

    End result, after 6 years with .Net (and plenty of Java time before that) my first port of call is now nearly always Python and not .Net. I am after all just taking Microsoft’s advice :)

  10. Performance worried me, for a while, but then not so much.

    It is interesting that one of the arguments for the performance of Microsoft’s .Net is that developer productivity it more important than software performance, because it is cheaper to buy more hardware than it is to pay developers – but this isn’t an argument I particularly like, it just seems, I don’t know, lazy?

    Given that this is what Microsoft claims, it is telling that I managed to re-write one of my apps from C#, into Python with a 70% reduction in LOC and and less than half the time. Some of this I put down to familiarity with the problem domain, and I don’t doubt being new to Python it took me longer to write than it should have.

    End result, after 6 years with .Net (and plenty of Java time before that) my first port of call is now nearly always Python and not .Net. I am after all just taking Microsoft’s advice :)

  11. I keep thinking about this. It’s definitely true for me as well. I’ve never used another language in which code came close to “staying wet” so long.

    Now I suspect that some of what I am (and you are?) attributing to python is actually the result of embracing a test-driven approach to development, but it’s still remarkable how easy it is to transmogrify quite large bits of python code months or even years after it was written.

    And I’m sure you’re right that appearance is connected somehow too. Python’s clean appearance somehow encourages clean code…and clean code is easier to understand, and often actually better, so easier to modify.

    A virtuous spiral indeed.

  12. I keep thinking about this. It’s definitely true for me as well. I’ve never used another language in which code came close to “staying wet” so long.

    Now I suspect that some of what I am (and you are?) attributing to python is actually the result of embracing a test-driven approach to development, but it’s still remarkable how easy it is to transmogrify quite large bits of python code months or even years after it was written.

    And I’m sure you’re right that appearance is connected somehow too. Python’s clean appearance somehow encourages clean code…and clean code is easier to understand, and often actually better, so easier to modify.

    A virtuous spiral indeed.