It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise.
Absolutely true! The merger-politics, the marketing missteps, and the cool technology that got buried are all epic.
Image-based development also didn't sit well with a lot of people
Not so true, for those who really "got it" and hit their stride, and anyone who comments who didn't get to that point is commenting as a clueless newbie. In image-based development, all of your programming meta-data are there as live Objects, instantly scriptable, totally and instantly obedient to your every whim. Ditto for runtime state -- everything available as live Objects and instantly scriptable. Really, once you learn a suitable style, it's heavenly, intoxicating and addictive. The same thing is true for Python and Ruby, but only about half as much. For example, a lot of advanced IDE functions require one to detect changes to files and re-parse things to keep programming metadata current. That problem just vanishes with image-based development. Literally hundreds of problems just vanish because everything is an object and they're all instantly available.
On the other hand, image-based deployment SUCKS. Sucks sucks sucks. Just about every Smalltalker agrees. The big advantage of being file based is that your development test environment resembles your deployment, or is at least halfway to deployment by comparison. Image-based Smalltalk development is like the ultimate monkey-patching uber-debugger. Very cool to develop in, but you do not want to give it to your users!
Isn't it possible in image-based environments to have live objects but not the code that created them? This idea makes me extremely uneasy. Being able to derive everything in a running system from source code seems almost necessary for maintainability and comprehensibility.
You have that in the Smalltalk environment in the Changes Log. It is -- wait for it -- a text file! In fact, it gives you database-log like replay-ability in your entire development environment. "Being able to derive everything in a running system from source code," is exactly what it's for, and it's actually more capable and powerful than what you can get from source files. All of that scripting against the objects I was talking about? You can replay all that stuff too! If you do something stupid-dangerous like, "Semaphore allInstances do: [ :each | each release ]" then you can just exclude that last action when you replay the Change Log. Combined with image save, it gives you the freedom to live as dangerously as you like!
The classic demo -- have your students spend 1/2 hour writing some toy system. Then have them hard-reboot their machines without saving the image. Show them how they can restart the image, grab the Change List tool, and voila, all their source code is back!
To answer your question: it's possible that the source can be absent, but you have to execute an explicit command or do some sort of willful sabotage to make it happen that way. Really, it isn't so different from having separate source and executable files.
Because the environment that thing is designed to regen is the development environment. That's not the environment you want to give to your users. This isn't so big a deal with things like web application servers, but it is very much a big deal with desktop applications.
It used to be, the way you deploy environments involved stripping out the parts you didn't need for your application. This is doable, but it is a pain, and if you do it wrong, your app blows up sometime when you don't expect. ObjectStudio Smalltalk can bootstrap itself from source files, so you can avoid stripping. VisualWorks tries to build itself up from components (Parcels) on a base image as a deployment strategy. These are less painful than stripping, but your app still blows up if you do them wrong.
Combine that with some vendors not being all that concerned about testing deployment, and you have a potential mess.
Image-based deployment done right - have two images. Your devlopment tools go in the second image. To deploy, you simply leave out the 2nd one.
Comments
It is my impression that corporate drama around the smalltalk vendors helped to quicken its demise.
Absolutely true! The merger-politics, the marketing missteps, and the cool technology that got buried are all epic.
Image-based development also didn't sit well with a lot of people
Not so true, for those who really "got it" and hit their stride, and anyone who comments who didn't get to that point is commenting as a clueless newbie. In image-based development, all of your programming meta-data are there as live Objects, instantly scriptable, totally and instantly obedient to your every whim. Ditto for runtime state -- everything available as live Objects and instantly scriptable. Really, once you learn a suitable style, it's heavenly, intoxicating and addictive. The same thing is true for Python and Ruby, but only about half as much. For example, a lot of advanced IDE functions require one to detect changes to files and re-parse things to keep programming metadata current. That problem just vanishes with image-based development. Literally hundreds of problems just vanish because everything is an object and they're all instantly available.
On the other hand, image-based deployment SUCKS. Sucks sucks sucks. Just about every Smalltalker agrees. The big advantage of being file based is that your development test environment resembles your deployment, or is at least halfway to deployment by comparison. Image-based Smalltalk development is like the ultimate monkey-patching uber-debugger. Very cool to develop in, but you do not want to give it to your users!
Isn't it possible in image-based environments to have live objects but not the code that created them? This idea makes me extremely uneasy. Being able to derive everything in a running system from source code seems almost necessary for maintainability and comprehensibility.
You have that in the Smalltalk environment in the Changes Log. It is -- wait for it -- a text file! In fact, it gives you database-log like replay-ability in your entire development environment. "Being able to derive everything in a running system from source code," is exactly what it's for, and it's actually more capable and powerful than what you can get from source files. All of that scripting against the objects I was talking about? You can replay all that stuff too! If you do something stupid-dangerous like, "Semaphore allInstances do: [ :each | each release ]" then you can just exclude that last action when you replay the Change Log. Combined with image save, it gives you the freedom to live as dangerously as you like!
The classic demo -- have your students spend 1/2 hour writing some toy system. Then have them hard-reboot their machines without saving the image. Show them how they can restart the image, grab the Change List tool, and voila, all their source code is back!
To answer your question: it's possible that the source can be absent, but you have to execute an explicit command or do some sort of willful sabotage to make it happen that way. Really, it isn't so different from having separate source and executable files.
So why does image-based development suck for deployment? If you can regen an environment from a simple text file what's the issue?
Because the environment that thing is designed to regen is the development environment. That's not the environment you want to give to your users. This isn't so big a deal with things like web application servers, but it is very much a big deal with desktop applications.
It used to be, the way you deploy environments involved stripping out the parts you didn't need for your application. This is doable, but it is a pain, and if you do it wrong, your app blows up sometime when you don't expect. ObjectStudio Smalltalk can bootstrap itself from source files, so you can avoid stripping. VisualWorks tries to build itself up from components (Parcels) on a base image as a deployment strategy. These are less painful than stripping, but your app still blows up if you do them wrong.
Combine that with some vendors not being all that concerned about testing deployment, and you have a potential mess.
Image-based deployment done right - have two images. Your devlopment tools go in the second image. To deploy, you simply leave out the 2nd one.
I imagine filtering out all the irrelevant lines from the changes log would be an issue if you went that route.