Last night there was a very interesting extra meeting of the local AgileRTP group. Johanna Rothman was in town and Jared Richardson arranged an extra meeting so that she could present some of the issues which arise in adopting agile methods, and how to deal with them. Johanna is very knowledgeable and gave an interesting and thought provoking thought.
One of the issues she talked about was "distributed" agility. This is a hot button as many companies are outsourcing some development to "offshore" locations. Johanna talked about the issues in following agile practices, and I'm vastly oversimplifying here, pointed at time zones as the major issue.
Someone in the audience, who works in a distributed team with members across the US, questioned her on this. As the discussion unfolded, other issues came up, such as dealing with a team in China which had one person fluent enough in English who acted as the "email-translator", as well as cultural differences affecting communication.
Language and cultural differences certainly can inhibit the free exchange of information which is the coin of the realm in Agile practices, but I had to observe that these are not really geographical or time zone issues. I've seen similar difficulties with co-located teams.
Distributed development using agile methods can indeed work, I've seen it. OTI was quite good at it. We did timeboxed projects with development spread across the globe. A given project might comprise team members in Ottawa, Zurich, Sydney, Raleigh, and Vancouver. Large projects might use a "team of teams" but smaller ones had individual members who were geographically dispersed. There was lots of communication by phone and email, and it worked quite well.
OTI had one "stand-up" meeting every year, usually in February in the balmy clime of Quebec, an annual Tech Conference where everyone in the company got together at a sort of internal "OOPSLA" to talk about what they were doing and to exchange interesting ideas, and just get to know each other better.
Now the main thing that made this work was that we shared a common culture when it came to development. Although not everyone at OTI was a native English speaker, all were fluent.
"Big Dave" had a tendency to hire good people wherever he found them. Often such a person would seed a new multi-person laboratory, but sometimes a "lab" would be a single person.
So distributed development can work, and work well, given the right people.
Some agility advocates stress the need for co-location, a notable exception is Kent Beck, the founder of eXtreme Programming, who now spends most of his time based a his farm in southern Oregon, and does remote pair-programming using VNC and Skype, with programmers around the world.
And Kent is currently auctioning off a two-hour pairing session this is a good opportunity to sample distributed agility at a high level.
I wish I could afford to bid, the current bid is at $200, which is cheap. I've learned a lot every time I interacted with Kent personally in the past. Someone is going to get a deal, whatever the winning bid turns out to be.
Yesterday I took a few hours and attended an intro to SolidWorks at TechShop Durham. Then today Kent tweeted about how JUnit Max has been faring, and it got me thinking about the state of the business in software for programmers.
For those of you unfamiliar with SolidWorks, it's a 3-D Parametric Modeling program, one of the newer and most popular CAD programs. If you are a fan of the TV Show American Chopper it's the program which Jason Pohl uses to design the bikes. It has been gradually taking over the 3D mechanical CAD market, replacing old leaders like AutoCad and ProEngineer. My main interest is as a hobbyist. I've been very interested in industrial technology since I was a kid, and I like to build scale models. I'd love to have SolidWorks to play with on my own, but it's out of my price range.
SolidWorks is owned by a big corporation Dassault Systems, and it's sold through a network of VARs. Yesterdays session was given by a support engineer from the local VAR. I haven't seen an 'official' price for a license, I think they get negotiated by businesses, but I understand that the cost of a single SolidWorks 'seat' is $5,000 to $10,000 with a yearly maintenance fee of around $1000 which gets you yearly upgrades and other goodies. There's also an 'educational' license which is carefully controlled.
And that price seems well worth it to a lot of companies.
This reminds me of the way the software development tools business used to be. IBM and others got big bucks for development seat licenses for compilers, ides and other tools, sold by salesmen and supported by customer support engineers. One of the reasons Smalltalk had a hard time gaining a foothold was that ObjectWorks and VisualAge licenses were very expensive, even Digitalk Smalltalk which was targeted at the same market as Borland TurboPascal cost a few hundred bucks.
Imagine there was a time when folks actually PAID for compilers for PCs!
Nowadays that model is harder and harder to support. Most of the tools programmers use, at least the programmers I hang with, are open source, and freely available. Every once in a while a program like TextMate will pry €39 or so from a programmer's pocket, but most of us get by living off the fat of the open source land.
Unlike the proverbial shoe maker's children, it's not that we don't have any shoes, we've got all the free shoes we want.
JUnit Max, as I understand it, is an Eclipse plugin which acts as a Java equivalent to Ruby's autotest, except on steroids. While autotest runs the most recently failing test until it passes then runs all of the tests, JUnit Max queues up retests based on how recently they failed. Knowing Kent as I do, I'm sure that it's a great tool, very well crafted, but I'm just not into Java anymore, so I don't have direct experience.
Kent is asking a measly $2 per month for JUnit (at least while it's in its beta version), but judging from his tweet this morning, he's disappointed at the number of takers so far.
I admit it, we programmers tend to be a miserly lot, and a lot of us end up doing a lot of code for the love of it. We might ask for a small fee, or put up a "tip-jar" like the one on the RiCal github page but it doesn't often amount to much monetary reward.
Boy, I wish I could come up with the next SolidWorks!
One of the classics in the Smalltalk literature, which has also had a big influence on the Ruby community is Kent Beck’s “Smalltalk Best Practice Patterns”, which captures the best practices for designing and coding Smalltalk programs. Back when it was published, I used to see Kent a few times a year, and happened to be in the Bay area when he made an author appearance at the Computer Literacy Bookstore in San Jose, where I got my copy, and the autograph shown here.
The Ruby language has many similarities with Smalltalk, so much of Kent’s advice applies to Ruby. I frequently hear prominent Rubyists mention the book.
On the other hand, Ruby is not exactly Smalltalk, so Kent’s book isn’t an exact fit to Ruby. I’ve been wanting to start writing about adapting some of these patterns to Ruby for a while, so this article will hopefully be the first in a series.
The Motivation For This Article
Recently on the ruby-talk forum a thread discussing accessor methods vs. direct instance variable access came up. This was a hot debate topic in the Smalltalk community back in the 90s, and Kent addressed it in two competing patterns in the book, one of which Ryan Davis (a.k.a ZenSpider) brought up in the conversation.
Patterns Are Decisions, Not Prescriptions.
In their best form, patterns represent a network of decisions made during the creation of something, in this case software. A good pattern should describe the forces which affect the decision whether or not to adopt the particular solution it offers.
There can often be a tension between competing patterns, different patterns optimize different desirable characteristics, such as readability vs. flexibility.
The forces, or their relative strength, can be affected by technical factors such as the language, and features of the editor or IDE being used. To varying degrees many or all of Kent’s Smalltalk patterns have forces affected by the capabilities of the Smalltalk IDE. One of Kent’s main goals is readable code, so writing code to maximize the utility of the code exploration features of the Smalltalk browsers, inspectors, and debugger figures into the book.
A Tale of Two Patterns
Now to the specifics of the article at hand. The book has two patterns described in sequence,starting on page 89, “Direct Variable Access”, and “Indirect Variable Access”. Both address the same problem “How do you get and set an instance variable’s value?” and give two opposing solutions, along with a good discussion of the tensions.
The first pattern, as the name implies, advocates referring to an instance variable directly by name, so in Ruby, within a method, you’d just write @x, instead of using accessor methods, the second pattern.
As Kent points out in the discussion of the first pattern, direct vs. indirect access was a hotly debated topic in the Smalltalk community, although indirect access got to be popular since it was advocated by several Smalltalk training companies.
Tension Number One: Readability
In his argument for direct variable access, Kent explains that whenever he ran into an accessor method invocation, which in Smalltalk looks like this:
a = self x
He found himself pausing to remind himself that x was “just” accessing an instance variable, but that he would read the direct form:
a = x
without breaking his stride.
I might point out that Ruby is subtly different here. First, direct instance variable access is clearly marked with the “@” sigil. On the other hand, a read accessor invocation in Ruby can be written without the explicit self receiver:
a = x
So it’s not as clear that this is a method invocation as opposed to a local variable access, although we know that it isn’t a direct instance variable access. Write accessor invocation usually requires an explicit receiver:
self.x = a
to disambiguate between a write accessor call and simply assigning to a local variable, at least the first time x appears in a particular lexical scope.
Tension Number Two: Subclassablity
Although direct instance variable is more readable, it does have a drawback in that it makes certain subclassing patterns harder to implement.
If a class uses indirect variable access consistently, then a subclass can leverage this by overriding the accessor. For example, lets say we want a subclass which audits changes to an instance variable. By overriding the setter accessor it can do things like logging changes very simply. Otherwise any methods which access the instance variable in the superclass need to be overridden.
Kent’s example is defining a PolarPoint subclass of Point which has radius and theta instance variables, and overrides Point’s accessors for x and y. One interesting aspect of the Ruby/Smalltalk comparison when you look at this example a little more deeply relates to my recent article about instance variables. In Smalltalk since the Point class has x and y instance variables, it’s subclass PolarPoint would have x, y, radius and theta instance variables, although the x and y variables would be vestigial and unused. In Ruby a PolarPoint instance wouldn’t acquire the unneeded x and y instance variables.
The Encapsulation Tension
One of the reasons why there was/is such a debate between proponents of direct vs. indirect instance variable access is the effect providing setter and getter accessors has on the apparent encapsulation of the object’s state.
First, in either Ruby or Smalltalk, the mere absence of accessor methods doesn’t prevent encapsulation intrusions. Ruby has the instance_variable_get and instance_variable_set methods, and Smalltalk has instVarAt: and instVarAt:put:, but these methods are ‘marked’ as slightly evil and reserved for dastardly deeds.
An accessor method on the other hand seems much more like any other normal method. In Smalltalk, convention is used to mark methods as private, although this is very weak consisting simply of putting private methods in a particular category in the browser, with no runtime check. Ruby does provide runtime checking of both private and protected methods, although even this protection can be circumvented, using send.
So in the end, the existence of and the tension between these two patterns demonstrates some key points:
- Patterns present choices, and the best patterns provide enough information to make an informed decision on a case-by-case basis.
- The languages and the tools we use have an effect on the patterns and the decisions they engender.
Maybe I’ve gotten a bit sensitive of late to the perception some Rubyists
seem to have of Smalltalk-bred Rubyists like me. So I thought that I might say a bit more of what
I think of the current and future of Ruby as a language.
What follows is much longer than what I expected it to be when I started writing it yesterday,
I hope that some will find it some combination of interesting, useful, thought-provoking, or
at least amusing.
- This weeks meeting of the raleigh.rb
group was a recap of railsconf 2007. Some of the attendees seemed to have gotten
a feeling that Avi Bryant was attacking Ruby in his keynote. I can’t speak for
him, and I wasn’t there so this might just be my reaction.
- Heard this week on ruby-talk in a discussion of the fact that Module#ancestors doesn’t
include a singleton class of the receiver should it have one:
I do not want to argue with the wise guys if it is an error – I
clearly thought so but that is not important ;)
But it really would have saved me an hour of debugging if the doc
stated clearly that singletons are not included. I thought this might
help others and as it took me 20s to vim the missing line into class.c
- Robert Dober
To which I replied:
As far as I can tell, singleton classes aren’t mentioned in the doc.
The documentation borders on folklore.
Singletons as a means of implementing both individual instance, and
class behavior have a position like “the man behind the curtain” in
“The Wizard of OZ.” We’re really supposed to disregard them.
Coming from a background in Smalltalk, my preference would be if this
machinery were more visible and official, but Matz has his reasons for
not doing so. For one thing, not documenting it, and hiding it from
methods like ancestors and class makes it easier to tinker with as the
language evolves without “officially” breaking backward compatibility.
Does that mean that no one who’s ever used Smalltalk can ever think
that it’s right for Ruby to deviate from Smalltalk? :-) I ask in a
humorous spirit – and also because it gives me an excuse to mention:
— David A. Black
To answer David’s humorously posed question, No,
and I present myself as “exhibit A,” because I certainly think that it’s right
for Ruby to deviate from Smalltalk. My main motivations in writing about Ruby in the context
of my Smalltalk background are first to help myself, and I hope others, understand Ruby a little
better by providing some perspective from another, earlier, dynamic language, and second, to a much
lesser extent, to air ideas of how some of the features of Smalltalk might be incorporated or
adapted as useful additions to Ruby as it evolves.
In many ways, I like Ruby better than I like Smalltalk. To name a few reasons, Ruby is more dynamic, has a more flexible deployment ‘model,’, and
albeit it’s not a technical reason, it’s not carrying the burden of the old business model of
trying to get thousands of bucks for each development seat.
is what really allowed
Java to pop Smalltalk’s balloon. Smalltalk was seen by IBM and it’s competitors as “enterprise”
technology, and they expected the same kind of prices which
other corporate level software development
tools commanded. When Java came out and was free “as in beer,” it gained a large popularity with
language hobbyists/hackers who could easily get it to play with, and a lot of those guys worked
for the companies to which IBM, ParcPlace-Digitalk, and the others were catering.
The other aspect of Java which helped at the time was it’s relationship in
syntax, and a lot of its semantics, to C++ at a time when there was a lot of corporate C++
activity and some frustration was starting to be felt with the complexity of C++. Java
felt enough like a simplified and friendlier C++ being a language which was more dynamic
without “going all the way” and which
felt familiar to both C++ advocates and C++ approach to
strongly typed class hierarchies, and C++ programmers with symptoms of the
These self-same aspects of Java caused many Smalltalkers to be uneasy with
The real salvation of Smalltalk, as it exists today, was and is Squeak. I remember when I
first encountered Squeak, it was at a Birds-of-a-feather session at OOPSLA, right when Java was
really starting to get most of the mind-share. My impression was that the atmosphere in the room
must have been somewhat like that in the Roman catacombs when the early Christians were
I guess that there is still a bit of the old “Enterprise” Smalltalk market,
Instantiations, which took
over the old IBM/VisualAge Smalltalk base when it fell out of IBMs strategies,
sells it for an entry price of
$6,995. There must be enough of the old legacy corporate Smalltalk customers around who
Personally, it’s been quite a while since I was an active Smalltalker, I made an oddyssey
through Java-land with IBMs shift in priorities. I plan to write about some of my
feelings during that period in retrospection but that’s for a later date.
I haven’t been
keeping up with Squeak enough to know how and how much it has evolved the Smalltalk technology
Old Smalltalker’s perceptions of Ruby
I always thought that Smalltalk would beat Java, I just didn’t know that it would be called
‘Ruby’ when it did.
— Kent Beck
I ran across this quote for the first time a few weeks ago. It sounded like
something that Kent would say, and also something that I would like to quote myself, but just
to make sure, I asked him. He told me that ‘yes’ he had said it in a private communication to
someone else, and both he and the original recipient had only recently found out that it was
becoming an internet meme. Googling <a href=""I always thought smalltalk would beat java">
“I always thought that Smalltalk would beat Java” garners over 250 hits.
Kent tells me that he’s a Ruby fan. Ward Cunningham is also.
I asked Ward, just before RailsConf,
if he was going since it was in his home-town.
He said that he had found out about it after
registration was closed, but he was planning to hang out at the hotel anyway. From what I heard
last night he was recognized and invited to attend.
Several of my other old Smalltalk buddies, who had also gone through a period with Java,
seem to have the same feeling which I do, that
looking at and using Ruby feels like being a widower who meets a new woman, who just seems to
be a partial reincarnation of the former spouse.
Where You Are Come From Depends On Where You Came From
Getting to David Black’s article. He certainly has a point about letting Ruby be Ruby. As
I’ve said, I’m quite happy with Ruby.
Getting back to the early perceptions of Java, and making an analogy with natural languages
let me suggest that if we think of Smalltalk as Italian, and C++ as German, Java is
Alsatian, and Ruby is French.
Were it not for Squeak, Smalltalk might be Latin instead of Italian.
The most un-Smalltalk like thing about Ruby, to me at least, is the syntax,
Smalltalk has almost
none, many Smalltalkers say that Ruby has too much. I thought so initially, but now
I’d argue that the flexibility and
“sugarary” aspects of Rubys syntax are what makes it so successful as a host for internal DSLs
like Rake, Rails/ActiveRecord, RSpec, etc. etc. which would be far less
natural in Smalltalk with its extremely limited syntax.
One of the complaints I often
heard about Smalltalk was it’s ‘different’ syntax just unary, binary, and keyword message send
expressions, blocks, parentheses for expression grouping, the use of ‘;’ to send a message
to the object which got the last one,
and single value assignment, and a way to return a value, everything else,
including class and method definition, and control flow was built from these atoms.
Ruby probably appeals to a broader audience
since it looks enough like something like Java not to be considered too wierd, at least not at
first. For one thing in ruby 1 + 2 * 3 is 7, instead of 9 in Smalltalk due to its total lack
of operator precedence.
But, syntax differences aside, conceptually both Smalltalk and
Ruby are romance languages, as compared to the Teutonic C++ and it’s kinder-gentler relative.
Language Evolution and Cross-Breeding
Programming languages evolve much like natural languages. They pick up influences from
other languages and incorporate them with modifications. English is the equivalent
of a multi-paradigm language, it has been influenced by the languages spoken by both the conquered
and counquerors of English speaking lands. It’s been influenced by Vikings, Normans, and Indians (both the Asian and American meanings of the last).
English has a lot of synonym pairs one from French and
one from Anglo-Saxon with it’s Germanic roots. Pork and pig; beef and cow; fraternity and brotherhood. This comes from the days after the Norman conquest when the language of the English court
was French. Bill Bryson describes this in his book
The Mother Tongue""The Mother Tongue".
Many of the words considered “fancy” by English speakers are of French origin. Kent
Beck told me that while he was working in Zurich on a contract with a Swiss bank, he found that
an effective way of communicating with the programmers there, was to use simple English grammar,
but “fancy” English vocabulary. The latter helped because the Swiss programmers facility with
French increased the chances that they would share such word.
There’s an old joke which goes:
What do you call a person who speaks two languages?
And what do you call someone who speaks only one language?
Most good programmers, even the Americans, are multi-lingual when it comes to programming
languages. As it does with natural languages, this gives a broader perspective.
But multi-lingualism sometimes makes it hard to compartmentalize language concepts.
Once on a trip to Zurich,
I was having dinner with Erich Gamma, some other Zurich OTIers, and a couple of customers in a
very nice restaurant on the Bahnhofstrasse. My facility with German fills a small thimble,
but as I perused the large menu, with no obvious English to be seen, I realised that I was reading
it rather easily, and thought to myself, “Hmmm, I’m starting to understand German.” Then I
that the menu was in fact bi-lingual, but the second language was French, a language with which I do have some facility.
I suspect that the “coming from x” quotes in David Black’s article are the result of this
difficulty in compartmentalizing by newcomers to Ruby.
A Living Language
Programming languages, like natural languages, survive best when they evolve, this is what
distinguishes live languages from dead ones. Languages die as the number of speakers diminish,
despite revival attempts like Winnie Ille Pu,
Quomodo Invidiosulus Nomine Grinchus Christi Natalem Abrogaverit: How the Grinch Stole Christmas in Latin,
Harrius Potter et Philosophi Lapis (Harry Potter and the Philosopher’s Stone, Latin Edition), or
Ruby is evolving, the core-team isn’t asleep, right now ruby1.9 is the cauldron to which new
potions are being added to brew what will emerge as the next major Ruby revision.
This is another area where Ruby and Smalltalk have similarities.
Smalltalk started as a paper design by Alan Kay to win
a hallway bet challenging his assertion that he
“could define the ‘most powerful language in the world’ in ‘a page of code’.”
Dan Ingalls then actually implemented it in Basic on a NOVA minicomputer, this
which begat Smalltalk-76, which begat Smalltalk-80. Smalltalk-80 was the basis for the
commercial Smalltalks of the pre-Java era, VisualWorks Smalltalk (ParcPlaces commercial Smalltalk-80),
Smalltalk/V which merged with VisualWorks when ParcPlace and Digitalk merged, and IBM/VisualAge
Smalltalk. Squeak is also a child of Smalltalk-80.
Smalltalk started to freeze when it became commercial. We tried hard to forge a standard in
X3J20 which allowed evolution and variation by underspecifying things as much as we could, but
broad enterprise acceptance slowed things down quite a bit.
So it’s exciting to see that Ruby is evolving. I hope that it too doesn’t get bogged down
in it’s success.
Finally getting back to my “Coming from Smalltalk” quote in ruby-talk, I expressed a personal
viewpoint that Ruby would be well-served if the mechanisms of singleton classes, and their use
as metaclasses were made visible and officially documented parts of the language.
If the rationale for not doing so is to preserve “freedom-of-action” in changing the
implementation in future versions, I can understand it, but to used a mixed language
expression, that is a “two-edged katana.” One of the things which Alan Kay told me a long time
ago was that he was disappointed that so few Smalltalkers experimented with changing and
extending Smalltalk by building off of the mechanisms of Class, Metaclass, and Behavior.
In Ruby, despite the fact that knowledge of the equivalent implementation is only known
“sub-rosa,” there is much more such experimentation.
Metaprogramming in Ruby is au courant, and lots of code is being written which depends on
undocumented “stuff.” I have to ask if this, being undocumented that is, is a good thing.
So, to wrap this all up, while I do “come from Smalltalk,” Today, I live in Ruby!
<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.