Watched some MountainWest RubyConf 2014 talks and noticed an interesting theme. Many dynamic programming environments back in the old days used to be self-contained VM images, e.g. SmallTalk, GemStone/S.
One could checkpoint, modify, and ship these images wholesale and have it up and running with very little effort. Fast forward to now and I'm still using Make files to configure and install binaries. What happened?
It turns out that providing a VM which modulates all communication to the OS is darn hard. In the best case, you end up with a knee-capped interface that improves as people complain about not being able to do certain things.
Remember that quite a lot of these dynamica languages evolved as glue, no one ever thought that Perl would need to run on windows when Larry Wall first created it. It was a lot more important for it to just be able to seemlessly interact with unix since that's what everyone wanted to do with it.
Things in smalltalk VM land aren't all hunkydory either, it's near impossible to do the sort of things your acustomed to being 5 lines of perl since smalltalk plays terribly with the outside world.
At best nowadays if you want crossplatform VM's you should invest some time in Groovy or JRuby which run on a VM which has painfully evolved to be a useful crossplatform interface.
The number of people who had actually used one of these extreme productivity environments was pretty low. It started in workstation land, think $100.000/developer. Most developers couldn't afford the license and hardware needed. Then the price war broke out where Microsoft tried killing Borland and Sun gave away Java. Not enough developers had actually used smalltalk enough to stop management making long-term mistakes. So now the vms come back from the devops side, with docker
Yes, there used to be quite a few of these. I'm referring to a single package that contains code written for a VM, the VM itself and a set of data files, often using a proprietary database format. If you write and save code it too gets saved inside the environment.
The advantage it that it's a single object to ship, and it just runs with no installation since it has no dependencies (except that target OS). I recall various flavours of Smalltalk, Logo, Mumps/MIIS, Pick/Information/Ultimate.
They share much of the same history with 4GLs and together they constitute something of a programmer's [walled garden] (http://en.wikipedia.org/wiki/Closed_platform). I think what happened, surprisingly, was the Internet.
Developers had long wanted a better database, better IDE, better libraries, etc. Before the Internet they were stuck, but suddenly they could find all sorts of better tools and the package vendors couldn't move fast enough to either bring them inside the walled garden or compete directly. These packages gave you everything you needed as long as you didn't need much, but the Internet gave you infinite choice, at a price.
Personally I think that the walled garden has a lot going for it, especially for programmers with limited skills. However, you can't make money out of them any longer and the smart people creating tools don't see the point, so I don't think we'll see a comeback.
I have used this approach quite a lot for copying and sharing dev environments.
It works quite well -- except the current Linux obsession with "trying to be as pretty as Apple" means that the VMs display and desktop gets regularly trashed if you allow automatic updates.
The alternative of turning of updates lets have a reasonable chance of the desktop working when you fire up the VM -- but if you require the latest libraries for your development then its painful to get them up to date manually.
Probably because of performance. I have used a VM image to develop with - on Microsoft platform I was exposed to a legacy product that worked on XP but not Windows 7, so was given a copy of a VM to run on my workstation that contained all the dev tools set up to go. Performance was not what I would have liked.
I think much of that was due to GUI performance, but that's the most important part for a developer. In the past, with mainframe environments partly the VM is better integrated, but also GUIs were less resource intensive.
Today, we tend to have developer environments that require as much power as is available, but there is a move to deploying applications in a single image - we've seen VMs for deployment, but these tended to be too heavyweight for a single application (ie you had to have a full OS running just to host a tiny server app), so we're moving towards application-level VMs in the form of frameworks like Docker or Windows Containers.
