This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Debugger use
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Debugging isn't about searching for forgotten quotes or a ';' at the wrong spot. It's about a totally different thing. Let's categorize some types of bugs to make understanding how to fix them a little easier, shall we?
Functionality bugs. These are the ones at the highest abstract level: in the functionality the software has to provide. An example of this kind of bug is the ability to execute script in an email in Outlook (Express) and enable that feature by default.
Algorithmic bugs. These are the ones at the abstract level below the functionality bugs. An example of this kind of bug is the (now patched) flaw in Microsoft's TCP/IP stack which marked the TCP/IP packets with numbers that weren't random enough which then could lead to data exposure via sniffing. The code was good, the algorithm used was bad.
Algorithm implementation bugs. This is the kind of bug you'll see when an algorithm is implemented wrong. This type shouldn't be confused with the next category, however. Algorithm implementation bugs are bugs which originate in the developers mind when the developer thinks s/he understands how the algorithm to implement works and starts cranking out code, however the developer clearly didn't fully understand the algorithm so a piece of code was written which will not function as expected, although the developer thinks it does.
Plain old stupidity bugs.. Everyone knows them: forget to update a counter, add the wrong value to a variable, etc. etc.
He then goes on to point out how edit and continue is not a good style for these issues. This is one of those places where Smalltalk (and Lisp) developers really part company with the rest of the developer community. Why is that? It's because for most people, the debugger is a forensic tool - the patient is dead, and the debugger is a tool you can use to figure out the cause of death. It's not that great a tool even for that in most cases. Now consider Smalltalk - the debugger is a browser where you also have the full context stack available. Unlike the patches on edit and continue in other environments, we can arbitrarily rewind the stack and start again from any previous point. We have a real code browser at our disposal, so we can investigate not just the in process object states, but also everything else. We can scan back to the starting point of the problem, fix that, and then start over. It's a highly useful thing to be able to do - I've used it to fix this server as people were actually using it.
The problem actually isn't one of right and wrong in debugger use, so much as different tools supporting different development cultures. This is why a lot of Smalltalkers read articles like Frans' and immediately roll their eyes - we are really talking about different things. And here's the clincher on that viewpoint issues:
People who grew up with assemblers, the gnu commandline C debugger and other terrible tools, know that debugging using a debugger is a last resort and also learned that debugging is not about using a debugger, but about understanding the difference between the sourcecode which should have been written and the sourcecode that is written
And people who grew up using Smalltalk or Lisp learned an entirely different lesson - which is one of the reasons why you see such frustration when Smalltalkers use Java, or C#, etc. - a lot of the basic development patterns are just different
Previous Topic
