This post originated from an RSS feed registered with Ruby Buzz
by Rick DeNatale.
Original Post: Cool, but Stupid, Things I've Done
Feed Title: Talk Like A Duck
Feed URL: http://talklikeaduck.denhaven2.com/articles.atom
Feed Description: Musings on Ruby, Rails, and other topics by an experienced object technologist.
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.
Previous Topic
