Old Dudes Who Know Smalltalk
It all started back in May, not long after we released the first public beta of Ruby In Steel. That was when Joseph Moore, a software developer in San Francisco, chanced to pick up on the fact that, long before programming Ruby, I had done some programming with Smalltalk.
Putting together this fact with the length of time that my colleague, Dermot Hogan, and I have been programming (a very long time), Joseph wrote:
Ah, there it is — These are Old Dudes! I love Old Dudes! And I really love Old Dudes Who Know Smalltalk! I was nurtured, sculpted, and brainwashed by Old Dudes Who Know Smalltalk from my very first day as a professional programmer, and they universally "get it". Young whipper-snappers out there, take note: if you ever here some Old Dude say the words "in Smalltalk you could blah blah blah" or "In VisualWorks you could yada yada", spend as much time with this person as possible. You will learn more from them about software development than the Young Dude who only wears black and thinks that the bash shell is "too bloated".
And what does "get it" mean? Maybe I’ll get into that some other time (it will be ugly, as this is one are where I am very opinionated), but the important thing is this: these guys don’t come from the school of web scripting hackery in vi, they come from the land of building real enterprise applications, where real tool support is appreciated. And at this point in the Ruby IDE game, I’d place my bets on them to produce the first a truly usefully development tool.
Flattered as we were by his confidence in us (but somewhat less flattered by his description – “old” forsooth!), I nevertheless assumed that this blog entry would soon vanish without a trace into the great mire of old blog entries which clutter up the Internet.
I’ve noticed recently that Joseph’s blog continues to bring visitors to this site. Curious to discover why this is, I decided to do a bit of research. This involved first going back to Joseph’s original blog entry and following the incoming links to the ‘old dudes’ post; followed, naturally, a bit of creative Googling.
I soon discovered that there are other people who reckon that being an ‘old dude who knows Smalltalk’ isn’t such a bad thing, after all. These include, as you might expect, some other dudes (quite possibly younger than us) who know Smalltalk.
But before everyone gets the idea that I am some kind of Smalltalk version of Yoda, let me put the record straight. Smalltalk is just one of many languages in which I’ve programmed over the years. Though, to give it its due, it happens to be one of only two languages which has ever truly excited me with its sheer audaciousness (the other language, incidentally, being Prolog).
That said, I am not unaware of the disadvantages of Smalltalk. Its ‘hermetically sealed’ development environment is a thing of elegance and beauty. But it isn’t necessarily the most practical way to program standalone applications. Ruby, on the other hand, has the potential of offering much of the elegance of Smalltalk without obliging programmers to commit themselves to working in the self-enclosed world of a specific implementation.
Ruby - The ‘New Smalltalk’…?
Some people describe Ruby (with or without Rails) as “the new Smalltalk”. I’m not sure I’d go along with that description. While it’s undeniable that Ruby owes a great deal to Smalltalk the differences are just as great as the similarities.
On the one hand, both Smalltalk and Ruby aspire to being ‘pure’ OOP languages. Unlike ‘hybrid’ languages such as Delphi or C++, both Ruby and Smalltalk do (almost) everything with objects. True, languages such as Java and C# may make the same claim – but both of those languages make more compromises than Smalltalk or Ruby in order to accommodate their C-like syntax. Ruby, in common with Smalltalk, makes far fewer concessions than Java or C#. To take a simple example, both Smalltalk and Ruby ‘hide’ the internal workings of objects (through ‘encapsulation’) much more thoroughly than C# or Java.
Ah, but here we arrive at one of the major differences between Smalltalk and Ruby. In Smalltalk, each method has ‘one way in’ and ‘one way out’. Once data goes in, it enters a sealed world. If any modifications are made to that data within the method, those modifications can only be communicated to other code by explicitly passing back a return value. This is definitively not the case in Ruby. In other words, Smalltalk enforces ‘data hiding’ but Ruby does not.
There are many other language differences between Smalltalk and Ruby and I shall have more to say about them at some other time. Naturally the one other huge difference between the two languages is that Smalltalk’s language and its programming environment are so tightly bound together that you can barely see the join. Ruby, by default, has no programming environment at all.
When I started programming in Ruby, the lack of an environment was the thing I noticed most. It was, indeed, the thing that first set us out on what has turned out to the monumentally complex development project of Ruby In Steel.
By the time Ruby In Steel is complete, these old dudes will be even older dudes. Ah well, it looks as though we are stuck with this tag now. I guess we’d better just get used to it…
Yeah, there’s a few of us who fondly remember smalltalk. Like ruby, we could boast about writing complex apps in a matter of lines. There was a cool cleaniness to smalltalk :) We used it at uni to learn OOP, wish I’d paid more attention now!
I programmed Smalltalk using Visual Works at a large telecommunications company in the mid-90’s. As noted above, it was an exciting experience. Unfortunately, the project I was working on was subsumed by a larger project and we were then forced to use C++. I was only able to work in Smalltalk for about a year before that happened. After a few months on the revised (C++) project, I lost all my enthusiasm and bid out to another assignment.
I have dabbled with Squeak ever since then, but the tightly enclosed environment is stifling. I have seen amazing things done with Squeak, but they can rarely be transferred to a more normal environment. Everything is usually within the Squeak VM.
So, I have now discovered Ruby and I am hoping to find the best of both worlds.