Literate programming is phrase coined by Donald Knuth to describe a certain approach of developing computer programs from the perspective of a report or prose. The basic idea is to create self-documenting code. The programmer should write code as if he or she is explaining to another programmer how the code will be executed by the machine, like a literature. Knuth implemented literate programming through the WEB system of structured documentation. It uses Tex for documentation and C for executable code.
Sounds like a awesome idea but I wonder why it didn't take world by storm like DSL. According to the interview recently published, Knuth thinks only small percentage of programmers are good at writing, hence never been adopted that well. What do you guys think? Now it keeps me wondering how good are we going to be with DSL, doesn't it requires same skill. It is not easy to come up with good succinct, well readable DSL. Do we need new skills to be good at it?
One beauty of DSL is, its domain specific and sometimes its really small and succinct, so no need to have extra documentation. Sometimes its important to have documentation if you allow your business users to play with your DSL but having them integrated part of the code could make it bit clumsy and verbose. And like any other type documentation it still have the same inherited problem of keeping up with code changes (maybe having them integrated might help). Now with languages like Ruby and Groovy its possible to write human readable executable code without any additional documentation.
Update: Nice blog entry from PragDave. Addresses few core issues associated with DSLs
http://pragdave.blogs.pragprog.com/pragdave/2008/03/the-language-in.html
Stuff about software development, agile and testing
Thursday, May 1, 2008
Labels
- agile (4)
- agile testing (1)
- build tool (1)
- design (1)
- DSL (1)
- duck typing (1)
- eclipse (1)
- ejb3 (1)
- Fluent Interface (1)
- grails groovy (1)
- groovy (1)
- gwt (1)
- hacking (1)
- haskell (1)
- java (1)
- javascript (1)
- jvm (1)
- languages (1)
- mac (1)
- pipes (1)
- programming (1)
- qa (1)
- rant (2)
- ruby (6)
- sas (1)
- scala (3)
- scripting (2)
- software rewrite (1)
- statically typed (1)
- testing (4)
- two phase commit (1)