In his RailsConf keynote Bob Martin channeled Ward Cunningham to say that Smalltalk died because “It was too easy to make a mess”.

Whether Smalltalk is dead is the subject of much debate. Technically it’s not. There is ongoing development on the language and tools (notable by Cincom). But for all intents and purposes, it is no longer a commercially viable language. That said, it’s cool, and was a great context in which to learn OO. For that I am forever grateful to it.

I, personally, don’t think that “being easy to make a mess” was the cause of Smalltalk’s downfall. Sure, it was easy… but it’s easy to make a mess in any language. I have to agree with James Robertson that Smalltalk makes it easier to clean up your messes.

I was a serious Smalltalk user ‘back in the day’.. in the late 80s & early 90s: ObjectWorks, VisualWorks, Digitalk. I used it both in industry (some early CDROM shrinkwrapped products as well as client server) and academically (for my MSc thesis work). It was a wonderful language and environment. I saw firsthand, a few things that I believe lead to it’s demise:

• The unfamiliarity of the language and environment,
• The incompetence of the company tasked with commercializing it (ParcPlace), with their ridiculous licensing/royalty demands, and
• Arrogance, but not so much of the community, but of the environments themselves. It was beautifully cross platform, but at the expense of a truly native environment. In fact it was quite late into the game that you had windows out on your desktop instead of in it’s own self-contained world or even with simulated platform look & feel. As I said, that changed, but I believe it was too little, too late. There were some native implementations that were reasonably good.. but none approached the power of those descending directly from the PARC codebase. And Squeak, the shiny new smalltalk, goes back to that we-are-the-world arrogance.

So.. no… I don’t think what “killed” Smalltalk will kill Ruby. We’ve learned a lot since the 80s… a lot about how to keep a system healthy. The TATFT attitude is part of it. Notice I said attitude, and not practice.

We still can learn a lot from Smalltalk, specifically from it’s toolset. When we finally have good, useful Ruby IDEs they won’t look like Java IDEs. They’ll look like Smalltalk IDEs.

So… Smalltalk dead? Yes, no, does it matter? Smalltalk lives on in Ruby.

As I’ve mentioned on Twitter & Facebook, I’m back to doing Ruby & Rails fulltime.

Joining Google took me out of the Rails community & largely out of the Ruby community. At least until very recently when I joined a Rails project (yes, at Google.. who’da thought).

As noted on my blog last spring, I had the rug pulled out from under me with a sudden onset of diabetes.

With all that I pretty much pulled an Austin Powers and went into cold storage for a year & a half.

Well, I’ve thawed out and am back at it… Ruby, Rails, and hanging with peeps at conferences. Look for me on speaker lists before too much longer.

After GoGaRuCo and RailsConf, I’m back, motivated, and enthused like never before.

Well, RSpec is doing well. A couple things of note recently:

• part of the install on hivelogic’s rails install instructions
• clear majority favorite on a recent twtpoll:
  
  
• with merb being rolled into Rails, there’s speculation that RSpec will be supported by Rails out of the box… that’d be cool

My coworker, Paul Zabelin, posted here on some ideas that we’ve been experimenting with using RSpec stories and JRuby.

I’m sitting in the airport in Charlotte, on my way home from RubyConf2007.

What a fabulous conference. This the most enjoyable conference I’ve been to in a very long time.

There was so many great talks/ideas/projects, it’s hard to pick highpoints, but these stand out for me (in no particular order):

• drnic for some very cool tech and sheer entertainment value.
• Laurent Sansonetti for a jaw-dropping talk/demo about what’s possible with the latest Ruby love from Apple.
• Charlie & Tom on JRuby
• Evan on Rubinius… that is one cool project… sign me up
• and, of course, Matz’s keynote

It’s no wonder the Ruby community is “nice people” when we have someone like Matz at the head of it.

Maybe as rewarding, or even more, than the tech & talks was seeing old friends again and meeting others face to face that to date I’d only known online.

It was an awesome weekend, and I’m eagerly looking forward to the next Ruby conference!

Here’s an article I wrote a while ago but didn’t get around to releasing.  Enjoy. 

Describing Equivalence Classes in Ruby with RSpec

Since writing that article, I’ve made good use of the code. Here’s an example of it in action: grouping the cards in a deck into their types. A second method then uses those groups to reassemble the cards into an ordered list.

  CARD_TYPES = ['basic land', 'land', 'creature', 'artifact',
                'enchantment', 'sorcery', 'instant', '']

  def maindeck_cards_grouped
    maindeck_cards.equivalence_classes(*CARD_TYPES) do |card, the_type|
      card.magic_card.card_type.downcase.include?(the_type)
    end
  end

  def maindeck_cards_ordered
    cards_by_class = maindeck_cards_grouped
    (CARD_TYPES.inject([]) {|cards, type| cards << cards_by_class[type]}).flatten
  end

TextMate  Power Editing for the Mac James Edward Gray II

I’ve read a couple of the beta versions of this book from the Pragmatic Press. It’s good. If you are using TextMate, you should have this book. The current documentation for TextMate is pretty lame. This book does an admirable job of filling that void.

The writing style is easy to read, and is quite information dense. Content goes from basic cursor movement all the way to custom language support. It’s a good read, and packed with valuable and useful information.

That said, while I’m impressed with the book, I’ve become less and less impressed with TextMate itself. It’s a wonderful text editor and a sweet Mac app, and will long have a place on my dock. But for serious programming, it doesn’t cut it. I’ve gone back to “old faithful”… my constant companion from from way back.. GNU Emacs. If you’re doing serious programming, there’s nothing like Emacs.

Nice post by Defiler on RSpec:

RSpec On Rails:

RSpec is mere days away from a new release with greatly improved Rails support.

Since people are currently paying me to write Rails code, rather than plain old standalone Ruby (hint hint), I’ve been waiting for these features before making serious use of RSpec.

As an exercise, I ‘ported’ the acts_as_authenticated controller tests to RSpec. The results were fairly interesting. Subjectively, I find it more readable than the test/unit version. Objectively, one of the test/unit test cases doesn’t get run because there are two methods with the same name.

…

So far, so good. Anyone who thinks that RSpec is ‘only’ about a different set of terminology should give it a serious try first.

(Via ~:caboose.)

I just finished working on notes for a Java5/jUnit4/TDD tutorial. This is a version of a Ruby/rSpec/BDD tutorial that I recently wrote. The app is a simple “guess the secret code” game. The contexts of the two are the same other than where language differences make themselves known. Primarily this is the in code. So, two codebases, same set of tests/specs, same functionallity.. 100% same. Both written by me… which, IMO, means pretty clean, tight code.

I’ll be looking over the code in the next few days, and probably blogging anything interesting that I find. But I’ll start off with this comparison… just how much difference is there in the amount of code?

So, in Java there is almost 50% more code. In this case.. a simple app… that’s only about 5000 characters… but what about a bigger app? That will add up fast. I can’t help but wonder if that comparison will be linear with the size of the app. Somehow I doubt it.