I’m so glad Avi Bryant jumped into this discussion. (I was hoping he would.)

The story so far (for the probably 99% of my readers who don’t read a lot of Smalltalk blogs): Avi and I had a discussion last year at OSCON about Ruby and Smalltalk, and Rails and Seaside. Avi was once a Ruby guy, but switched to Smalltalk (but he’s still friendly to the Ruby crowd). I’m currently a Ruby and Rails guy, but I’ve evangelized Seaside rather extensively.

During our discussion, we talked about the different tradeoffs that the two communities make.

I related that story to Neal Ford, which helped him to understand some things he’d been wondering about, which led to these blogs. In a vastly oversimplified nutshell: Ruby has some strengths that Smalltalk is missing, because it gives you a place to put all your stuff. (Please note that this does not imply that Smalltalk is fundamentally inferior to Ruby. I believe Smalltalk, in turn, has other strengths that Ruby is missing.)

James Robertson took issue with Neal’s blog, but gave no real evidence to back up his point. I was getting a bit frustrated with the “all heat and no light” nature of the discussion, until Avi saved the day by explaining the Smalltalk way of doing things.

I have to say that I think to some degree Avi confirms Neal’s and my point: Ruby provides a ready-made place for stuff like “has_many”, whereas in Smalltalk, to provide similar functionality while preserving the “statement of intent” (as we’ve been calling it) the tool has to build a place for that statement. Which is fine, but it seems to me that “to make the generated code round-trippable,” as Avi says, adds extra complexity to building such tools.

Again, this is not to say that the Ruby way is necessarily superior. These different approaches reflect different tradeoffs. That’s the conclusion Avi and I reached during our chat last year, and we were both happy to agree to disagree. Smalltalkers tend to prefer generating the methods directly, because that way they can get the most value out of their terrific toolset. And Alan Knight (in his comment on James’ blog) definitely prefers generating the methods in-place, so that the full API will be visible to developers. We Rubyists, on the other hand, having generally crappy tools, are free to do things in a way that even rdoc doesn’t understand, and I for one like the fact that all those boilerplate methods aren’t physically cluttering up my source code. You pays your money and you takes your choice.

My interest in discussions like this is not to have a language war, and especially not between Smalltalk and Ruby. (There’s brother against brother for you.) The point is to learn from each other and, through learning about the other, to understand more clearly the strengths of both approaches.