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.

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.

• 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

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!

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

So far it’s been good. I’ve been popping it open somewhat randomly so far, but plan to take a more structured look at it shortly. I enjoyed the overview of OO as applied to Ruby as well as the section on Rubyisms and idioms.

This is a big book, and looks very comprehensive. I’m looking forward to working through it.

One thing I have noticed… and I don’t know Hal so I’m not sure… is that there are comments regarding programming language issues that seem to indicate a lack of familiarity/awareness of Rubys grand-daddies: LISP & Smalltalk. Comments like “in more recent languages such as Java, memory is reclaimed…”   Both LISP and Smalltalk had garbage collection. In fact that’s where the majority of GC research was done. This however is a minor quibble. This is a book about Ruby, and a good one at that. ]]> http://techblog.daveastels.com/2006/12/22/the-ruby-way/feed/ 0 http://techblog.daveastels.com/2006/12/11/textmate-book/ http://techblog.daveastels.com/2006/12/11/textmate-book/#comments Mon, 11 Dec 2006 06:48:00 +0000 dastels http://techblog.daveastels.com/?p=48 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.

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’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.