On Tue, Sep 22, 2009 at 18:43, Matthew Brand <[email protected]>wrote:
> Literate programming sounds like a good idea to me in theory, but in > practice it looks like it takes as much time to do the literate programming > bit as it takes to just do the programming bit. > It does take more time up front to write essays, though it gets faster the more one gets familiar with the essay style of writing code. But since there is more typing, and the intent is to be explicitly didactic, it does take more time. > I think most people are probably as lazy as I am. If not lazy, then at > least > they have deadlines which would get in the way of the diligent "Literating" > of their code. > This is not an unfamiliar argument, but I think it applies just as well to testing or design. Deadlines are always an issue. The real question is whether the return from writing code essays is worth the investment. This will, of course, be different for different people and in different situations. My laziness takes the form of taking more effort to set things up early on, and then doing less later when things change and I (and others) have to revisit the code. I can't speak to other people's form of laziness. > It seems good in theory, but in practice it is probably true that > nobody is auteristic, or dare I say autistic, enough to keep it up. I'm not really keen on the idea that people who write code essays are autistic. It's an unnecessary insult. > How many large programs/organisations use/enforce Literate Programming > anyway? > I would think none enforce it, and hardly any use it. Argumentum ad populam? > With hindsight we might all wish that we had documented our code better > from > the outset, but practical realities mean that most of us are just happy to > get something working and state what the input and output should look like > before moving onto the next task. You've made three explicit references to the distinction between theory and practice, and an implied a conflict between them. Either the theory of literate programming can lead to practical benefits in software development and maintenance in certain situations, or it can't. Otherwise, the theory is simply wrong. I haven't seen any studies done on it, and doubt there have been any, which is a pity. But can we agree that a good theory would have implications on practice? At any rate, in the absence of good research, it's more of an anecdotal practice based on personal preference. As such, de gustibus non est disputandum. -- Sean Stickle 202-701-8353 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
