The first Ruby Hoedown, sponsored by the Raleigh Ruby brigade, has finally come and gone. I had a great two days, saw some old friends, and made lots of new ones.
Here are my initial thoughts after more than a bit too litle sleep after a night trying to root out werewolves.
Deja-Vu All over again
I was just a little surprised how often Smalltalk came up during the weekend.
- The first instance was in the keynote talk by Bruce Tate, well known as a Java apostate in which he explored the current state of Ruby, how it got where it is, and where it might go in the future.
This was in part a cautionary tale, and the fate of Smalltalk in the mid-late 1990s loomed large.
As one of those heavily involved in the Smalltalk community as a developer and evangelist for IBM, I found it interesting to get an independent perspective.
- Ken Auer gave a talk on Saturday called “Does Ruby have a Chasm to cross?”
-
Finally, I “organized” a birds-of-a-feather session covering “Ruby for Smalltalkers, and Smalltalk for Rubyists” which was well attended and turned out to be mostly a few old IBM Smalltalkers like me, Fred George, and my
“evil twin”, Pat Mueller responding to questions from Rubyists about Smalltalk.
which covered much of the same ground as Bruce’s talk, but really focused on comparing the life paths of Ruby and Smalltalk.
So another independent perspective on what happened to Smalltalk, this time from someone with known credentials as a key member of the Smalltalk community when it was booming. Ken and I go back quite a ways.
Ken worked at Knowledge Systems Corp back then, which as a company which provided intensive training in object oriented development using Smalltalk via an apprentice program. Clients would send small development teams to KSC to work on the clients project with the assistance and mentoring of KSC folks. Efforts such as these were important seeds for what we now know as the agile movement.
Ken got a lot of things right about what happened to Smalltalk, although I could add some details and corrections from and “inside IBM” perspective, which might be food for future articles.
Testing Workshop
Stepping back, on Friday morning, Bruce Tate,
Chad Fowler, and
Marcel Molina jr. ran a charity workshop on test driven development, with proceeds going to the local food bank.
Although I’m a pretty committed test-driven developer, I found the session very informative, and got a new appreciation for the use of mocks, not only to allow testing before all the code is written, but to keep tests independent even after the components being mocked exist.
Watch this space
This article has already gotten long enough, I expect to post more about the events of the past weekend in the near future.
“Uncle Bob” Martin of Object Mentor just published an article containing his
personal recollection
of how the
… Dave Thomas of OTI fame. (We call him “Big Dave” to differentiate him from the Pragmatic Programmer of the same name.)
Agile Alliance got started and the writing of the
“Agile Manifesto”
He gives a bit more background than has previously been told. Of particular interest to me is the role of “Big Dave” Thomas, the founder of OTI in kick-starting the organization.
“Big Dave,” not to be confused with Dave Thomas of the Pragmatic Programmers, has been one of the movers and shakers of the object-oriented technology community for many years, and doesn’t always get the credit he deserves, particularly now that he has “retired” to the Carribean island of Anguilla. He might not be as visible now as he was in the heyday of OTI, but he’s still active. Had Anguilla been easier to reach, the Agile Manifesto would have been written at Dave’s place instead of in Utah.
I’m proud of my experiences working with and for “Big Dave” and to count him as a friend.
For some reason, talk on ruby-talk brought up old computer stories. David Black related a story told him by a former boss about a “photo op” in a company computer center triggering failures when the photographers’ flashes upset the optical sensors in the tape drives.
Since I’m sitting in a hospital cafeteria this afternoon waiting to see my wife who just had some surgery. I figured I might amuse myself, and hopefully you gentle reader with some old mainframe war stories.
Tale #1
When I was an undergraduate, I used to spend all my free-time (and much of my non-free time) at the University computer center. There was a large room for student use with keypunch machines on the walls and worktables in the center.
One of my friends was a graduate student who was working on a team writing an Algol compiler as a term project. They had broken down into teams, lexical analysis, parser, code generation ,etc. They were in the middle of integration.
The “source code control system” was a large punch card box. For those who haven’t seen them these are long corrogated cardboard boxes which hold a big stack of cards and have a lid hinged in the back.
The team was making a series of debugging runs, they would take turns carrying the box to the room with the card reader and offer the contents to the god in the mainframe as their latest ‘sacrifice.’ When the listing came back, they would spread it out on the table and figura out what to do next.
This wasn’t ‘pair’ programming, it was ‘septet’ programming.
I was sitting at a nearby table helping another student with a homework assignment, and glancing occasionally at the compiler team.
The guy with the card box came back from the reader to see his team-mates vigoursly discussing something they had seen in the last run. He was carrying the box in front of him, his fingers wrapped around the bottom, and his thumbs holding the lid down. He walked up to the table gaining interest in the discussion. As he leaned over the table, he absent-mindedly rotated his wrists and relaxed his thumbs!
They spent the next hour or so trying to ‘revert’ the deck from the last listing.
Thank God that today we’ve got cheap hard-disks and subversion!
Tale #2
Same time frame and place.
Tom was another graduate student friend. He was an older guy who had come back to school after spending some time in the trenches in Texas. Back in the early 1970s there was lots of data processing done by what IBM called “Unit Record Shops.” Tome had worked in one before coming to graduate school.
In IBM parlance a punched card was a unit record since the file record (I guess we’d call it a row in SQL these days) and the physical unit, the card, were one and the same.
Unit record shops, didn’t have computers, which in those days were investments on the order of a million dollars, give or take an order of magnitude or two. They did everything with decks of punchcards and machines which sorted, collated, or printed them. These machines were ‘programmed’ by connecting holes in plugboards with wires.
Tom said that once he’d accompanied his boss to a trade show. The boss, like many others, didn’t have a really good grasp of the technology his business used.
The boss saw Tom on the show floor and told him, “Tom, come here, you’ve got to see this!”
He led Tom to a booth where a “booth babe” was loading a rainbow-colored stack of cards into the input hopper of a machine, and pushing the start button at which point the machine put all the blue cards in one slot, the yellow cards in another, and so forth.
Tom couldn’t figure out why the boss was so impressed, surely he’d seen sorting machines before. After all they has several of them at work.
Then the boss showed his hand.
Tom, I’ve seen lots of fancy machines in my day, but this is the first one I’ve ever seen that could sort by color!
Even today, it’s too easy to create demos with lots of flash and no substance.
Recently on gluttonous, Kevin Clark announced that
Powerset is going to launch their front-end on Ruby. It seems that they were already pre-disposed to a major ruby comitment having built a sizable Ruby talent pool for their internal applications.
Prior to making the final decision to go all out with ruby for their front-end launch, the did some due diligence which included investigating the facts behind the recent furore caused by an interview with one of Twitter’s developers.
So they went to
Twitter’s lead developer, Blaine Cook to get the straight dope.
Quoting Kevin:
The simple fact is that Ruby wasn’t the source of Twitter’s woes. As it often happens with rapidly growing sites, they ran into architectural problems. Some design decisions don’t hurt until they reach a massive scale and at that point you have to rethink your approach. In an email he writes:
For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January
That last sounds quite true and corresponds to my experiences in the past with Smalltalk. I used to tell IBM customers that almost all performance comes not from the language but from application design, and that using a dynamic language which allowed the application to be developed in what’s now called an agile development process allows major performance gains through refining, refactoring, and retuning the system as both business and performance requirements get uncovered/discovered.
That’s as least as true of Ruby as it was of Smalltalk 15-20 years ago.
<iframe align = “right”, src=“http://rcm.amazon.com/e/cm?t=denhaven2com-20&o=1&p=8&l=as1&asins=0201184621&fc1=000000&IS2=1<1=_blank&lc1==E50707&bc1=000000&bg1=FFFFFF&f=ifr&npa=1” style=“width:120px;height:240px;” scrolling=“no” marginwidth=“0” marginheight=“0” frameborder="0">
Most programmers these days are familiar with, or at least aware of the now classic
“Gang of Four” book Design Patterns: Elements of Reusable Object-Oriented Software
One of the recurring arguments about design patterns is how they relate to individual programming languages. The “Gang of Four,” Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, were by majority, proponents of strongly typed languages. Ralph was the sole representative of Smalltalk and the rest of the dynamic object oriented languages. As a result, The GOF book had and has more resonance with the C++ community and it’s successors. Although there
are some Smalltalk examples in the book, many of the patterns express things which are easier, and in some cases
unnecessary to express in a dynamically typed language. I find this a bit ironic, since the whole patterns movement
seems to have started when Ward Cunningham and Kent Beck, two of the best known Smalltalkers, discovered the work of architect
Christopher Alexander and thought that his approach to building and municipal design could be translated to the
design of software.
As I was browsing today, I was reminded that there is another “Design Patterns” book,
“The Design Patterns Smalltalk Companion” by Sherman Alpert, Bobby Woolf, and Kyle Brown.
Which might be of interest to not just Smalltalkers
but also Rubyists, since it approaches the subject from they dynamic language point of view. It’s not easy to find, but Amazon has a few copies in stock.
Sherm was one of the researchers in the IBM User Interface Institute
which was housed in the same building where
John Vlissides and Richard Helm of the “GOF” worked,
the IBM Watson Research center in
Yorktown Heights, NY. I spent quite a bit of time with Sherman and the rest of the UI institute team under John T.
Richards back in the late-1980s to early 1990s.
Bobby and Kyle were OO consultants, who I also knew through Knowledge Systems Corp.
You never know what you might learn from the old Smalltalkers.
A recent thread on ruby-core which touches on the issues of subclassing
prompts me to tell another war story.
Back in the late-1980s to early 1990s, the software industry was starting to warm to the possibilities of object-orientation.
I’d gotten to be seen as one of the experts on OO inside IBM so I found myself
in a series of interesting meetings, but inside IBM and with other
companies.
That’s how I found myself at the headquarters of
a well-known company in the Seattle area
which at that time was one of IBM’s major partners.
This company was the major supplier of IBM’s operating systems
for personal computers. I don’t want to give too many hints, so I’ll give a
pseudonym to the CEO, let’s just call him “Gill Bates”, and I’ll refer to the
company as “BigSoftware” or “BS” for short.
Now some of the guys I
used to work with at IBM might remember a co-worker in IBM Cary, and then RTP,
named Gil Bates, different guy.
The meeting was to discuss
the BS plans for a new operating system with an object-oriented
implementation
and application programming interface.
A small team of BS engineers presented to
a small team of IBMers. I found myself sitting across a conference table from
the presenters and right next to Gill.
Frameworks, Frameworks, Everywhere
Let me step back a bit and give a little techno-historical perspective
for those who weren’t involved in software in the late 1980s/early 1990s.
One of the things which was exciting people at that time was the emergence of
application frameworks.
MacApp had been around a bit, and had gotten some publicity. This was a
framework written in Object Pascal which made writing Macintosh applications
considerably easier. MacApp provided inheritable classes
which implemented a vanilla application conforming to the Mac UI guidelines.
Writing a MacApp application consisted of subclassing the framework classes
and adding the behavior which made the app what you wanted it to be.
MacApp spawned other frameworks, ET++ was a port to C++ done in
Zurich by a team, which included Erich Gamma, if I recall correctly.
MacApp itself later was ported to C++, which led to Apple’s ill-fated Pink
project. I’ll probably tell a war-story or two about Pink here sometime.
Of course the framework notion has long legs, for example Rails is such a
framework for writing web-based applications.
Back then, the idea of applying the idea not just to applications but to
operating systems seemed natural to many. MacApp and its ilk contained
object-oriented wrappers to OS apis. Why not just make the whole OS a
framework?
As an OO evangelist I’d been caught up in this as well, selling the idea of
frameworks. I was still pushing for application frameworks, but the idea of a
framework-based OS seemed pretty neat until I started thinking harder about it.
The Blessing and Curse of Inheritance
Object Orientation to my mind is about encapsulation. The implementation of
an object is hidden from the users of the object. Inheritance is a powerful
implementation technique, but it breaks the encapulation between superclass, class, and subclass. Like it or not, subclasses need to be written with knowledge
of,
and track changes to,
the implementation of their superclass. That’s okay as long as the
superclass remains relatively stable.
The problem is that you can’t expect that kind of stability over time. As
the framework evolves, new methods and features get added to the framework
provided superclasses, and worse from the point of view of the framework
subclasser, the inheritance relationships between the framework classes often
change. It’s the natural result of refactoring.
I’d played with about three releases of MacApp, and noticed that with each
release, I needed to rewrite substantial parts of my applications if I wanted
to step up to the new version. This was okay in that,
since the MacApp framework classes became part of my application,
the application was a self-contained
whole, and would continue to run as long as I didn’t rebuild it with the new
framework version.
Dealing with the inevitable refactorings is feasible if you have control
all of the code being refactored, or at least can delay refactoring by
ignoring new versions of code not under your control.
The problem becomes much more difficult
when the operating system interfaces require your code to inherit from the
system. New operating systems will break existing applications.
Inheritance is a mechanism for sharing code DNA.
In that sense it’s like sex.
It’s best when it’s restricted to consenting adults, practicing using
safe techniques, and aware of the potential consequences.
The State of the Art circa 1990
The difficulty of maintaining compatibility between releases is exacerbated
when the techniques used to provide inheritance are statically bound. At the
time of my tale, it was conventional wisdom that in order to get reasonable
performance out of an object oriented program the classical C++ approach was
the only way to go. This involved using arrays of pointers to the method
functions, called virtual function tables, and mapping method names to an integer sequence from 1 to the number
of methods needed. For a given class, the number of the first method it
introduced (i.e. a method which was not just an override of an inherited method)
would be one more than the maximum number assigned to its superclass’s methods.
These numbers were determined statically at compile time, and needed to be known
when a call to a method was compiled.
This meant that a simple act such as adding a new method definition in a
class would require recompilation of not just that class,
but all of it’s subclasses,
and any code which called a method on any instance of the class or its
subclasses. Besides making for long build times, it also meant that such a
change would break binary compatibility even in cases where subclassing or
client code which didn’t use the new method and so didn’t need to have its
source code changed.
Inside IBM, something called the System Object Model was being advocated.
This was an attempt to make the C++ implementation just described a little more
flexible to at least partially address this problem, an issue which was dubbed
the “fragile base class” problem.
But the number of refactorings which can be successfuly addressed just
by loosening up the method calling mechanisms is a small subset of the
refactorings which normally occur over the life-cycle of a framework.
Early binding issues or not, even with a dynamic language like Smalltalk
or Ruby, maintaining interface compatibility over time is a very difficult
problem.
Rails, like MacApp, addresses this by letting applications be frozen to
a particular version of the Framework.
Back to the Conference Room
So as you’ll recall, I found myself sitting next to “Gill Bates” while his
senior architects presented their framework based operating system to be written
in C++. I gently introduced the problems I just described, and it took a while
for it to sink in.
I kept re-asking my questions as they came up with inadequate answers.
Meanwile I noticed that, sitting next to me, “Gill” was starting to rock
back and forth in his chair.
Finally, I said:
I just don’t understand how you are going to maintain compatibility
after you refactor the framework for the second release.
The reply was:
We have our best people designing the system,
we won’t have to refactor.
At that point, I suggested that the best people would recogize the
inevitability of refactoring. At which “Gill” finally chipped in by saying
to his presenter:
You guys don’t explain our stuff very well.
At the last meeting of the Agile RTP group, I won Michael T. Nygard’s book Release It!
Interpreted languages such as Java and Ruby almost never crash. Sure they get application errors, but it’s relatively rare to see the interpreter or virtual machine crash. I still remember when a rogue pointer in C could reduce the whole machine to a navel-gazing heap.
I remember “back in the day” when there were endless arguments between the C++ and Smalltalk advocates. The C++ folks would often quote Bjarne Strroustrup’s fear of flying in an airplane whose flight control system was written in Smalltalk, and threw a “message not understood” exception.
Those of us in the Smalltalk camp found this amusing, since the alternative was a system crash caused by an invalidpointer.
Now maybe Nygard framing rogue pointers in C as a memory means that the problem has been solved, but I seem to recall having seen it recently.
It’s Not Just The Language Stupid
<iframe align = “right”, src=“http://rcm.amazon.com/e/cm?t=denhaven2com-20&o=1&p=8&l=as1&asins=0978739213&fc1=E50707&IS2=1<1=_blank&lc1=E50707&bc1=000000&bg1=FFFFFF&npa=1&f=ifr” style=“width:120px;height:240px;” scrolling=“no” marginright=“0” marginheight=“0” marginleft=“8” frameborder="0">
One point here is that pet-features such as strong vs. dynamic typing or garbage collection vs. allegedly more performant1 manual memory management aren’t panaceas. They can have a major effect on aspects such as easo of development, or tweaking out the last bit of performance, sometimes in non-intuitive ways.
Making robust software requires more than just choosing a language, it requires craftmanship, adherence to best practices for the chosen language(s) and technologies, and a realistic understanding of the challenges at hand.
Release It!
And that’s where we come back Nygard’s book. Although I assume that most of my readers are Rubyists, and Nygard is a Java guru, there is much of value here for anyone concerned with producing robust software that can stand up to the real world.
Based on what I’ve read sofar, and skimming the rest, I can recommend it. If you’re interested you can buy it directly from the Pragmatic Programmers, or via the amazon.com link. The later would help feed the duckdogs who run this site, and lower my distraction from their gowling stomachs.
<a name=“fn1 href=”#fn_ref1">1 The “allegedly” will no doubt be explained in further posts here.
Recently, I’ve seen the Sapir-Whorf hypothesis used to motivate new spins on old ideas, such as behavior-driven design. For those unfamiliar with Sapir-Whorf it comes from the school of linquistic determnation, and taken to the extreme posits that a person’s language determines the way he or she thinks.
I’m going to post some thoughts about bdd soon, but this appeal to Saphir-Whorf reminds me of an experience I had about 10 years ago.
At the time, I was on a tour of eastern Europe for IBM. Our team was giving presentations on IBM software development products to developers in the former Soviet Bloc. I found myself in a hotel bar in Budapest with Muriel, a lovely young Frenchwoman who I’d met some months before and who was also one of the speakers. I’d decided to try to recover my old high school French which had been “rusting” for about 20 years. We had had several discussions about the French language and how it related to English. She had done a couple of overseas assignments with IBM in the US previously, and had worked in Connecticut with someone who had grown up in Brooklyn, which resulted in an amazingly charming and unique accent when she spoke English. We remain good friends to this day.
After a short time we were joined by another IBMer who was an American on assignment in Paris.
Flashback
I’d met him earlier in the day, when we were preparing for the next days session with the help of sevaral local IBMers. He had needed help in editing his Freelance presentation (I guess his secretary normally did this for him), and Muriel had done it using a Thinkpad borrowed from one of the Hungarians.
After she had finished, she closed Freelance to reveal that the machine was also running Microsoft Word. Mr. American in Paris went ballistic, since IBM had recently acquired Lotus. He couldn’t understand this treason, why was the guy not using Ami Pro? The answer was that Ami Pro didn’t yet support the Hungarian language.
This wasn’t enough to satisfy our friend, and the Hungarian went away shaking his head.
Back to the Bar
So our friend showed up and told us that, although he’d been in Paris for nearly two years, he hadn’t bothered to even try to learn any French. His theory was that there was no need since “everyone you work with speaks English anyway.” Now he exposed himself as a lingustic determinist, “and people who speak languages other than English can’t form certain thoughts.”
Oh really!? I said, like what?
“For instance, there’s no way to say “I like you in French.”
I shot an amused look at Muriel, we’d been talking about that very thing in the recent past. Those with a surface “knowledge” of French think this because the verb “Aimer” means both “to like” and “to love.” If you want sweet-talk a girl you say “Je t’aime.” Which every high-school French student, and ever sailor on shore-leave in a French-speaking port knows means, “I love you.” So they figure that there’s no way to say “I like you” since “aimer” is already taken.
But of course there is. French isn’t the “language of diplomacy” due to a lack of expressiveness. One way to say I like you is “Je t’aime bien” which seems odd to some since the “bien” strengthens a verb. That girl you’re trying to sweet-talk migh reply with “Je t’aime bien, mais je ne t’aime.” or “I like you but I don’t love you.”
And the Japanese don’t have a word for “no” which is why they can’t be impolite.
Again, this is patently false. Anyone who watched the old mini-series whould now that one of the first words Anjin-san learned was ie which means an emphatic no. The Japanese have lots of ways of saying no, or expressing variations of that thought, with various levels of politeness.
He went on to express several similar thoughts, but my amazement at his naiveté soon turned to boredom, and I tuned him out.
Does Language (Determine|Influence) Thought?
The Sapir-Worf hypothesis in it’s strongest form, and more generally, linguistic determinism, are nothing if not controversial amoung psycho-linguists. While there is some experimental evidence that language might have some influence on thinking, it doesn’t seem to be as pervasive as Sapir-Worf would predict.
Language, Expression, and Communication
It does seem evident to me that language affects the way thoughts are expressed, and that this difference in expression can hinder communication.
Take the expression of “I like you” in French. Not understanding the subtleties of expression might lead to a slapped face! I’m not sure about this, but my theory about “Je t’aime” vs. “Je t’aime bien” is that the two phrases might be related to teachings in the Catholic church. When I learned of the distinction, it brought back a memory from parochial school. The parish priest was visiting the classroom, and the teacher, a nun, asked him to explain the difference between “like” and “love.” He said that like was more than love because “I have to love you, but I don’t have to like you.” Because we might be talking to someone whose native language lacks the subjunctive case doesn’t mean that she can’t think hypothetically, and when she is trying to talk hypothetically we might not understand how she translates from her native language into English. It actually disproves my “ugly American friend’s” belief that since everyone needed to do business with already speaks English, there’s no need to make any effort to understand their language.
Now Back to our Regularly Scheduled Program
So what does all this have to dowith the usual subject matter of this blog?
The answer is that this mismatch between thought and expression leads to misunderstanding even in technical matters.
Someone whose ‘native language’ is strongly typed can have a hard time understanding the expressive power and idioms of a dynamically typed language such as Ruby or Smalltalk, and those without knowledge of Java or C++ can have a hard time understanding those guys, and arguments can proliferate because words denote slightly different concepts in various programming languages.
Different “methodologies” can sprout up as different groups of developers independently discover the same or similar techniques and give different names to the same concept, or the same name to different concepts, or a guru decides that a vocabulary shift is just the thing needed to explain something to a group with another mode of expression. Some of have been using agile techniques before they were agile, or even extreme.
And it can be languages vs. methodologies. I like to use the term “behavior” the way Smalltalk uses it, as an abstraction for an object which contains the methods of other objects (i.e. classes and metaclasses). I’m afraid that with the rising popularity of behavior-driven development in the Ruby community, with a different meaning of behavior, I’m going to have to find a new term.
But more on BDD here soon.
For those who don’t want to read a lot, or dont care too much, here’s the executive summary:
- I’m a long time object programmer.
- I worked for IBM for 31 years.
- I was one of the early adopters/advocates of Smalltalk in IBM.
- I’ve done a lot of Smalltalk.
- I’ve done a lot of standards work.
- I’ve done a lot of Java.
- I’m now free of IBM and Java, and I’m learning to love Ruby.
As a result of all of the above I’ve developed lots of strong opinions, weakly held, which I’d like to share.
Now for those with the stamina, some more details on my personal journey…
IBM Research – Smalltalk and ClassC
My early IBM career gave me a lot of experience with developing software. One of the things which struck me was how, despite its name, most software was hard. Hard to develop in the first place, and harder to change to adapt to new requirements.
Like many others, I first became aware of Smalltalk when Byte magazine published a special issue on the langage in 1981. I led a small team at IBM Watson Research which developed a language called ClassC which was inspired by that Byte issue, and added Smalltalk message sending to C, it was similar in concept, but not in syntax to Brad Cox’s Objective-C. We found out about Objective-C after we’d already done our worst. ClassC got some use for internal projects in IBM after I moved to a new IBM development lab in Cary, NC in 1984.
While I was working on ClassC, the late David N. Smith was dealing with the lawyers at IBM Research, Xerox, and UC Berkeley to get Smalltalk-80 into research. Dave and I became good friends, along with other folks in the IBM Research User Interface Institute like Dave’s “sidekick,” the late Jerry Archibald, and John T. Richards, and we formed an OO-Smalltalk cadre within IBM. These three were also key participants in the birth of the ACM OOPSLA conference. Although I personally missed the first OOPSLA, I was a steady participant for the first decade or so, moderating several panel discussions, participating in workshops, and serving on the commitee for OOPSLA ’93.
One of the advantages of being part of the OOPSLA community was being able to forge friendships and working relationships with many very bright people such as Ward Cunningham, Kent Beck, and all four of the “Gang of Four”
Research to Internal Consultant
After moving to the new lab in Cary, I primarily worked as an inter-divisional consultant, working to drive the requirements of my division, which was writing what was then a new style of applications with graphical direct manipulation user interfaces, into the plans of the Personal Systems division. This got me into a lot of interesting meetings with not only other IBM folks, but also staff from other companies. For example, I was present at the shotgun marriage between IBM Boca Raton, IBM Hursley, and Microsoft which led to OS/2.
My job had given me the opportunity to visit various companies which IBM was investing in, or considering investing in. I got to meet people like Jean-Marie Hulot of Expertelligence whose interface builder implemented in Lisp got re-written in Objective-C to become NeXTStep’s Interface Builder, after he moved to NeXT. A little later, after IBM had made an investment in NeXT, I got to meet Jean-Marie again along with Steve Jobs. I got to argue with Tony Williams and Bill Gates and his team over the merits of their approach to the early design of what became COM, which made the C++ type system a little more dynamic andwith the IBM designers of SOM which tried to make a statically typed systems more resilient to “schema” evolution. Both of these were also (failed) attempts to forge an entente in the “Language wars”
Smalltalk and IBM
With the availability of Digitalk’s SmalltalkV, our little OO cadre started to push for adoption of Smalltalk inside IBM. One of my biggest contributions was to implement a prototype which extended the Smalltalk/V development environment with a direct-manipulation UI and UI Logic (i.e. controller) tool inspired by the Interface builder, which I dubbed Application Builder. When SmalltalkV/PM came out, I ported the Application Builder to it.
The division’s mission had been shifting towards building application development tools, so this prototype fit in. Most of those tools were focused on old big-iron ideas and languages, such as ISPF, and Cobol adapted to personal computers, although targeted for mainframes. I arranged to demonstrate Application Builder to Earl Wheeler, the group executive who oversaw our division and who was in charge of a grand IBM strategy called Systems Application Architecture. Wheeler seemed quite impressed with the App Builder demo and directed us to turn it into a product, and get Smalltalk to be part of SAA, although he wanted it positioned as a “generator” instead of a language for internal IBM political reasons.
I took the point on getting Smalltalk into IBM product plans, while others took the prototype and turned it into what became VisualAge. In my opinion they took the visual programming idea a bit too far, but it did the job of getting Smalltalk out to the world from IBM. And it resulted in IBM Smalltalk, which was implemented by Object Technology International, a company founded by Dave Thomas, although a different Dave Thomas than PragDave. As an aside, what is it about guys named Dave Thomas? Besides OTI-Dave (who is well-known to the Smalltalk community as Big Dave), and PragDave, we have the Dave Thomas from SCTV and Doug of the McKenzie brothers, and the Dave Thomas who founded Wendy’s. Two Canadians, and two Americans.
I also spent a lot of time talking to IBM customers about how object-oriented approaches, and Smalltalk in particular, could help them solve the problems they were having with software being hard.
Smalltalk Distributed
One of my big-idea products was Smalltalk Distributed, a feature for VisualAge/Smalltalk. I led the development on this one.
Distributed applications were the rage at the time. There was another approach to distributing Smalltalk from HP called Distributed Smalltalk, but this was really a Smalltalk implementation of the Object Management Groups CORBA. Although I had been serving as one of the IBM representatives to OMG (as a Smalltalk expert), I didn’t find this idea particularly interesting or appealing. The goal of Smalltalk Distributed was transparent distribution of Smalltalk. Our approach was to implement a distributed implementation of the Smalltalk object model including object storage and garbage collection, message sending, and distributed threads of execution complete with non-local returns. This was all done completely in Smalltalk, using lots of tricks in using metaprogramming much like what the wizard Ruby metaprogrammers do.
This project was technically interesting, and got some use by customers, but it was most valuable as a learning experience. In retrospect, the transparency was both a neat idea, and a problem. Putting a black box around a distrubuted system is probably not as good an idea of putting a distributed system together out of black boxes.
As a result of the Smalltalk Distributed work, I got to spend a month in Sydney Australia, working with Jeff McAffer of OTI, to re-implement some of the ideas such as the distributed threads in a toolkit for building server applications which he called Surfer (or Server) Smalltalk. Jeff subsequently became one of the technical leads of the Eclipse project.
Smalltalk Standardization
Another piece of work I did at IBM was to write a report characterizing the similarities and differences between the various Smalltalk implementations. At that time these were ParcPlace VisualWorks/Smalltalk-80, Digitalk Smalltalk/V, and IBM/Smalltalk (from OTI). By focusing on the externals of the classes and taking inheritance out of the picture, I wrote a report called “Smalltak: A Common Base” which was in effect a rough draft of a reverse-engineered specification for a common Smalltalk language specification.
When the various Smalltalk vendors expressed interest in forging a Smalltalk language standard, X3J20 was formed to develop an ANSI standard, and the common base document became one of the early inputs. I became the secretary of X3J20. The standard was published in January of 1998.
Language Wars – Dynamic vs. Static OO
Of course back in the days before the turn of the century, there was a great debate raging in the “object-oriented” programming community, centered around the value of dynamic languages like Smalltalk vs. static languages like C++.
One of the things which always attracted me to Smalltalk was that it placed encapsulation above all else. As Alan Kay noted in his memoir about the origins of Smalltalk, his original conception of object-oriented programming was that software should be composed of objects which were, in effect, little computers themselves, which encapsulated both data and behavior, and hid the implementation of both from other objects, with objects interacting via sending messages to each other and replying. This uniform object model separates languages like Smalltalk and Ruby from other “object-oriented” languages. The various versions of Smalltalk all shared this model, although they varied as to some of the semantics of message sending and reception.
The idea of classes and inheritance as a way of factoring implementation was actually a rather late addition to Smalltalk. Although Kay acknowledges the Simula language, which also lacked classes and inheritance, as one of the influences on his thinking leading up to Smalltalk, it’s been a popular misconception that the better known Simula-67 was his real influence, when Smalltalk and Simula actually evolved independently.
Kay’s term “object-oriented” got hijacked when Peter Wegner published paper entitled “Dimensions of Object Based Language Design” at the second OOPSLA conference in which he defined “object-oriented” as “objects + classes + inheritance.”
Simula-67 spawned a family of languages which called themselves object-oriented but really used classes and inheritance to create hierarchies of abstract data types. In thes languages which include C++, Oberon, and to a lesser extent, Java became popular bacause they were seen as an easy entree into “object-orientation” to programmers who were more comfortable with the notion of programs manipulating data from “a distance.” This led Alan Kay to observe that
It is unfortunate that much of what is called “object-oriented programming” today is simply old style programming with fancier constructs. Many programs are loaded with “assignment-style” operations now done by more expensive attached procedures.
Because of this morphing of the meaning of object-oriented programming I started to use the term “object programming” instead. In 1991, I wrote an IBM Research Report called “Types From the Client’s Viewpoint,” which very much relates to duck typing and which got cited in a few places. It’s long out of print. So I’ve scanned a hard copy of a draft, to show my thinking at the time.
This debate lives on. It pops up as some of the uneasiness of new Ruby programmers coming from the strong-typing/abstract data type community over thinks like “duck typing.” I plan to explain my thinking about duck typing and other related topics here.
My point here is, I’ve got strong opinions about this topic. While I do believe that the key to wisdom is strong opinions weakly held, I haven’t seen any reason, over twenty-something years to let go of this set of opinions.
Smalltalk to Java
Smalltalk was quite successful with our customers. In some ways it looked like it might become the Cobol of the 21st Century.
Then Java came along. It gave some of the benefits of Smalltalk like languages in a package which was appealing to the C++ community, a lot of who were starting to become jaded over how C++ (if they actually used the compiler to do more than compile normal C programs), seemed to make development harder. It kind of looks like C++, and has a more “regular” syntax than Smalltalk, which some found wierd, although to the Smalltalkers it was beautiful in it’s sparseness and elegance.
And IBM made the jump to Java. Most of us who had been working on Smalltalk were encouraged to start working on Java and Java tools.
About this time, I took an assignment to OTI, which had been acquired by IBM Canada as a wholly owned subsidiary.
OTI itself was making an investment in Java. The first step was to turn the IBM/Smalltalk virtual machine into what was called the UVM or Universal Virtual Machine. This could run both Java and Smalltalk bytecodes. The Java “natives,” the equivalent of extensions in Ruby were written in Smalltalk instead of C. The first VisualAge for Java was written in Smalltalk on this UVM.
Eventually, as Java evolved this approach became less tenable. So OTI started building a new IDE in Java. Our first use for this was for a system to develop embedded Java applications. IBM was getting very interested in embedded software, which they called “Pervasive Computing” and had formed a division called PvC to pursue it. Embedded applications (e.g. code inside an oscilloscope, or a cell phone) written in Smalltalk was an early focus of OTI predating the relationship with IBM. Java, which was actually first developed within Sun for such embedded applications, was a natural language to employ.
The resulting development was called VisualAge/Micro Environment or VAME. The IDE and UI design was done at the OTI Zurich lab by a team led by Erich Gamma of the “Gang of Four.” This code was almost completely reworked and combined with Jeff McAffer’s component run-time architecture to become the basis for Eclipse.
After working on VAME, I moved over to a group working with customers on embedded Java applications. We majored on automotive applications, since there were a lot of car companies and suppliers who were interested in telematics systems with sophisticated software. As a “standards guy” I represented IBM in standards organizations such as the “Vehicle Expert Group” within OSGi
Back to the Mother Ship for a while
By this time, OTI was being gradually assimilated into the Borg of IBM. My group was first. Although we continued to work out of the OTI lab in Raleigh, NC, we now reported to IBM PvC management in Austin Tx.
Then because I was “the standards guy,” I got re-assigned to the PvC architecture department in Austin which was the home of all the PvC standards guys.
Eventually, OTI got “reorganized” (i.e. broken up) with various pieces going to different IBM divisions.
Free at last
After a year or so of this, and 30+ years of IBM, I realized that I was tired of life in a big corporation. Since I was old enough to still have a traditional pension, it was time to see what life was like on the outside, so I retired in the spring of 2005, and I’ve been happily pursuing my own muse, happily learning and working on new projects that I wanted to work on.
I’ve recently discovered Ruby, and as an old Smalltalker, I’m excited to see what looks like the reincarnation of an old friend. I’m starting this blog to see what I can share with the Ruby community based on my experiences.