I've been thinking about literate programming lately.

LP is the brainchild of legendary algorithm-master Donald Knuth, one of our field's undisputed deep thinkers. For the past 50 years Knuth has been toiling on his masterwork, The Art of Computer Programming, an encyclopedic exploration of algorithms, languages, and compilers. Knuth has finished just three of the planned seven volumes in his first 50 years of work, but it's not entirely his fault. He gets distracted. Disappointed with the state-of-the-art in typesetting when he published the first volume, for instance, he took some time off to create TeX and METAFONT.

Knuth introduced LP in an article called “Literate Programming” that appeared in the British Computer Society's Computer Journal in 1984.

The idea behind LP is that developers should write text that describes each aspect of their programs along with the code, in the same file, using a markup language to signal logical structure (headings, subsections, and so on). Special tools make the text visible and invisible, and strip out the text before compilation.

Knuth argued that describing code in prose would lead programmers to think more carefully about what their code did and how it operated. A mental feedback cycle would be established as the programmer wrote the text and the source code, and the result would be better software.

“The practitioner of literate programming,” Knuth wrote, “can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”

LP aficionados flame anyone who suggests that LP is just a mechanism for writing better-documented code. They emphasize that the programmer is really writing an essay about the intentions behind the code, and explicitly explaining how those intentions are mapped into source code. It's not just documentation. It's not just a discipline. It is a (dare I say it?) paradigm.

A central assumption behind LP is the notion that programmers can write well-structured essays that explain the why and how of their code. I'm skeptical about that. Going back to college showed me that the ability to write a well-structured essay is surprisingly rare (even at Columbia). Anyone with the ability to organize his thoughts sufficiently to write an essay about their code probably doesn't need help getting the code organized properly.

In other words, literate programming can help only those who least need its assistance.

The tools page at literateprogramming.com seems a bit out-of-date, but it provides a list of LP tools for use with different languages. A quick search of the Web turned up dozens more, most of them free. If you want to get started with LP, there's no reason to hesitate.

But modern operating environments have brought substantial formatting capabilities to source code editors, and I think those capabilities have rendered LP obsolete.

Yes, we should embed more and better documentation in our code. But once we've made that commitment, LP and LP tools don't bring much to the table.

Web recommendation: Computerworld's Preston Gralla is a super-smart guy and I've learned a lot from reading his columns over the years. But I think he's missed the mark with his latest effort. Gralla argues that those who are urging Apple to insist upon better working conditions for the offshore workers who manufacture its products must be prepared to pay more for Apple products. I think Gralla missed an obvious point. Apple could invest more in worker safety and working conditions without raising prices if it were willing to reduce its legendary profit margins somewhat. Apple is a profit machine. In the final quarter of 2011 the company had revenues of $46.33 billion and quarterly net profit of $13.06 billion. The company has $97.6 billion in the bank. Sharing some love with abused workers in overseas sweatshops shouldn't force Apple to raise prices. Gralla's article is here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He feels virtuous today because he spent the morning mopping floors.

There's an awful lot of talk this week about .docs. And not just .docs, but also .odf files. The first bit of news related to Microsoft's collaboration with Facebook. It's produced www.docs.com, which allows Facebook users to share doc files on their Facebook pages. I was unaware that people needed this ability, as I thought Facebook was for fun, and LinkedIn was for the serious business that .docs imply. But it would seem I was incorrect.

The other kerfuffle this week was the news that Oracle would begin charging for the ODF plugins Sun created to convert ODF to Doc. Much has been made of this link, wherein Oracle shows the plug-in to cost $90 per user, with a 100 user minimum purchase. One can't help but figure this will hurt OpenOffice.org adoption. But as a long time OpenOffice.org user, I am sorry to say that this is the least of that project's worries...

At the end of the day, both of these news items are pointless in the long run. I think its becoming clearer every day that our future does not require locally stored documents, nor does it include file formatting worries. Oh, developers will still have to worry about converting from one type to another, but really, they'll do all those things on the server-side, not on the client-side. 

Last week, I installed the Flow binaries of Google's Chrome OS on my wife's rinky-dink Acer Aspire One Netbook. It's a tiny machine that always chugged like a sputtering train uphill when I ran Ubuntu on it. The cheap SSD internal hard drive died, so I moved her over to a USB flash drive with Chrome OS on it. I have to say, this really will be the future of computing. And it's got nothing to do with Google's take on the operating system. It has everything to do with simplicity.

With the Chrome OS, the laptop becomes nothing more than a browser. There's no desktop, no local applications. You have to configure wifi or ethernet, first, but beyond that, it just works. How do you turn a Chrome OS machine off? You push the power button and it turns off. Simple as that. I don't think I've seen a computer in 20 years that could survive its power switch being hit like a light switch, without requiring a quick disk check on reboot.

I don't want to sit here and love on Chrome OS. Frankly, I would never use it on my work machines. But for less technical users who only care about the Web and simple office tasks, it's a dream. Of course, it's also quite far from finished. You can't print while using Chrome OS, for example.

The biggest worry in the transition was my wife's school-work. She's working on some degrees right now, and she has to write an awful lot of papers. She also has to read a lot of .doc files. As a former Ubuntu user, she also had some old ODF files lying around. 

But when we uploaded both types of these documents to her new-fangled Google Docs account, it didn't matter what they were originally saved as. There were formatting glitches, and some things didn't survive the translation perfectly, but the point here is that it was all handled by the server. The end user just fed the documents to the server, and the server made them usable. No dialog boxes, no configuration.

So, while the ODF versus .doc battles will continue to rage as time goes by, I remain confident that it is only the developers who will care about such things in the future. And any time a software concern can be abstracted to the point where only developers worry about it, the end users always win.