Missing The Point Of Programming
This is in response to a lambda-the-ultimate post on literate programming, in which they wonder why it never caught on. Now, there are several possible answers to that question, and they give one or two good ones. But I think they are ultimately missing the point.
See, the idea of literate programming was born out of the well-meaning but ultimately misguided notion that programming is hard because of the notation. It's the same thinking that gave us pseudocode and UML. Did I mention 4GL languages? No, I didn't, because that particular idea died, thankfully, before I could be exposed to it (being young does have advantages, you know). The others survived enough for me to learn about them and to use them with abandon for a while. Then I asked myself a simple question. Why am I writing all my programs twice?
My issue here isn't laziness (though laziness is a quality in programmers; just ask Larry Wall), but a matter of keeping the two versions in sync. Anyone who's written real world software - or simply maintained a document in two languages - knows that one of the versions will end up falling behind. Which is fine, really, unless it's the one you actually use. But which version of a program do you actually use?
As it happens, there is a famous answer to this particular question. It says: "Programs must be written for people to read, and only incidentally for machines to execute." And I really hate to contradict the authors of SICP. But I tried to type their wise words into my theoretical text editor which I have coded on paper, and it didn't quite work out. Maybe I'm doing something wrong. Then again, the code in SICP is perfectly executable. Not so much readable, except in the first two chapters of the book. But hey, at least it's written only once.
So, about literate programming. One might argue that, at least, it's a step forward from maintaining separate documentation for software. We all know how well that works, right? Unfortunately, as it turns out, keeping the documentation in the same file as the code still doesn't help them stay in sync. Doing everything twice is boring and time-consuming no matter how you do it.
But, you might ask, if you give someone your undocumented code, how is that someone going to understand what it does? And you'd be missing the point: well-written code makes its function obvious. What code cannot tell you is why it does all that stuff. That's where a little documentation would come in handy. And that's exactly the kind of documentation that seldom gets written, because, you see, "why?" is a perennially difficult question to answer.
Now, I do know one system that might be labeled both "literate programming" and "successful". It's called Inform 7 and it's an authoring tool for a little-known form of art called Interactive fiction. It is also a programming language, though a layman would be fooled: Inform 7 is designed to read like plain English, or at least a formal dialect thereof. At least the authors took this approach to the logical conclusion and implemented a rule-based system. Which is much more like the way we humans process information. (It is also quite remote from the way a computer does, but hey, computer time is cheap nowadays.) So the Inform 7 approach works for plenty of people. See, there's an exception for every rule. Even this one.
To make things even more complex, while typing all this I remembered something said by Professor Solomon Marcus during a recent talk show. Namely, that if you see one of those scary math books with too many formulae and too little text, it's a sign that the author doesn't really understand the subject matter. The right proportion, he said, is around 50%-50%. Now, I could argue that math and programming are different things, but he'd probably whack me over the head with his thickest book for that. He'd probably be right, too. The only difference (except for the obvious fact that computer code must actually run on a computer) is that with math, you can have text and formulae be equal citizens, whereas in programming you have either code peppered with comments, or the other way around. Or comments that happen to be code at the same time, as in I7. The one thing you don't have is true equality. Hmm.
P.S. Having just finished this essay - for certain values of finished -, I stumbled upon Bertrand Meyer's scalding critique of UML (warning: hysterical laughter hazard). Small world indeed.