Why can’t modern tools match Smalltalk?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

I often have the impression that Smalltalk in the late 80s and early 90s hit a peak that has yet to be matched. Great effort was instead put toward languages that are less intelligent, and which limit the computer programmer. Does this have something to do with the deskilling of computer programming, as Stanislav says?

It amazes me just how blindly complacent programmers have been in the face of the ongoing and very successful deskilling of their profession. Instead of rebellion, we see mass Stockholm Syndrome. There is no shortage of pundits ready to bloviate at nauseating length on nearly every – even the most trifling – perceived shortcoming of Lisp, other than this one.

This from the article about Smalltalk:

Dave’s OTI was notable for Smalltalk, ENVY/Developer, Visual Age for Java, and (as it was absorbed into IBM) Eclipse. Dave himself is a restless and driven businessman and innovator. His impact on the field of software development is much bigger than you realize, unless you already knew everything on his personal website. Dave’s fact packed contribution to this posting:

The original system was called Orwell ref and commission by Brian Barry of DREO Canada in order to bring disciplined development to a team of developers. In those days version and configuration management were foreign to personal image centric development style of Smalltalk. It managed both source and binary as well as versions of methods, classes, applications and their exact configurations for different products/releases. Developers managed their own change logs and code could only be shared by exporting and importing source. The original research system use a btree for method storage. The first system designed for developing embedded systems with code placed in ROM had an overly strict concept of code ownership.
Method, class level versioning were new concepts at the time, as were applications (now called packages and components) and there is still no capability in existing systems for sub-applications, method extensions and and configurations which are first class in the programming environment. ENVY/Developer was an internal tool that escaped because there was a need for something like it. Unfortunately the UI and documentation often meant that unless you learned it from an master (Alan and the ENVY/Master book) many didn’t grok the workflow. ENVY was a great strong specific solution which meant it worked well if you used it was intended. It was constrained to run on very small machines and poor network file systems where storage was expensive. We didn’t share the global name space due to a rush in implementation, which would have allowed ENVY to support true distributed development including global definition and initialization.
The commercial implementation done at OTI was called ENVY/Developer. Since I hate acronyms, we named products and projects with names. ENVY was inspired for software environment. ENVY/Developer was the version and configuration management tool, ENVY/Smalltalk was the embedded Smalltalk, ENVY/Actra the Smalltalk with Actor, ENVY/Packager the tool that removed unnecessary code from the image (both methods and class slots) so the code could be placed into RAM/ROM/Flash as appropriate. Later ENVY/App provide a “applet” like package for the Momenta pen computer.
The commercial implementation uses an immutable log for changes, and semantic locks to implement efficient fine grained concurrency. ENVY/Developer added the concepts of Configurations (Config Maps) and Sub-Applications. The former allowed a complete image to be loaded quickly for a specific product/Application configuration. Config maps could be nested for complex product development. The ability to click and load a specific configuration enabled one to support a specific customer in the field.
Code ownership was supported for both classes and applications, with a mechanism which allowed others to assume ownership when needed. In practice many teams used a common owner for applications. Applications were one of the first uses of Packages. An Application when loaded had the option of initializing itself and other applications. Applications were intended to be used as components with value based interface methods. SubApplications and Class extensions enable multiplatform or specialized method variants to be loaded for execution in different applications/platforms. One could version a method, a class, a SubApplication or Applications. Clients used the product to manage documents, hardware tests and deign diagrams.
Visual Age Java was implemented in Smalltalk and the Team facility used ENVY/Developer under the hood. The move to Java in Eclipse removed ENVY/Developer; but the ideas were contributed to Delta V (the basis for WebDAV/Subversion). ENVY/App provided the facility to load and unload applets, which at the time was not available for Java. Hence OTI contributed to the core of OSGi.
Many of the ideas were similar to GIT but with an integrate and share first culture versions a fork and merge later culture. ENVY encourage fine grain sharing to reduce merging. Being able to have multiple developers working on classes and methods with few conflicts facilitated this culture. Later versions included diff and merge tools. Recently Analyst for Kx used a new implementation of the ENVY repository, which has now uses a Git backend. The Git model is better for distributed development, and ENVY adds the concepts of function and module level versioning and configurations to the Git model.