Yesterday, while I was listening to an episode of FLOSS Weekly, Randal said something that caught my attention. He talked about writing unit tests and then running them before you had actually written the code - that much I had heard about before - but he then went on to talk about how you would then fix each of the tests by writing the code in the debugger, and clicking proceed.
This struck me as a really interesting way of coding. It's almost like having your office applications built into your to-do list. The to do item becomes the item you are trying to do.
I think I am going to experiment with this approach - I still need to understand a bit more about the debugger's capabilities. But what really appeals to me is that one could write almost pseudo code (although I think it is more of a declarative description) of what you want the object to do, and work away - a piece at a time - until it does it.
In a way, one could think of this style of programming as gradually removing all the bugs until the code does what you want.
Subscribe to:
Post Comments (Atom)
1 comment:
The approach mentioned of developing code in the debugger is a long standing Smalltalk strategy stretching back to the programmers at PARC that originated the language/system. At that time, before unit testing came along, it was common to find something already working in the environment which was similar to what was wanted. Then start up an instance of what you found and hit ctl-c with the mouse cursor over it (assuming an on screen visual component was involved.) Control-C would interrupt the process and bring up a debugger on the process stack thus exposing the live code for inspection and modification. Coding then became a matter of debugging what was already running to turn it into what was desired.
More than one person in those days commented upon having spent a day programming only to realize they hadn't left the debugger to use code browsers or other tools.
Concomitant advantages -beyond those directly related to rapid prototyping- coming from extensive utilization of the debugger are an increased understanding of how things actually work (from the level of the cursor to processes) and the effect of reading lots of good code (that in the system being of a high quality.)
As an aside, this approach became the standard approach to coding in the Self language/system where there are no classes but merely instances/prototypes to grab and manipulate as needed.
Post a Comment