The Weekly Squeak

Giles Bowkett sparked a bit of controversy. There have been some interesting responses from James and Avi. I figured I would just stay out of it, and I did a pretty good job resisting. Until now.

Giles is right. Tools do not make good programmers. Coding in a debugger has the tendency to create lava code. Some of the worst code I’ve ever seen was the result of one more patch on a mountain of crap. The code just grows and grows until what ever was originally intended is completely lost and nothing is understandable.

That said, if you try to take away my Smalltalk debugger I will break your arm. Why? Because tools do not make good programmers. Even the Smalltalk debugger which is way more then your ordinary debugger will not help you. It will not cause you to write better code but it won’t hurt either. Anyone that has used and understands the Smalltalk debugger knows that it is a very powerful tool to realize your design.

If your design sucks then Giles is right a debugger is not going to help and will probably make things worse. If on the other hand you are a good programmer a debugger as capable as the Smalltalk debugger is extremely liberating.

I can understand why some people do not appreciate the power of the Smalltalk debugger. Most people think of debuggers as a way to watch a value or set a break point. They do not understand that Smalltalk is different and miss the point. As a live system that doesn’t need to be recompiled, a system that is running while you program, the Smalltalk debugger gives the developer unprecedented access to the heart of the language.

We have access to everything that is Smalltalk in that debugger. We can change running programs and step right into the code we just typed. We can view the whole running stack and full context. We can change data in objects, create new objects, do anything that can be done in Smalltalk right from the debugger!

Ever wanted to step through a loop? You need to see how the system handles the 57th item. You could add code to break at that point. You could write tests that isolate that data and run it separately. You could use aspects to keep from having to change the code but you are really working hard to do something pretty simple. The worst possible solution is hitting step until you get there! Since everything is live and dynamic in Smalltalk I just change the index to 56 and step from there! See it’s pretty simple in Smalltalk!

Yes tests are good and there is no substitution for good design. That doesn’t change with a powerful debugger. Powerful tools can enable bad programmers to program badly, but that doesn’t counter the argument that good programmers benefit from complete access to a dynamic running system.

Ok so break your arm is a bit strong, but I hope you understand that the debugger is our window into the heart of Smalltalk, maybe we should name it something else because it does way more then capturing debug.

– Ron Teitelbaum * President / Principal Software Engineer * US Medical Record Specialists