lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Miles Bader writes:
> David Manura <dm.lua@math2.org> writes:
>> Maybe this would be a case where something at least loosely based on a
>> literate programming style[2] would make sense given the Lua code's
>> small size, low change rate, and wide readership.
> 
> A typical problem I've noticed with "literate programming" type things,
> though, is that often the result _source code_ is almost unreadable.
> You _need_ to read it in the context of the "pretty" version, and while
> that's great for educational purposes, it's not obviously so for
> actually working on the code...

No, that is the whole point of literate programming.  What you call
the "source code" is analogous to the assembly code a compiler
produces.

When writing a literate program, you write an expose of what you are
trying to achieve, using the code fragments to make your ideas
concrete.

But since doing this is just as hard as capturing your design (or
intent) upfront, no good tools exist to facilitate this approach to
programming.  For people who like to program mostly within their
debugger of choice, literate programming is currently a complete
non-starter.  And in my experience, that is a lot of people.

Every time I embark on a new project, I think of using a literate
programming style.  But I am lazy.  Which means I often don't, and end
up spending more time coding than writing the program.  Every single
time I actually managed to get my ass in gear and do a project as a
literate program, I managed to complete it to much higher personal
satisfaction (and probably in less or roughly the same time, at least
never late).  And that, leads to much higher customer satisfaction as
well.

Robby