In a way Smalltalk prepared the way for Java in that it showed how great VMs and garbage collection were.
BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must have existed in other systems but Smalltalk was the first language where I encountered it.
Actually, Smalltalk compilation to bytecodes isn't incremental, from a certain point of view. The compiler finishes completely with bytecodes, usually instantly from the POV of the programmer. The compilation is complete. However, the binding is late. (Usually termed "late binding." You see, usually only one method has to be compiled at any given time.)
If the VM is a JIT VM, then there's another compilation step to machine code. Arguably, one could term this "incremental compilation" as well. It fits the colloquial definition of "incremental."
Another weird way one could term the features of Smalltalk, is the argument that it's a strongly typed language. Yes, that's right. It's just that the only type is Object. The differing of behaviors of instances of different classes is just runtime magic. (Late binding again.)
when an error occurs, the application does not crash but freezes allowing me to fix the error and resume.
to the point that when the aplication is a website and an error occurs while a browser is accessing it, the loading of the page just stalls until the error is fixed, at which point it resumes without any user intervention from the browser side.
Sounds like these live environments didn't support version control or reproducibility in the modern sense then?
"Corrupting the VM" just means that you were editing the stack frame class in the live system running on the VM and as soon as you hit "save", the VM crashes. So you simply run it again. And if needed, replay the changes log up to before the crashing change.
This only takes seconds, and is part of the reason why Smalltalk is so productive.
I wish more languages would incorporate it. The closest thing I know of is inspecting DOM elements through javascript’s debugger and using the developer console to run operations on them. But that only lasts until you press refresh.
With smalltalk, seeing an object and then being able to edit the object and then making it interact with other objects made OOP come alive, rather than Java’s inheritance soup with dubiously modelled classes that eventually made developers want to throw away OOP.
The article is very good describing what failed, from business to technology.
Why people jumped from St to Java? Besides the licenses and the OS movement that took many St companies off guard, there were also technical issues:
- Java was better for server side work. It had mature frameworks for Http/XML/Database access. Big companies allocated tons of resources to create Java frameworks and tools... the situation for St was different, you were at your own. For example, I had to debug and fix the WebServices framework available in VisualAge... because I didn’t have another choice.
- The JVM was superior in many areas: native threads, different GC algorithms, JIT, and many tools for monitoring and troubleshooting. Most of the St VMs only had green threads, it means that any blocking native libraries (like DB drivers) are problematic.
- As the article says, enterprises moved from desk apps to the web. And web frameworks for St arrived late.
- The classic St-80 was not designed with the idea of packages in mind. Loading a package is basically executing code that modifies your image. It’s powerful, but problematic because it can introduce unexpected bugs. Strongtalk tried to fix that, but it was a research project.
- To the package isolation problem, add the fragmentation between St implementations... it didn’t help to create an open source ecosystem of shared libs like in Java.
What I miss? The environment! In St you have absolute control of the environment. You can inspect everything (including your editing tools), and evaluate code everywhere without having to stop the world. Today you have editors or IDEs with plugin APIs, but is not the same. A comparable experience is modifying things live in the web browser, but it lacks the inspection/authoring tools from St.
We looked at Smalltalk early on but found a number of problems. They included slow execution speed (there was no JIT), lack of static typing (hard for maintenance), and difficulty to strip the VM environment to create an efficient runtime. Finally it had very limited ability to manage storage and memory directly. Without these it's difficult to build fast database systems.
Sybase tried to acquire a Smalltalk vendor in order to fix the VM problems but could not reach a deal so we ended up moving to other technologies. When Java came along we felt it was the language we had been looking for even with the early performance problems.
I was at their shared session (together with Sun) in Lisbon about NC and how it would change the workplace.
Thanks for sharing.
In addition to other advantages DBMS designers were looking for better ways to compile queries into executable representations (aka bytecode). That path still exists but I think the tendency now is to harness tools like LLVM and do JIT compilation.
https://en.m.wikipedia.org/wiki/Sybase
> 1993: Sybase and Microsoft dissolve their partnership. Microsoft receives a copy of the SQL Server code base. (...) Sybase SQL Server version 4.2 and Microsoft SQL Server are identical. (...) From this point the products diverge as Microsoft includes more Windows features whilst Sybase adds Enterprise features (performance and scaling).
> June 1993: Sybase announces its latest generation of software, named the System 10 product family; (...)
Then all C / C++ compiler vendors, jumped on the wave by adding support for the free beer Java SDK on their IDEs.
Just like Linux versus commercial UNIXes of the day, free is a mighty power.
There was serious intermingling back then.
There is also a lecture video in the Supplemental Material section.