So there's been a lot of buzz about Bob Martin's "What killed Smalltalk could also kill Ruby" talk. The problem is, his talk started with misconceptions, and pretty much plowed forward from there. Early on, he stated that "Squeak is pretty much an academic thing now". That's kind of amusing; it's actually pretty hard to find academic use of any Smalltalk - Squeak or otherwise. Even "back in the day", Smalltalk didn't really have that big an academic presence.

Early on, that had to do with the lack of a free implementation, and the insistence on the part of vendors (ParcPlace being very bad this way) of charging universities to use Smalltalk for teaching. That was a dumb idea, and it did an awful lot of damage.

Getting back to his assertions that Squeak (and Smalltalk in general) is isolated to academia, I think Bob needs to subscribe to the Seaside mailing list. Sure, it's not nearly as active as some of the Ruby groups you'll find out there, but there are tons of people active in that community, and there's a lot of commercial work going on using Seaside - in multiple Smalltalk dialects. The coolest thing about Seaside is that it's the first thing that's really gotten all the vendors (and the open source offerings, Squeak and GNU ST) onto the same page.

It took awhile in the talk before he got back on point (which is not to say he wasn't interesting), but then I heard something fascinating - he related a statement from Ward Cunningham such that "it was too easy to make a mess" compared to other languages, where messes would be more obvious (in terms of build time, for instance). Well. I've seen plenty of bad code in Smalltalk; heck, I've written plenty of bad code in Smalltalk. But here's the secret, and it's one that Bob - and I guess Ward - missed:

It's much easier to dig your way out of a mess in Smalltalk than it is in anything else.

I'll give you a live example: this blog server. I originally had all of the storage code sitting in a "god object" called "BlogSaver". It was convoluted. It was a pain in the neck to modify. Adding, or god forbid, refactoring anything, was a nightmare. But...

Not only did I refactor it all, I did it without taking the server down, by patching the server while it was running. And - sorry to break this to you, Bob, but no, I didn't have tests for that stuff. Sure, I should have tests, and it likely would have helped. But you know what? I was able to dig my way out of that hole, patch the server on the fly with the update, and move along... and it took me oh, I think a couple of days. In fact, it didn't come down after that until there was a major power outage in Cincinnati (since then, Cincom has installed backup generators).

I have more bad news for Bob on this theory that a lack of proper testing will kill a community. Were that true, C, C++, Java, and C# would all be failures. And no, big messes in those languages aren't prevented by lengthy compile times and pain, either. There are lots and lots of absolutely enormous systems built in those languages, and many of them were (and are) being built without TDD. Sure, it's painful - I remember my days as a C programmer well enough :) The reality is, people build messes without regard to the language, and the relevant point is which language and tools make escape from the mess easier.

Here's another thing, too - in a quick toss off, he talked about the time people spend in debuggers. Oh boy, the common "debugging is bad" thing. Just a few minutes ago, I was working on my Facebook interface. Sure, I could read the doc, write a test that expects the stuff coming back from that, and... discover that the doc is way less useful than I'd like it to be. On the other hand...

I could just not write the full code at all, let the thing break, and ponder the response in the debugger. While there, I can write the code based on what actually came back, and watch it work. Rinse, Repeat for each one of them

Yes, tests are useful. But, the debugger is not something to be feared. Rather, it's a great tool to be used in order to have the computer do all the memory work for you. I can get a lot more done by working with decent tools like the Smalltalk debugger than I can by assuming the doc is good and writing tests that just help me a whole lot less than you might think.

On arrogance, Bob has a point - back in the 90's, Smalltalkers really were arrogant - I say this as one of the people who displayed a lot of arrogance back then. Then again, C++ developers were pretty arrogant too (go search the usenet archives if you don't believe me). Trust me - the arrogance ran in both directions :)

The place Bob takes this point is truly absurd - that Smalltakers didn't want to deal with the outside enterprise back then. I know where he gets that idea from, but the reality is, Smalltalk's problem was pretty much the exact opposite: all we had were enterprise projects. There was virtually no activity going on outside the enterprise, because the Smalltalk vendors set pricing and licenising so as to keep it that way. if you were an individual developer, it was easy to get a C, C++ (later Java) set of tools - but it was well nigh impossible to get ahold of Smalltalk. It wasn't until the late 90's that Squeak came out, and VisualWorks (and later ObjectStudio) didn't come out in non-commercial versions until a year or two later.

So to summarize - I'd have to say that Bob made a number of assumptions that I just don't think hold up. Smalltalk had problems in the past (and continues to have some of them now) for a few simple reasons:

• Through the late 90's, it was just too hard to get Smalltalk unless you were an enterprise developer paying big bucks
• Smalltalk asks you to change a number of things: use our tools (not your editor), use our SCM (not things like SVN, et. al.), use a syntax that isn't C-like
• Use a non-mainstream, niche language and stack

Notably, Bob didn't bring up any of those. I'm not wearing rose colored glasses; I realize that we do ask you to try new and different things when you pick up Smalltalk. Instead, Bob focused on things that don't really have a lot to do with what caused Smalltalk grief - meaning, his points really don't have much to do with where Ruby's going, either.

Technorati Tags: ruby, railsconf, bob martin