Earlier today, I commented Edit and Continue in the context of the MS tools and languages. I should explain what I meant when I called Smalltalk a more productive environment. I'll use a simple example - a small class Counter, with a single instance variable - count, and a couple of API methods:
Smalltalk.Demo defineClass: #Counter
superclass: #{UI.Model}
indexedType: #none
private: false
instanceVariableNames: 'count '
classInstanceVariableNames: ''
imports: ''
category: 'Demo'
addOne
self count: self count + 1
subtractOne
self count: self count - 1
I'll add a very simple UI so that you can get an idea of what I'm talking about:
Ok, so we have a simple UI, a simple counter. Now, with the UI running (which means that an instance of our domain model, the Counter class has been instantiated), let's make a change - I'll change the #addOne method like this:
addOne
self count: self count + 10
Ok, it's a silly change. But when we press the 'Add' button, we get the change immediately, in the running application:
That seems like a small thing, until you step back and think about it for a moment - this is exactly how I update this server. In fact, it's how I updated the search facility this afternoon. Ok, but what about edit and continue? Well, I'll toss a breakpoint into the changed method and press the 'Add' button again:
I change the method back to the original code, adding just one - and I get a result of 11. This is what Smalltalk has given you for decades - and it gets better - I can do more than modify just that one method, I can rewind the stack and modify any method, and restart from there. I've done this with the blog server as well, using X11 over SSH. This is the kind of thing that MS says they'll provide in a limited form for C# someday. Mind you, you don't need to have a breakpoint set to jump into a debugger - any unhandled exception tosses you there as well (extremely helpful during development). In fact, it's not uncommon for a Smalltalk developer to create a basic shell of a set of code, and then build out the code from inside the debugger. This allows us to use Smalltalk inspectors, and have the entire object model exposed to us as we develop. To a Smalltalker, objects aren't dead text fields - they are putty in our hands to be shapped and molded. That's what productivity looks like.
