I understand what Ian Bicking was saying here - and yes, I know it's an ancient post from 2004 - but it serves as a launching point for a few things I wanted to say anyway :)

There's also the syntax -- it's not a bad syntax, but it's not the dominant syntax, and it clashes badly with the dominant syntax. It's hard to phrase one in terms of the other (i.e., they do not map to each other). The syntax is only a small part of it, but it's one of many things where Smalltalk reinvents everything from the ground up.

But there's a wee problem: Smalltalk came first. We didn't reinvent everything; the rest of the field went in a different direction from where we were. The end result might be the same, but I feel compelled to point that out :) This needs some comment too, however:

But it's more than just ravioli code. Smalltalk encourage a style where there's often no program at all. Everything is developed in a persistent environment where there's little distinction between code and infrastructure. You open a workspace, set up some objects and tie them together, then trigger a key method that sets it in motion. But as a result the program is hard to distinguish from your one-time workspace. Zope has a lot of the same problems, and interestingly this article advises that you follow a methodology that "Devalues the data that goes into any given ZODB storage," due the challenge of cooperating in such an environment. I know there exist better tools for Smalltalk collaboration than for Zope. But they are generally proprietary, so I dismiss them :P (I don't live in a Smalltalk world either, so please don't ask me to choose to abandon my existing tools)

Well, I know where he's coming from with that, but we've steadily been chipping away at that problem in Cincom Smalltalk for some time now. When the image starts up, there's a standard way to hook in and tell the system "my application starts here" - and the packaging tool uses it. I've written a couple of decent sized apps in the product now (BottomFeeder and Silt), and I understand this concern.

The bigger issue is the "separate environment" one - and interestingly enough, we addressed that last week on Industry Misinterpretations (and I just posted on a related topic a few minutes ago).

It has crossed my mind more than once as CST Product Manager that arrogantly telling everyone that all their tools are teh suck and they should just use the image is off-putting. We may not be able to get you to visit the Balloon, so instead, we intend to bring the Balloon to you. Over the next little while, we will be moving closer to where average developers like to sit - feel free to give us some helpful nudges along the way.

Technorati Tags: development