Slashdot Mirror
Code Is Not Literature
An anonymous reader writes "Hacker and author Peter Seibel has done a lot of work to adopt one of the most widely-accepted practices toward becoming a better programmer: reading high quality code. He's set up code-reading groups and interviewed other programmers to see what code they read. But he's come to learn that the overwhelming majority of programmers don't practice what they preach. Why? He says, 'We don't read code, we decode it. We examine it. A piece of code is not literature; it is a specimen.' He relates an anecdote from Donald Knuth about figuring out a Fortran compiler, and indeed, it reads more like a 'scientific investigation' than the process we refer to as 'reading.' Seibel is now changing his code-reading group to account for this: 'So instead of trying to pick out a piece of code and reading it and then discussing it like a bunch of Comp Lit. grad students, I think a better model is for one of us to play the role of a 19th century naturalist returning from a trip to some exotic island to present to the local scientific society a discussion of the crazy beetles they found.'"
...works much better as a model. Performing music is analogous to executing code.
Code is very similar to language. How would it not be?
However, what's being described is entirely different. A narrative relies on both clear expression of the action and a broad context of details to give it resonance.
Code, on the other hand, operates through loops and definitions independent of timeline, so is a better match for architecture and math than the science of communications.
Futurist Traditionalism
There is a (rather small) minority view that code can actually improve our ability to think - http://www.jsoftware.com/jwiki... . However, the bulk of opinion sees code as an obstacle to be overcome - rightly so, given the sloppy, ad-hoc construction of most programming languages.
When writing code, your audience is not the compiler.
Your audience is another human being who will be maintaining that code a few years later.
If your audience were the compiler, then your code would just need to compile and run. It could be ugly. Unreadable. Unmaintainable. Uncommented. Have meaningless identifiers. Poor organization. Follow worst practices. Etc. In short, the kind of code you get from an outsourced contractor.
Consider that another human is your audience. Choose identifiers such that a comment is unnecessary. Comments should not say what is obvious. (This assigns foo to x.) Comments should say what is not obvious and cannot be made obvious by the code itself.
Write your code almost as if you are writing literature.
I'll see your senator, and I'll raise you two judges.
Code itself is simply a set of rules tying words and symbols to operations on a system. Learning those rules won't make you better at anything but learning rules. What will help you develop as a thinker is learning the underlying theory and ideas of a closely related field -- computer science. Thinking up your own solution to the dining philosophers problem, the knapsack problem or even understanding how you can describe the solution to the towers of Hanoi as an iterative process all help you develop problem solving skills and grant deeper insight into solving other problems. Simply learning a new coding language (unless that language is interestingly 'conceptually' (for lack of a better word) different from one you already know, like learning LISP when all you know is BASIC) won't improve much.
By the time some of my literature teachers are done, I'm sure the Hello World would be a subtle and poignant take on the overbearing consumerism as well as taking us to the depths of despair in search of the hero's hidden personality fractures.
The must instructive, enlightening thing I did in college while majoring in CS was to take a part time job grading Pascal assignments for an instructor. Of course my programming experience was significantly above that of the class being taught, but it was still very worthwhile to see how different minds went about solving a specific problem. There were a few students who I could immediately identify (by their code) who had the proper thought process (whether learned or innate - most likely the latter) for software development. I could easily recognize a few groups of 2-3 students who had obviously collaborated on the assignment (it was supposed to be an individual assignment). Students who only knew the most rudimentary constructs of the language were obvious - for example relying on huge sets of if / else statements instead of a simple case statement. There's just something about "reading" and critiquing code that makes you more self aware of the code you produce. Whether we're talking about code efficiency, style, organization or conciseness - I found myself writing better code (again, and not even necessarily through example or having seen something new) after having spent time grading and critiquing others' source code.
Better known as 318230.
If that tool you speak of is static and unchanging, like a wrench, then I could agree with you. Even if it were a moderately complex but extremely common machine with standardized parts, like a car, I could agree.
But if that tool is a complex machine, even a software machine, then communication is an important goal. Software inevitably requires maintenance and will be changed and improved over time. Pointless features will be added. Useful features removed. Since this machine is not an off the shelf machine, like a car, it is important that all of the information that the maintainers and improvers need are somewhere. The best place is probably in the source code itself.
I'll see your senator, and I'll raise you two judges.
It's more about the metatextual narrative. What does this say about the author? This GOTO implies that the author does not want to be where he is. He is desperate to break out; to be anywhere other than where he is now. He's backed himself into this corner, bound in a loop of his own devising, and yet unable to meet the conditions necessary to move forward. "GOTO!" he cries out, "For the love of God, take me away from the endless DO and WHILE!"
Here we see laid out the mind of a soul utterly broken. Can you not feel his burning shame? From the time he first took his toddling steps into the Hello, World! his teachers have admonished him "GOTO statement considered harmful". Yet desperate times call for desperate measures. He casts the thread of his execution into the void*.
Where will he land? We scan the page with increasing alarm. Can you feel your heart quicken? Where is the label? Where are we GOing TO? Now the reader is caught up in the narrative as well as the author. Does the label exist at all? How did this thing ever compile? Until finally, we see it. Safe at last! Our execution can continue, and yet we are forever changed by the experience. Have we exited the loop in the correct condition? Will there be enduring side effects? Read on to find out...
* The void, that is, not a pointer to an unknown type, I just mean to clarify that as a footnote**.
** A footnote, that is, not a pointer to a pointer to a footnote.
It is still a method of communication, though. You can often tell a lot about the programmer and his state of mind at the time by reading his code. It's very easy to tell when they were confused about what they were trying to accomplish, how comfortable they were with the language they were using and whether or not they were in a hurry.
Early on in my career, I started with the assumption that the original programmer knew what he was doing. The more code I read, the more I realized that this is almost never the case. From my observations, it takes about a year for someone to come up to speed with a project, the business process for the company they're working at, and any code base that was already there. Longer if the company's business processes suck. Until then they're mildly to severely confused, and this is reflected in their code. Since a lot of programmers don't hang around at one company for much longer than that, most of the code that I've run across has been crap. The first inclination might be to rewrite it, but as you're starting on a new project you're also mildly to severely confused, so it's best just to study the crap closely and make minor improvements as the opportunities arise. A crap in the hand is worth two in the bush. Or something. Most of the time. I've run across a couple of what had to have been bottom-ten-percent programmers whose crap did end up requiring full rewrites. Coming into a C project where the programmer didn't realize strings are null terminated is a huge warning. C++ or Java code where everything inherits from everything else is also a warning.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
No no, certain parts of coding is very much like literature. The style of how you... branch based on a string, or how you implement event-driven coding, or how you distribute computing power.
There are a TON of ways to skin those cats and which way you do it is a matter of stylistic preference. It's fashion. The exact sort of subjective shindig that lit major whittle away their time with. It's like the difference between writing in first person or third person. And in certain places one way is very much better than the other.
But who the hell reads code for the stylistic appreciation? We read code because it's broken, we want to steal part of it, or we need it to do something else. That's not a stylistic issue, that's a mechanic wrenching on a car. Figuring out just what the hell it's doing is a different act than bickering how it could have been done better. Doing the first part pays a lot better than the second.
This guy has noticed that most people that read things are reading restaurant menus, technical documents, text books, grocery lists, and not novels. The writers of said material are doing it to get shit done rather than fretting about how they do it.
Reading other people's code is a great way to learn better ways of doing things you thought you already knew how to do. ;)
The GOTO statement is reflective of the existential malaise experienced by programmers, and typified in post-modern society.
It shows that the programmer in the code, as in life, feels they have reached a dead-end from which there is no escape, and reflective of a desire to escape the mundane and return to the optimism of youth.
The GOTO becomes a metaphor for man's desire for a quick solution to our problems, and a naive belief we can make the problems go away, and thus becomes symbolic of wish-fulfillment and fantasy to offset the feelings of stagnation and dread so often described in post-modernism.
In stack based languages, the GOTO becomes a surrogate for a strong father figure, and metaphorically kills the mother in frustration. It's also convenient for breaking out of nested logic to an error handler, which gives us feelings of going back to the womb, and indulging in self-infantilism in order to achieve a more expedient resolution of the dichotomy between self and other.
Thematically, the GOTO is both liberation, and the source of our own slavery; it simultaneously demonstrates our desire for freedom, as well as showing the futility of such a quest and how we re-enslave ourselves through our actions.
Because it highlights the existential question of "how do you implement an IF statement without a GOTO in Assembler?", it forces us to acknowledge that, as much as man tries to escape his primitive roots, there persist behavior which is neither rational nor defensible, but which we nonetheless cannot do without from an evolutionary perspective.
The GOTO defines for us the boundary between man as thinking entity, and non-thinking animal. And, as in Conrad's Heart of Darkness, forces us to look within ourselves, and confront the things we see but cannot fully understand or control.
Lost at C:>. Found at C.
Your comment reminds me of this bit about the code for what became Adobe Photoshop. The code is available for download from a link on the page linked to below.
Adobe Photoshop Source Code
Thomas Knoll, a PhD student in computer vision at the University of Michigan, had written a program in 1987 to display and modify digital images. His brother John, working at the movie visual effects company Industrial Light & Magic, found it useful for editing photos, but it wasn’t intended to be a product. Thomas said, “We developed it originally for our own personal useit was a lot a fun to do.” Gradually the program, called “Display”, became more sophisticated. In the summer of 1988 they realized that it indeed could be a credible commercial product. They renamed it “Photoshop” and began to search for a company to distribute it. ... The fate of Photoshop was sealed when Adobe ... decided to buy a license to distribute an enhanced version of Photoshop. ....
Commentary on the source code
Software architect Grady Booch is the Chief Scientist for Software Engineering at IBM Research Almaden and a trustee of the Computer History Museum. He offers the following observations about the Photoshop source code:
“Opening the files that constituted the source code for Photoshop 1.0, I felt a bit like Howard Carter as he first breached the tomb of King Tutankhamen. What wonders awaited me? I was not disappointed by what I found. Indeed, it was a marvelous journey to open up the cunning machinery of an application I’d first used over 20 years ago. Architecturally, this is a very well-structured system. There’s a consistent separation of interface and abstraction, and the design decisions made to componentize those abstractions – with generally one major type for each combination of interface and implementation — were easy to follow. The abstractions are quite mature. The consistent naming, the granularity of methods, the almost breathtaking simplicity of the implementations because each type was so well abstracted, all combine to make it easy to discern the texture of the system. . . .
This is the kind of code I aspire to write.”
Good examples can provide powerful learning experiences. They can crystalize the intangible aspects of description and discussion.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
I don't see how any programmer would think code was literature, except perhaps highly technical literature. You read novels from beginning to end. You read code on an as-needed basis. You might only read the header of a library. In fact I've seen good libraries where the only docs I read were long comments in the header file. If you want to understand a system you might start with main() or your language's equivalent and find some kind of dispatch function with calls to things like ResizeWindow which is *boring* and calls to things like DetectThief which is *interesting* so you drill down into the DetectThief function and find out where it gets the data and how it decides the user might be a thief. That might only be a few thousands lines that you've looked at. The other 30k lines of GUI or sorting, or options of writing PDF reports... blah, it might not be interesting to you... unless you're a font and layout geek and the reports did something interesting with fonts and/or layouts. Then you might only read that part.
Likewise, if it crashes you'll pull it up in the debugger and read parts of the functions on the stack that lead to the crash. Aha! The contract called for the caller to not pass any NULL pointers, and they passed one. Fix. Commit. You had a *reason* for reading that code.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Knuth disagrees, which is why he created Literate Programming. If you aren't familiar with it, you should make yourself familiar. He suggests eventually someone might win a prize for literature from their code.
If you haven't seen it, you should check it out. His code has a table of contents, and could definitely be considered literature. His Tex code is so well organized, that you can find what you are looking for within 15 minutes, even if you're not really familiar with it. That's how code should be: written so other people can read it.
That's not what the author is talking about, though. He's talking about crappy code that wasn't written in a way that was easy to understand (I read the article; this is my understanding of it). So yeah, crappy code is not literature, or easy to 'decode.' Tautological.
"First they came for the slanderers and i said nothing."
Perl jokes aside, I have some old code written in everything from bash to C to R to Java. The common theme among these absolutely stunning pieces of literature is how incomprehensible some of it can be just a few months later. Sure, good code is self documenting, good code reads like a sentence, a proper module fits on one page of screen (I have a 24" display with better than 1920x1080 resolution, btw) but if my code were indeed prose, it would cause eyes to bleed, to hemorrhage, to explode in a fantastic fountain of blood and aqueous fluid.
Sometimes I wrote bits of code without knowing that there were easier ways. I may do a "for item in $(ls *.csv)" instead of the proper "for item in *.csv" or some furious hackery to manually rotate 20x10 matrix into a 10x20 (single command in several languages), or try to parse an XML file by regex'ing and other madness... Sometimes I was drunk. There was one class where the instructor didn't like "showoffs" so code had to be written using only the commands that were covered in the lecture. The resulting code from that class was horrid. One of my earliest bits of code from the 80s sent escape sequences to a printer and there are several strings with non-ASCII characters. There is no way to understand the code without knowing the printer. I have similar code for an Atari that stored music in a BASIC string. That might be possible to decode only if one understood how the Atari made sound.
obviously white-only
We don't read poetry, we decode it. Or maybe you would say that we interpret it? Depends upon your point of view. We don't read the original article, we skim it.
The original author is romanticizing the term literature, not that there is anything wrong with that of course, but literature is a term applied to everything from Dostoevsky to instructions for assembling a toy. Beautifully/Dreadfully written code could be labeled as art, poetry, literature, garbage, puzzling, cryptography, and a whole variety of other terms.
With all that being said and putting aside that I do not agree with the original author's definition of literature, I do appreciate their perspective.
Reading other people's code is a great way to learn better ways of doing things you thought you already knew how to do. ;)
Reading the source code to the OS and compilers used at my school probably taught me more than the classes themselves.
It was good code. Most of the business code I've seen is more like pornography than great literature, though.
Probably the best analogy is Architecture. There is a discipline that necessarily has a functional purpose, but still can (and often is) viewed and appreciated as art. A large part of the appreciation of architecture is appreciation of how it went about achieving its functional purpose, and there's a large body of theory build up around this. For example, its is a controversial but generally accepted architectural principle that form should follow function. An implication of this is that unnecessary architectural features are frowned upon. In SW Engineering we call non-functional code "dead code" if it flat out can't be used, and "inelegant" if it is simply more than necessary. Both are generally frowned on.
So if you want to spend time systematically analyzing software as art, perhaps the Right way to go about it would be the way architectural reviewers do, not the way literature or "high art" reviewers do it.