This is part 6 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.

This week we look at the question of creativity in programming.

Last week I talked about how the linguistics baked into Perl allow for maximum programmer creativity. But of course all that discussion contains a hidden premise: that allowing for programmer creativity is something desireable. But is it really? Maybe programmer creativity isn’t that great an idea.



Certainly the folks who created and advocate Python seem to believe that. In the book Learning Python there is a sidebar which addresses the question of how Python compares to Perl. This section is entitled “Python Is Engineering, Not Art.” 1 On the question of programmer creativity, it has this to say:

But as anyone who has done any substantial code maintenance should be able to attest, freedom of expression is great for art, but lousy for engineering. In engineering, we need a minimal feature set and predictability. In engineering, freedom of expression can lead to maintenance nightmares. As more than one Perl user has confided to me, the result of too much freedom is often code that is much easier to rewrite from scratch than to modify. This is clearly less than ideal.



Well, there certainly is a lot to chew on there. Let’s set aside the self-selection bias entirely (i.e., that the group of people both experienced in Perl and most likely to be talking to a Python trainer are probably those who have failed at being Perl developers and are looking for a more suitable language); it’s obvious and not worth more than noting. Let’s look a bit deeper and see if Mr. Lutz (the author of the book) perhaps has a point after all.

The first bit I have a problem with is his overly generic use of the term “engineering.” Once upon a time we were programmers, and proud of it. Nowadays it seems we need fancier titles, and thus we have become software engineers. 2 But there are some radical differences between the field of engineering and the field of computer science. For instance, a rigorous proof of correctness is often achieved in mechanical engineering; in computer science, there is still a lot of debate about whether this is even possible. 3 Engineers (at least the ones that I’ve known 4 ) get to approach their problems logically, deconstruct them completely, then reassemble them with rigor, according to structured rules. There’s nothing wrong with solving problems like this. It’s an awesome thing that engineers do, and it’s a very cool way to earn a living.

But it’s not what we do as programmers.

As programmers, we begin with nothing, as a writer begins with a blank page. Oh, sure—we know where we need to end up: those are the specs, the description that the user has given us of what our program needs to do. Sometimes a writer knows how the story must end as well; even if they don’t, they know the general shape of it, at least have some idea of where it’s going. Just like the writer, we create: from nothingness, towards a vaguely defined goal which may very well change many times along the way, with an infinite number of different ways to get there, some short, some long, some elegant, some messy, and there will be pangs of birth, and there will be revisions, and other people will give us their opinions and sometimes they will be right and sometimes they will be about as wrong as it’s possible to be, and there will be blind alleys, and backtracking, and sudden epiphanies of A Better Way, and finally we will present our finished work, proud, knowing it could be better, wishing we could fix just one more thing, tweak just one more bit of code, but knowing that we must deliver it, the business needs it, the users need it, or perhaps we need it, if we’ve written it for ourselves, and we must let it go, for others to enjoy, for others to critique, for others to simply use in a utilitarian way, but it will always be our baby, even if it’s a little bit ugly, oh, sure, we know we could have done better, and we look forward to the opportunity to do better next time, but, butt-ugly or gorgeously elegant, intricately sophisticated or plainly functional, it’s ours, and there’s a little piece of us on the page, or on the screen, or in the bytes, and anyone who knows us will always be able to see us in there if they look closely. That’s what we do as programmers, and it’s messy and it’s glorious and it’s hard as hell and satisfying as all get out, but it ain’t engineering.

I’ve known programmers who approach writing code like engineers approach designing a piece of machinery, of course. They’ve been some of the worst programmers I’ve worked with. They lack flexibility, and they don’t make intuitive leaps, and you have to explain things to them in a very detailed way that tends to be frustrating and time-consuming. Again, there’s nothing wrong with this approach, when applied to a problem that warrants it; I’m sure there are even some programming problems that warrant it ... scientific analysis programs, perhaps, or tricky, high-level academic algorithms, or ... I dunno, there must be something. But I’ve never done that sort of programming. The programming I’ve done has always required creativity: you must be able to start with almost nothing—perhaps just a computer language and some tools like a particular database—and you must be able to see how to code your way to the finish line. Now, there are some mathemeticians and engineers who are creative in this way, definitely, 5 and of course there are always going to be those super-geniuses who are good at both approaches, but most of us mere mortals are good at one or the other. I’d make a lousy engineer. I don’t have the patience for all that rigor, and I hate rules. But programming ... I’m good at that.

So perhaps it is true that freedom of expression is lousy for engineering (although I think many of my engineer friends would beg to differ), but that’s utterly irrelevant. Because programming requires creativity. Programming requires freedom of expression. Freedom of expression is crucial to communication. And communication is what it’s all about. Here’s what our Python-lauding author has to say next:

Consider this: when people create a painting or a sculpture, they do so largely for themselves; the prospect of someone else changing their work later doesn’t enter into it. This is a critical difference between art and engineering. When people write software, they are not writing it for themselves. In fact, they are not even writing primarily for the computer. Rather, good programmers know that code is written for the next human being who has to read it in order to maintain or reuse it. If that person cannot understand the code, it’s all but useless in a realistic development scenario. In other words, programming is not about being clever and obscure—it’s about how clearly your program communicates its purpose.



Besides displaying an abysmal ignorance of artists, 6 the problem with this passage is that it wants to have it both ways. It says that code should be simple—simplistic, even—so that anyone can understand it. If we were to apply this logic to the English language, for instance, it would be saying that everything you write should be on the level of Dick and Jane. Well, okay: I suppose we can make an argument that, when you write for the lowest common denominator, you do increase the chances of other people understanding what you meant. And, yet, human communication doesn’t use that level, neither in common speech nor in common writing. You don’t write your emails like that, do you? I’m not writing this blog post in that fashion. About the only things we have today that actually do use that level of communication are (some) instruction manuals, and do you find those easy to understand? Hell, even the books that teach our children how to read don’t sound like that any more, thanks to that visionary Dr. Suess, who Wikipedia tells us wrote stories which were “often characterized by imaginative characters, rhyme, and frequent use of anapestic meter.” In other words, they were creative. So our Python devotee here quite rightly identifies that, when we write programs, we should be writing for other humans, but then he doesn’t want us to communicate in the way we commonly communicate with other humans. I’ve puzzled and puzzed till my puzzler is sore, but I can’t make any sense of it.

But surely he has a point when he says that a programmer has to think of something that no other artist does: that, one day, another programmer will likely have to come along and modify their program. Writers and painters and sculptors don’t have to worry about that; their work is typically done alone. Even musicians and filmmakers, who often have to engage in a much more collaborative process than their fellow artists, still don’t have to worry about their work being changed later: once the vinyl is pressed or the film is printed, the work is done. Someone might do a remake one day, perhaps, but that’s nothing to do with the artists in the here and now. Programmers are unique in this aspect, are they not?

Well, almost unique. We could compare programmers to architects, who often have to marry the aesthetically pleasing with the functional, and who definitely have to think about making it easy for the plumbers to get to the pipes when they rust, or the electricians to get to the wires in the walls when the mice chew on them. 7 Architects have to be creative, but also approach their projects with a logcial plan, just as we programmers do. But, even without this analogy, if programmers are just like artists in every way except that they have to think about other people maintaining their work, does that necessarily preclude them from being artists? Every artform is different, after all. This is just one of the ways our artform diverges from drama or literature or dance.

There’s only two other bits of this piece that I’ll comment on. 8 The first is this sentence:

Because Python’s syntax model almost forces the creation of readable code, Python programs lend themselves more directly to the full software development cycle. 9



Now, why would you want to brag about how your language limits expressivity? Since “readable code” is by definition a subjective measurement, what this statement really means is that Python forces you to write code that someone (Python’s creator, I suppose) considers more readable than other code, whether you like it or not, whether it’s appropriate for that situation or not, whether it fits the paradigm you need at the moment or not, no matter what. You’re gonna write like we say so. ‘Cause we said so. Get used to it.

Here’s the last one:

Python programmers can be wildly creative, too, of course, and as we’ll see, the language does offer multiple solutions for some tasks—sometimes even more than it should today, an issue we’ll confront head-on on this book too.



Can they, I wonder? Can Python programmers really be wildly creative? Perhaps. Although note the implicit disapproval of such shenanigans after the dash. Apparently wild creativity is something to be on the lookout for. Be sure and throttle any such behavior, should you come across it.

Now, my experience is not exhaustive. I’ve not worked in every kind of industry, nor on every type of program, nor in every possible language. But I’ve spent over 25 years (about 45%) of my life programming. I’ve been the grunt coder at the bottom, I’ve been the manager in the middle, and I’ve been the man at the top. 10 I’ve worked on banking software, voting software, insurance software, advertising software, and web software. I’ve written code from scratch, rewritten code to match older software bug-for-bug, and maintained large codebases of up to two million lines of code, stretching back as far as a decade before I got there. I’ve worked for businesses, for individuals, for the government, and once for a political campaign. And my experience is that I’ve never found a programming problem that didn’t require at least a little bit of creativity to solve, and I’ve never worked with a good programmer who wasn’t a least a bit creative. Maybe your experience is different. Maybe Python is the right language for you. (Although I suspect it isn’t, else you wouldn’t be here ... and that’s our self-selection bias rearing its ugly head.) Or maybe what I’m saying rings true.

Also, I hate doing what other people say. So that’s probably a big part of it too.

Next week, I’ll ponder whether creativity is something that ought to be stressed more when people are taught computer science, and how little I know about how compilers are put together.



