Sunday, March 26, 2006
The Evil Write-Compile-Test Cycle
Computers are now fast and interactive. When writing code, you can just do a compile for every function you write to make sure you got the syntax right. You can write simple test programs to find out how some construct behaves.
Except that this kind of development is extremely bad (yes, I do it too). When you just have the computer tell you if you got the syntax correct, you will not actually learn the language properly. When you use test programs to figure out library use, you don't get to understand the library.
The main problem with this comes when designers of languages and libraries start to expect this kind of development. They become less likely to document their creations properly, relying on users to apply this trial-and-error method. Potentially there will be a few simple examples that do not tell anything useful, just how to use the most basic functionality.
For libraries, having the source available is the worst thing that you could have (I mean, when you're a user of the library). Designers too easily get the mindset that if their user has the source available, there is little need to provide documentation, since the source says how the library behaves. Of course, the source typically never says how the library is intended to behave, so a user can never tell whether some property of the library is accidental or designed.
My belief is that I should be able to write at least a few thousand lines of code only relying on published documentation on the language and any libraries I use, and have this code work correctly on the first compilation, assuming I have taken reasonable care in writing. My current experience is that this seems to be an explicit non-goal for most language and library designers.
