Mark Derricutt weighs into the live/dead debate with some comments based on his Smalltalk experience:

Sure, alot of the time Smalltalk gives you this "everything is live" scenario, the problem I have is when Blaine (and others) say "there's no shutdown, compile, restart, and retry" which goes all the window when you start asking them about deploying an application.

I've been using Dolphin Smalltalk from Object Arts off and on for the last year for a small windows project, to get an executable you strip the running image down to the executable you ship to clients.  As part of this "stripping" process, all the classes and methods that are unused in your application are (as they process implies) stripped/removed leaving you with a nice small redistributable application.

A problem I've often encountered with this is that often methods or classes that I'm using, but don't reference directly in code (class names set in config files etc.) also get stripped causing a problem that only occurs at "run time" - a state of the application where all the wonderfull "everything is live" functionality of the image isn't available. There's no means to update classes on the fly because the compilers been stripped out, I could include it - but then I'd be violating Object Arts licence aggreement.  My only hope of debugging any problems is to take a generated .ERRORS file (stack trace, thankfully one that includes all local variables at each point in the stack), load up the image, load the strack trace into Ghoul and hope I've not changed the source too much.

Well, let me take these in turn. Producing an application in Smalltalk is often the hardest part - the downside to having there be a blurred line between development and deployment is the line drawing. Now, I don't use Dolphin, so I can't comment on their process. In VisualWorks, I have a fairly automated process for turning the crank on a BottomFeeder executable. It's not as simple as it could be, but it's not Makefile maintenance either :)

As to the compiler and online updates - there are no license restrictions in Cincom Smalltalk that prevent you from shipping the compiler. Way, way back in the day, when VW 2.5 was the current release (around 1995), ParcPlace-Digitalk (The vendor at that time) had such restrictions. They went with the release of VW 3, and have not come back. I post examples of screwing around with the Smalltalk system in BottomFeeder all the time here, for instance - and I ship updates as new versions of parcels, that get re-loaded over the existing code.

The issue mark's talking about is a legal problem, not a technical one - and it's not a legal problem in any other Smalltalk system that I know of.

One last thing on deployment - it really depends on whether you are talking about a client or a server. For a client (especially a Windows or Mac client), you want to package up an executable. This matters a whole lot less on the server. The server running this blog, for instance, is a development system that was saved with the GUI turned off. It's still a full bore development system. In fact, if I were having a real problem with it, and wanted to know why it was doing something, I could have it save itself in the state it got into - and then download that image (meaning, I could save it separately, not impacting the running server outside the save window itself).

I've done that a few times, in order to see why certain things are happening. Which is the difference between live and dead.