Okay, monkeys, this one’s for you.
I often hear the phrase “beautiful code,” but I’m not entirely sure I’ve ever known quite what beautiful means in that context. I’ve seen some beautiful results, is that what beautiful code means? Some might argue that code is simply a means to an end, like a blueprint or structure to get a desired result. (So architecture counts as art but the steps involved [like the blueprint, or the pouring of the foundation] are not.) Others say that the creativity and problem solving involved in getting those lines of text to order your hardware and software to get along and perform exactly the way you want them to is obviously an art.
Perhaps this is part of why it’s so hard to figure out where to start when you realize that you’d like to learn that foreign language called code. (Pick a language, any language! You can do it! WAIT NOT THAT ONE O SWEET JEEBUS)
So what do you think? What is beautiful code? Is it the stuff that works properly, that looks “pretty” in the environment, that is well-commented and plays well with others? Does it have to solve a particularly interesting problem, eliminate a given quantity of alternate lines, utilize a certain number of libraries? Is it the ideas and concepts behind the code, rather than the text itself? Is it enough that the code is not necessarily beautiful but that it creates something beautiful? Do you have any idea what I’m talking about? And finally, can code be considered art?
The ART Inquisition (or AI) is a question posed to you, the Mad Art Lab community. It used to appear on Mondays, Wednesdays, and Fridays at 3pm ET… maybe we’ll just try for Wednesdays this go ’round. Make with the comments!
Monkey here, acknowledging the call.
In short, code is beautiful when it is clear. Beautiful code exposes the underlying pattern that make it work. Beautiful code doesn’t look like it’s doing something other than what it’s doing.
Some people prefer to focus on code that is crisp, that fulfills its task with an absolute minimum of work (however they might be measuring it). But sometimes this winds up championing code that is unintuitive or surprising. Such code may be valuable or instructive, but I prefer not to call that beautiful.
The eternal struggle of writing code is that there are two different audiences for code: the computer and the human beings. The former is necessarily the one that takes precedence: if your code doesn’t do what it needs to do, then it’s not useful. But working code that is incomprehensible is almost worse. It misleads and misinforms those who read it, but because it gets the job done, it sticks around, thus extending the lifetime of its cancerous side effects. The best code of all speaks plainly to both audiences, accomplishing the job with a minimum of extraneous effort, while clearly describing what it does and how to the human beings who seek to learn from it.
Agreed with breadbox – to me beautiful code exposes the underlying patterns. In many cases that means explicitly *not* making it as concise or minimal as possible since that’s often done at the expense of clarity and/or extensibility. I would call this beauty in the Zen sense.
However, I think we can make something beautiful by doing the exact opposite of that – things like this http://www.ioccc.org/1998/bas1.c (from the The International Obfuscated C Code Contest). What does it do? Something about making a maze (I’ll take their word for it). It’s most certainly not Zen, but it’s definitely art (and I happen to find it beautiful).
I’m also gonna jump on the Breadbox band-wagon.
For me, beautiful code reveals itself to you right away. And its cleverness is obvious and not obscured. Unlike some, I don’t find the ‘obsessively terse Perl’ trope fascinating at all**. Yay. You really really mastered regular expressions… good for you… but
print((($line=join(“”,))=~s/.*\n/index($`,$&)>=$[?””:$&/ge&&$line));
is not beautiful, it’s a monstrosity. It is not elegant, it is opaque and its meaning obfuscated. I think this is why I agree with McGrath that John Carmack’s code is beautiful. It is elegant and reads well and imparts its intent to you easily. Yes… Carmack is obsessive and I understand is on the Aspergers spectrum, but it’s hard to refute that what he’s done is art.
I’ve only wrote one thing in my life that I consider beautiful – everything else I consider ‘hacky’ in one way or another – and I knew it was beautiful when I was done. I think every programmer could learn to make their code more beautiful, but no one teaches that… they teach efficiency, which is a different (albeit related) thing.
Like a lot of art, it’s really about stripping something down to its core without losing the essence of the thing. That’s where the genius of someone like Carmack really shows through. When someone can put code in front of you and say “What is this? and you immediately respond “It’s a parser.” Followed by “… and it’s very clever. Beautiful, even. Look what he’s done here!”
But, of course, most of us end up doing this job -> “Oh, and comment the hell out of this so that PersonX can take it over. OK?” “OK…”
Maggie
** – But I agree with Carl that the IOCCC is art, even so. Not ‘beautiful’, to me, but art.
Haha, don’t get me wrong. I ADORE the IOCCC, and I have definitely uttered “That’s beautiful” upon seeing certain IOCCC winners. (And some winners ought to be required reading for C programmers.) But never never never would I refer to them as “beautiful code”, as that term has a specific connotation, which an IOCCC winner must necessarily avoid at all costs.
Part of the problem is that things (including code) can be appreciated in lots of different ways. And we want to use the word “beautiful” to describe things we appreciate. I too appreciate IOCCC as art, and therefore, in that specific context, I can describe them as “beautiful”. That same “beautiful” IOCCC entry in the workplace is an abomination, however. As with all creative expression, context is paramount.
Maggie, the Perl snippet you posted is an interesting example. It’s a filter that removes blank lines from the input, but it took me forever to figure that out. For one thing, it’s testing for blank lines in a completely roundabout and obfuscated fashion, to the point that I am forced to admire the cleverness involved in hiding its true purpose. And it joins the individual lines together, only to separate them out again via a global regex? I love it. Again, if I found this in an professional context, I would be horrified. But anyone who could write that code knows Perl pretty well, certainly enough to know that
while(<>){print unless /$^/}
does the same thing, is easy to read, and is shorter to boot. The fact that they didn’t clearly establishes the context (to me, anyway) as intentionally obfuscated. And as intentionally obfuscated Perl code goes, it’s pretty damn hilarious.
Indeed there are many characteristics we can call “beautiful”. One I particularly appreciate is solving a problem in a creative, elegant way. For example, recursion is a very natural way of thinking about problems, but we run into a little problem when we apply that approach to computers: For large problems we can run out of space on the stack. Enter tail recursion, such an elegant way of solving it. It’s just beautiful. Here’s a much more detailed explanation using the functional paradigm and an object-oriented piece for even more clarity of what is going on.
Also (tangentially) relevant: beautiful comments.
😀
Maggie, I disagree with the first sentence of your second paragraph. It takes me a while (sometimes) to recognize beautiful code, but ugly code reveals itself right away. I have to understand code to consider it beautiful, and sometimes that isn’t instant. Lots of code is stodgy but straightforward, not actively ugly, but not beautiful either. Beautiful code has to be elegant, not clever for the sake of cleverness, and concise, but no more concise than it needs to be to be understandable, and at least a little surprising. (I think I’ve just redefined “beautiful” in three different ways, without explaining it at all, but you know what I mean…)
When Maggie said, “beautiful code reveals itself to you right away”, I took that to mean that the code’s purpose and methods reveal themselves right away. Not that the code reveals itself as beautiful right away. So I don’t think the two of you are actually in disagreement.
To me, at least, saying that code is beautiful could mean various things. It could be that the algorithm that the code describes is beautiful, probably because it has a sort of elegant simplicity that not only efficiently solves the problem it is supposed to solve, but does so in a way that changes the reader’s perspective on the problem (this is very close to what I would think of as beauty in math or fundamental physics). Or, it may be that the algorithm is fairly straightforward, but the code uses the constructs of the language in a surprising or elegant way to instantiate the algorithm. I don’t think my code tends to be very beautiful, but one instance where I feel I came close was in this latter sense. I was programming Matlab (not a language that lends itself to beauty) and was trying to manipulate large matices in a particular way that seemed to require writing a loop (something Matlab does not do well and which makes it slow down considerably). It wasn’t obvious to me at first, but eventually I realized I could reconceptualize the algorithm I was using as a set of linear operations, converting the loop into matrix multiplication (something Matlab does very well). It was a few years ago, but I still feel pretty proud of that code.
I definitely think it’s very subjective, though. For me, I find examples of deliberate code obfuscation to be funny, enjoyable, and even artistic, but not especially beautiful (and I wouldn’t ever want to see it out in the “real world”!), but I think I can understand why others might.