Talk Like A Duck: Tag visualage

Will It Go Round in Circles?

Rick DeNatale — Wed, 15 Oct 2008 15:24:00 -0400

I really like seeing the resurgence of interest in my second most favorite programming language

One of the comments to the referenced Gartner Group blog post had a link to an IBM Developer Works article about using using Eclipse as a Smalltalk IDE.

It seems like a strange loop, since Eclipse is the descendant of IBMs old VisualAge. Now I happen to know a bit about this since I was involved at the beginning. I guess that enough time has passed that nothing I say here will affect anyone’s business.

IBM, Smalltalk, and VisualAge

VisualAge started out as a demonstration prototype I wrote using Digitalk Smalltalk/V. The idea was to make something like the NeXT interface builder in Smalltalk as an adjunct to the Smalltalk IDE. For those who are not hip to such things, the Interface Builder, originally a Lisp program before Steve Jobs hired the author, lives on as part of Apple’s XCode tool suite for OS/X for the Mac and the iPhone.

The demo got some key IBM executives excited, and so the VisualAge development organization was born. Development proceeded using Smalltalk/V, along with Object Technology International’s (OTI) Envy/Developer, which was the state of the art version and configuration management for Smalltalk team programming.

As the project progressed, IBM and Digitalk had a falling out over conflicting views of who should be doing what. I’d shown the prototype to them in my position as liaison between the two companies, and they launched their Look and Feel kit which was seen by IBM management as competition from a supplier. So since we already had a relationship with OTI because of Envy/Developer, and OTI was in the business of building Smalltalk VMs, including the VM used by Digitalk’s Smalltalk/V for the Macintosh, IBM switched horses and contracted OTI to build “IBM” Smalltalk. This eventually led to the acquisition of OTI by IBM Canada.

This was about the time we founded the ANSI X3J20 committee to forge a standard across the existing and emerging Smalltalk implementations. I served as the secretary of X3J20. Some of the other members included Peter Deutsch and Glenn Krasner of ParcPlace, which Xerox had spun-off from their Palo Alto Research Center to commercialize Smalltalk-80; George Bosworth of Digitalk; Allen Wirfs-Brock of Instantiations one of the more successful Smalltalk consulting companies in the Portland Oregon suburbs; David Simmons who was the brains behind the iconoclastic Smalltalk/Agents; and Bruce Schuchardt who worked for Servio-Logic or Gemstone, I can’t recall which name they were going under at the time. I’m sure that I’m forgetting some of the players, but I’ll plead senility.

One of the great joys of working in Smalltalk during it’s first “glory days” was the opportunity to work with and exchange ideas with such brilliant people in IBM, OTI, and other companies.

VisualAge grew to become an entire family of development environments for several of the IBM “SAA” programming languages. There was even a VisualAge for Cobol! All of the various flavors featured an IDE written in IBM Smalltalk.

Enter Java

When Java “reared it’s head.” IBM, of course came out with VisualAge for Java. Again, the IDE was written in Smalltalk, although, in order to accomodate Java execution, OTI developed what was called the UVM (or Universal Virtual Machine) whcih could execute both Smalltalk and Java byte-codes, and used Smalltalk to implement the Java primitive functions which were implemented in C in the Sun JVM.

IBM eventually switched its focus from Smalltalk to Java. After considerable thought about this, and conversations with those who were in a position to know, I’m now convinced that this had nothing to do with the relative technical merits, and everything to do with a combined IBM/Sun platform play against Microsoft.

VisualAge for Java did eventually move away from the UVM for Java execution, primarily because the Java language had evolved to provide a standard C api for extensions. OTI began implementation of a new JVM, which was dubbed J9, which was built from the ground up to be usable in embedded systems.

OTI had a reputation of fostering the use of Smalltalk in embedded systems. When I first became aware of them in the early OOPSLA days, they were showing off products like an HP Network Analyser, and a TekTronix Digital Oscilloscope which used Smalltalk to implement their user interfaces. They were also involved with a large semiconductor company in Texas which was planning to use Smalltalk in controllers in an automated IC fabrication facility.

Around the time of the birth of J9, IBM was becoming quite interested in embedded software, under an initiative called Pervasive Computing (PVC). Because of this, OTI now an IBM Subsidiary, started working on VisualAge Micro Edition, which bundled J9 with an cross-platform IDE written, this time, in Java. About this time, I moved from IBM to OTI, and ended up working on the VAME IDE.

The Emergence of Eclipse

Work on VAME was distributed between various OTI labs. The lab in Phoenix acted as the liaison with the IBM PVC folks, the J9 VM work was done in Ottawa, Raleigh did some applications work, and some UI work, but the bulk of the VAME UI framework was done by Erich Gamma’s team at OTI Zurich. The IDE used Swing, as most Java desktop apps did in those days, and apparently that was a bit of a struggle. OTI used to have an annual all-hands internal developer conference in sunny early February Quebec, and I’ll never forget Erich, who is quite the Alpine skier, talking about the UI while showing a slide he took at some ski report showing a sign with a precariously oscillating chair-lift and a skier about to fall, with the text “Don’t Swing!”

This led to the desire to develop a new UI framework and what is now known as the standard widget set or SWT.

And the overall IDE/UI framework which replaced VAME was, of course Eclipse.

And now it seems we’ve gone from a Smalltalk IDE hosting Java development to the reverse!

Where Are They Now

Digitalk eventually merged with ParcPlace to form ParcPlace-Digitalk. For a while, both Smalltalk/V and VisualWorks/Objectworks (the ParcPlace Smalltalk-80 products) were carried, but eventually VisualWorks survived. It’s now shepherded by Cincom, which bought the rights.

Similarly, IBM eventually sold the rights to market and develop VisualAge Smalltalk (a.k.a. VAST) to Instantiations. My old friend and colleague from IBM John O’Keefe “retired” from IBM to lead the development team.

Several of the X3J20 guys went to or through Microsoft. George Bosworth worked for several years on a precursor to today’s Microsoft DLR. Davd Simmons and Allen Wirfs-Brock both work on Javascript for Microsoft.

And, of interest to the Ruby community, Gemstone is now working on Maglev, a Ruby implementation with persistent objects based on their mature Smalltalk product.

Cool, but Stupid, Things I've Done

Rick DeNatale — Sat, 17 Nov 2007 06:18:00 -0500

Cones
© Eric Castro

One of the things about working with software is that you can pretty much do anything you imagine.

Many of these things can be cool.

And many of them, particularly in retrospect, can be less than brilliant.

Here are two of the more visible cool, but stupid things I've done in the past.

Visual VisualAge

Years ago, my position at IBM gave me the opportunity to visit other companies pushing the envelope in software development. One such visit was to a small company in Santa Barbera, CA called Expertelligence, which at the time produced a version of common lisp for the Macintosh called ExperCommonLisp

There I met an interesting young Frenchman by the name of Jean-Marie Hulot, who showed me a user interface tool written in ExperCommon Lisp.

Sometime later I ran into Jean-Marie again at a meeting with Steve Jobs at NeXT. Steve had hired Jean-Marie. The interface tool had been ported to Objective-C and had become the NeXT interface builder. It lives on to this day as part of the XCode tools for Mac OSX.

I was impressed by what I'd seen, but by then I'd been working with Smalltalk for a while. The visual construction of the UI was cool, but I didn't like the idea of being dumped back into the mundane world of compilers and make. After having seen "Paree" in the form of the Smalltalk development environment, it was hard to imagine staying down on the farm.

So, I thought, why not make something like the interface builder inside the Smalltalk environment, and a quick prototype was born.

For some reason, I dubbed this the "Application Builder" with the idea that the combined UI Builder/IDE was for building more than just UIs.

Well, after I showed the prototype around a bit, I got to show it to Earl Wheeler, who was the IBM executive responsible for IBMs software tools strategy (AD/Cycle). He apparently liked what he saw, and funded a Smalltalk project based on my prototype. This opened the door for the IBM Smalltalk products to come.

Rather than getting intimately involved with the product development group, I stayed in advanced technology research.

When Earl took on Smalltalk, the last thing he seemed to want was to introduce a new language. But, because of the visual UI construction in my prototype, he rationalized "positioning" Smalltalk as a "generator." Perhaps as a result of this, the product team got quite carried away with visual construction and made the project a complete visual programming language, and the product was dubbed VisualAge as a result of a christening contest among the development team.

In retrospect the streass on visual programming wasn't so smart. The resulting programs were hard to understand, debug and maintain. Ken Auer recently observed that it produced a lot of "Smalltalk" programmers who didn't learn Smalltalk.

It also had a marketing effect on Smalltalk. After IBM came out with VisualAge, ParcPlace renamed their ObjectWorks family of products as VisualWorks.

IBM did eventually release IBM Smalltalk, unbundled from the visual programming componentry.

Too Much Transparency Considered Harmful

Sometime later, I had another "cool idea" and led a small development team to turn it into a product. The idea was transparent distributed execution of Smalltalk programs, and the product was the IBM/Smalltalk Distributed feature.

This was, if I may say so, a technical tour-de-force. Completely written in Smalltalk, the feature allowed Smalltalk programs to comprise objects on different networked machines. It was much more transparent that other distributed object technologies like Rubys DRB, Javas RMI, or Corba. Everything worked off of Smalltalks reflection capabilities, there was no IDL. In fact we named it Smalltalk Distributed to distinguish it from HPs Distributed Smalltalk which was 'just' a binding of Smalltalk to CORBA.

And the development environment was fully distributed as well, without too much work on our parts. For example the regular Smalltalk debugger was able to follow execution threads (in Smalltalk threads are called Proessses) from machine to machine and back again. A Smalltalk block containing a return on one machine could be called from a method on another machine, and the distributed stack would unwind just like it would on a single machine. Normal process synchronization techniques would work as well.

The key to making this work was implementing what I called a "logical" process which associated each Smalltalk process with a single local process on each physical machine involved in the logical process. The Debugger worked, because the Smalltalk debugger is, at heart, a process inspector, and by making the logical process mimic a normal process, the debugger was none the wiser.

This was really cool technical stuff, but in reality it turned out to be stupid because making distributed method sends so transparent hides important facts such as that there can be orders of magnitude performance differences between a local and remote send and, probably more importantly, there are failure modes (like network outages) for a remote send which just don't occur for local sends.

So just like cases where a building owner decides that it's prudent to put some obvious visual clue on a large floor-to-ceiling window to keep people from trying to walk through it, sometimes it's better to eschew transparency and make the programmer deal with reality rather than perception.