IBM, Sun, Java, and Smalltalk

Joe Gregorio

A comment on reddit:

So could we finally pull away the curtain and show how VisualAge is really Smalltalk underneath, kill off Java except as legacy callable libraries, and get back to working in Smalltalk like we were doing in 1995?

An amazing amount about IBM can be explained by the Java/Smalltalk schism that took place almost 15 years ago, though internally you'd think it happened just last week.

I tool some smalltalk classes back in 1998 or 1999. This was ParcPlace smalltalk, not IBM, but those guys just laughed off java. Then, at OOPSLA in 99, I remember the Smalltalk guys showing how they could convert their smalltalk code to java. Smalltalk is a nice language and environment but: 1. Smalltalk never built up an open community. 2. Smalltalk never tried to get itself into the University system That said, I have seen lots of good programs written in Smalltalk over the years.

Posted by Dave on 2009-04-05

As I recall, Visual Age is just a morphing of the technologies of Object Technologies International of Ottawa, Canada. IBM bought OTI around then, and took their Visual Smalltalk environment, and morphed it into Java / Visual Age. I think it has morphed again into Eclipse...

I programmed once in a derivative of Smalltalk called RPL, and I absolutely loved it after I learned how to do conditionals and counted loops using the Smalltalk syntax.

Smalltalk had two causes of failure:
  1. It never beat Microsoft at price/performance on development tools. They tried the Unix pricing formula (thousands per seat) instead of the Windows formula (hundreds per seat). Not a good way to win the loyalty of programming shops. The productivity gains of Smalltalk only work with star programmers, not average ones, and therefore don't justify a Unix pricing model.
  2. Smalltalk did not have an imperative C-like syntax for conditionals, counted loops, etc. That made it too hard for most programmers. Matz did not go this route with Ruby, and Ruby is doing quite well. The predecessor of Java was called "Oak", and it was much more like Smalltalk. However, Sun had the good sense to make the language look more like C in order to attract more developers.
Smalltalk did get itself into the University system (e.g. Carleton University), but that was just not enough.

At some point, the masters of the JVM will introduce support for closures/blocks and pave the way to support languages such as Ruby and Smalltalk to compile directly down to JVM bytecodes. .Net 3.5 has already done this, so JVM could not be far behind. Once that happens, I'm sure many enterprise shops will start accepting other JVM languages into their development toolchains.

Posted by Jay Godse on 2009-04-06

The problem with the JVM is not lack of support for blocks or ST syntax (that's easy), it's lack of support for dynamic features and the fact that the libraries have been designed for static OOP. That's not fixable; you might as well start from scratch.

Posted by mike on 2009-04-06

Jay: What exactly has the .Net 3.5 VM added to support closures?

Posted by Neal Gafter on 2009-04-06

comments powered by Disqus