Reaction for: Literate Programming by Lucas

Although the middle 4 pages or so of this article were useless to me, the author raises some interesting issues. The point of high-level languages is to bring machine code at the assembly language level up to a human-coherent level; something akin to literature. Hence this author's subject, Literate Programming. The author had some very "modern" ideas, although in the 14 years since this article's inception, things have changed quite a bit. What if coding and commenting could be integrated into an actual language, and not just a set of symbolic instructions that are broken down into more instructions?

One problem with this concept is that there are so many intangibles in litterature -- irony, implication, avoidance, prosopopeia -- these are all things that would be tough to translate to a programming environment. This is not to say that one would ever need any of these things, but as I have just illustrated, it is possible to go too far. Computers are literal machines, and they need code that is direct and to the point, not full of idiomatic expressions. Enter commenting; comments allow the programmer to explain to the reader what was intended, or how a cryptic function operates. Commenting is a great way to internally document the specifics of programmed code.

However, there is a major problem with commenting: not many people do it at all, and those that do usually don't do it well. I for one don't comment much if at all, while writing programs. CS15 made me go back and comment, which was a pain in the neck, so I began to begin to force myself to comment as I wrote to save time. This was one of the more helpful things I learned in 15, but it is cumbersome and most programmers don't see a need for it while coding. It helps me search through my code quickly to find bugs, certain methods, etc., plus explain to me something I wrote 3 days ago that I would have to hand-simulate to remember. In the short run, it's a pain in the neck -- however, in the long run I have found it to be definitely very beneficial, making my programs, dare I say, literate in some way.


Reactions


MY NAME: Danah Beard

MY COMMENTS

You say that you never saw the need for comments. Did forced documentation allow you to see the importance or did you just do it for a grade? Does anyone (other than TAs) see why commenting is useful? How can this be expressed?


Jon:

Well, I think that most people realize that commenting is useful, but are just lazy about it. If nobody really cared about commenting, why is there so much complaining that GP has none? :-)


MY NAME:Matt C

MY COMMENTS: Perhaps the majority of commenting should be done in the beginning of the program, when the design is done. If the program is big enough, the major classes and methods are pseudocoded before the real code is written. While a little tedious, it might be fairly trivial for a programmer to take their pseudocode, which is easier to understand than regular code, and comment based on that.


Lucas's Reactions to everyone else's reactions:

Danah: I should rephrase the second sentance of my final paragraph to read, "I for one didn't comment much if at all ..." Before Brown and 15, I never thought it was necessary because I never had to deal with anyone else trying to interpret my code. At first I did it just for a grade, but now I truly to see wht it is useful, not just to a grader/third party, but to myself as well.
Jon: I think it comes back to our discussion in Wendesday's GISP about how students see much of the code in their assignments (especially the earlier ones) as pretty much straightforward, and the addition of a readme on top of header and in-line comments seems a bit much. On the GP end, students are expecting all their support code to be flawless, and if they don't understand something, they want an immediate (and correct) answer. It may just come down to an issue of laziness.
Matt (Chotin): That sounds like a good (and feasible) idea.

[BACK]