Constricted by Python

I've been doing a lot of work in Python of late. There's a lot to like about it. List comprehensions were a bit odd to work with at first, but they have certainly grown on me. Nice baked-in laziness capabilities. However, there's something essential about Python that bars it from ever becoming my tool of choice. I have several characteristics in common with Larry Wall, among them a love of linguistics. And just as that influenced his development of the Perl language, it impacts how I view other programming languages. I think of programming languages as I do spoken and written languages, as means of expression. The structure of a language lays the groundwork for what it can express, or at the very least it dictates the length to which one must go to express something.

Now I'm a poet, at heart if not in practice. And my favorite form of poetry is haiku. Part of what I like about it is the syllabic constraint, which makes it particularly tricky to get your point across. But when done right, it packs an awful lot of meaning into a very small space, in a fashion that prose could never match. In order to make it work however, you have to bend the rules of grammar a little, maybe make some unusual word choices, and you must nearly always leave behind such poetic niceties as alliteration or rhyme. You must make extensive use of your poetic license to accomplish your goal, and the language you work in may or may not cooperate with you in your quest. English is an unusually good language for poetry because of its amalgamated nature, leaving a plethora of literary weapons in your arsenal, ranging from terse Anglo-Saxon hammers to graceful Romance rapiers.

Going back to programming languages, I feel like good programs often have elements of the poetic in them. Instead of just prosaic recitations of the steps to be taken, there are often metaphors and similes, abstractions that both accomplish the stated goal in elegant fashion and infuse extra meaning into the code for the illumination of the reader and/or maintainer. And, like English, some programming languages give you a diverse set of building blocks, and let you take care of the rest, while some languages are more geared to guide you rather hamhandedly into a certain mode of expression.

Which brings us to Python. You must return values explicitly from your functions. You must use consistent whitespace. Assignments don't return values. The end goal of these design choices is largely admirable. We want people to write good code. I'd probably say that it is fairly effective in that regard, and that the average quality of code written in Python is perhaps the highest of any language I've dealt with. However, I don't judge a language just by how the average coder writes in that language, but by how the best coders write in that language. And being one of the best coders I know, I have to say that Python's authoritarian approach to discipline has stymied my efforts many times to write code that is both effective and appealing to work with. Python quite often forces me to create variables or named functions which are very soon either thrown away or passed off to another scope. The lambda syntax is so clunky and limited that it makes nearly no sense for it to even exist in Python. Perl or Ruby on the other hand give you plenty of ways to string things together to get the right answer, and it's up to you to use good judgment as to which of them is the best. Most programmers will choose poorly, but I won't accept that as a reason that choice should be taken out of my hands. Just as I don't let others' inability to use English properly or well affect my desire to keep taking advantage of all the possibilities that using English affords me.

The best language is, I would say, one that gets out of the way of the coder and lets them create something that ultimately reflects their own qualities. I don't want bad coders creating slightly less odious code because the language just would not let them. I would much rather the stench of their vomitous coding atrocities rise to the heavens, that all may gaze in horror and learn to hold tight to their children and walk briskly in the other direction whenever they see such a thing occurring. Best that bad coders learn that they just aren't cut out for the job than be led into a false sense of security by a language that won't allow them to indulge their incompetent inclinations.

Those equipped for the task of codesmithing on the other hand should be free to practice their art. They should be well aware of the guiding principles that a language like Python tries to enforce, and they will more often than not employ them. But they may find situations that the principles just don't adequately handle. Or they may discern even better formulations and applications of these principles that no language designer could ever envision.

So I'm happy to make use of Python where the task calls for it, particularly on projects where it is already in use. But I don't think it will ever be a default choice for me. I just feel like it doesn't give me enough room to breathe.

Trackback URL for this post:

http://www.tigretigre.com/trackback/26