Medicine versus mortuary in the debugger
James Robertson talks about some misconceptions about Smalltalk, but this is the bit that struck me:
I could just not write the full code at all, let the thing break, and ponder the response in the debugger. While there, I can write the code based on what actually came back, and watch it work. Rinse, Repeat for each one of them
Yes, tests are useful. But, the debugger is not something to be feared. Rather, it’s a great tool to be used in order to have the computer do all the memory work for you. I can get a lot more done by working with decent tools like the Smalltalk debugger than I can by assuming the doc is good and writing tests that just help me a whole lot less than you might think.
Here’s the thing. For some value of “nothing”, Smalltalk’s debugger and a debugger for C or Java are nothing alike. Smalltalk’s debugger is like going to see the doctor. You can poke and prod and run tests and prescribe medicines to resolve issues all while monitoring the results. In fact, it’s better than a doctor, because generally no matter how weird the “fix” you try, you can rewind it and go backwards. It’s a doctor with a time-machine. The debugger in C and Java is post-mortem. I can maybe tell you why it died, but I can’t fix it.
This is where the deepest disconnect happens. It’s a language issue. The debugger in Smalltalk and the debugger in C and Java are not only different in capabilities by orders of magnitude, they simply are orthogonal intellectually.
This entry was posted at 9:21 am on 9 May 2009 and is filed under Smalltalk. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
I’ve been trying to pin down why watching Avi Bryant fly through some Seaside development once was like watching someone perform magic, having only really used gdb in its variety of forms, but calling its debugger “a doctor with a time-machine” is incredibly apt.
Both comments and pings are currently closed.
Eclipse’s Java debugger allows some amount of changing code while running. Can’t add fields or methods to a class, but you can change the method bodies. Better than nothing.
Sadly, JavaScript debuggers are more or less read-only. It’s not even clear what “reloading” code, if you could change it in a JavaScript debugger would mean. It’s also the case that things like “reload” require things like “pop stack frame”, which JavaScript VM external APIs generally don’t support.
I say sad, because JS is a fantastically dynamic language that could have debugging capabilities ala Smalltalk.