While Jim Robertson's financial info on ENVY and VisualWorks is fine
that's not the reason that Glenn Krasner as VP of engineering and I as
technical lead had for ditching ENVY.
First,. ENVY essentially dictated the architecture of the development
environment, including things like what constituted a valid package.
Once a new version of VW would come out we would have to wait about 6
months for the corresponding ENVY to come out. That gave VAST a 6 month
time-to-market advantage and meant that whatever ParcPlace engineering
did to enhance the programming experience was essentially irrelevant
because it would be overlaid by whatever ENVY deemed appropriate.
When we came to do VisualWorks 3.0, which introduced Parcels, this was
intolerable. First parcels had features ENVY couldn't model:
Parcels do "partial loading". One can maintain a large logical component in a single parcel and load it in a system that is missing some prerequisites. Any code that can't be loaded is held back until subsequent code loads make it installable.
For example let's imagine you build a distributed programming
system that allows helper methods on classes to control
distribution semantics for different kinds of objects.
Let's say you have several loadable applications such as
a multi-user drawing editor and a dungeons and dragons game
which you make distributed with the system. With parcels you
can put all distribution code, including helper methods, in a
single file. If you try and load it into a base system that is
missing the drawing editor and the d-n-d game the parcel will
still load. The extension methods and subclasses get squirreled-
away for a subsequent load. When you load the drawing editor
the distribution methods and subclasses get added.
In ENVY and other code loading systems in Smalltalk and other
languages you must subdivide the distribution package into a
code set of facilities and separate fragments.
This is a real advantage when you try and break up a system
into components. Partial loading means you don't have to
visit all other components splitting them up whenever you
extract some base functionality into a component.
Essentially it avoids a polynomial explosion in the number
of components in a componentised system.
Parcels support overrides, the ability to redefine classes and/or methods on load. So a parcel can override an existing base method, which is essential if you want to add or modify kernel behaviour on load. The overridden code is remembered so that if you unload a parcel the system reverts to its previous state, allowing one to unload code, which allows one more freedom in trying components out.
We needed the facilities to make 3.0 a componentised system within the
limited resources we have and these features have proved their
usefulness over the years, but ENVY could not support them and we would
have had to wait for years for it to do so. So we provided Store as a
team programming tool that supported the new parcel concepts and facilities.
Second, we wanted to bring programmers a rich VisualWorks programming
experience immediately, and not wait for ENVY to get around to doing the
work. We believed (and still believe) we can do a better job than ENVY
in the context of VisualWorks. By moving away from Store we have gained
control of the programming environment and you can see the improvements
made in recent years. Vassili would have had his hands tightly tied had
we not moved out from under ENVY.
Third, Parcels allow one to add single methods, including methods
defining types or external calls in external interfaces. ENVY requires
an entire ExternalInterface class to be in a single package.
Fourth, and quite importantly, ENVY's model is that one is always
attached to the repository. Store allows one to detach, developing in
ones' own image, reconnecting to the repository when appropriate. great
for plane trips.
Fifth, ENVY's versioning scheme is old-fashioned, based on ascending
version numbers. Store separates the version tree from code quality.
There is no implication in Store that a later version is more correct.
In Store one has "blessing levels" which declare whether a given version
is production quality, development quality, blue sky, etc, etc. So
components can go through natural cycles of development, productization,
experimentation, development and productization for version 2, etc.
So we had very strong compelling technical reasons that were the real driving factor. We had to risk pissing-off customers who were wedded to ENVY and even risk losing some of our most important accounts. But in then end VisualWorks is much better because of it.