This post originated from an RSS feed registered with Python Buzz by Ian Bicking. Original Post: Where Smalltalk Went Wrong 2 Feed Title: Ian Bicking Feed URL: http://www.ianbicking.org/feeds/atom.xml Feed Description: Thoughts on Python and Programming. Latest Python Buzz Posts Latest Python Buzz Posts by Ian Bicking Latest Posts From Ian Bicking

I got a couple reactions to my last post. As I said, it was half baked, which is to say that I didn't know my conclusion when I started writing the post, and I didn't rewrite everything that came ealier once I realized my conclusion. So they labelled me uninformed, rather than merely disorganized.

I did a fair amount of Smalltalk programming at one time when I was in school. I drank the Kool Aid, I understood the philosophy, I read the literature. I only used Squeak, and I am aware that other systems offer more tools. Those other systems are all proprietary, and sadly the Smalltalk community (for the most part) is not a Free Software kind of community. I'm sure cool Open Source things happen (and Squeak is certainly cool), but all the most advanced (most "modern") features seem to be proprietary. Maybe it's not fair to dismiss them because of that. But I am not fair and I dismiss them because of that. And I offer no apologies for this.

Now, working back from my conclusions:

Smalltalk offers no path from here to there. Smalltalk has a lot of nice things about it. A lot of them involve different ways of thinking about programming and thinking about the nature of programs themselves. 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. Much of it is successful, much of it is particularly elegant when viewed as a whole. But you take it or you don't, it's very hard to go part way. That's a huge flaw.

Smalltalk devalues the idea of a "program". The Smalltalk image is a lively set of interacting objects, like agents in a community. It often seems almost spontaneous the way they interact, and it's like they are all peers with no center. Ravioli code is often the result.

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)

Still, the damage that ravioli code causes should not underestimated! A quick definition from the wiki page:

In the structured programming world, when things got messy your code became SpaghettiCode. Everyone knows what SpaghettiCode is. It has been said that with objects you get RavioliCode: thousands of little classes everywhere and no one knows how to find the places where things really happen.

Again, ravioli code doesn't offer a path from here to there. "Here" in this case is the ignorant programmer first introduced to the code, "there" is the same programmer successfully making whatever change they need to make. In my experience with ravioli code there is a gestalt which is arrived at in a sudden realization, when the picture comes together. But before you reach that realization you find yourself in a murky set of code where it is difficult to predict effects or determine causality, and you seldom know how far away you are from the gestalt realization.

This is some of what I was referring to when I said that Smalltalk programming styles led to too many frameworks and not enough libraries -- a framework requires you to take on a certain metaphor of execution, to adapt your thought process to the framework instead of adapting the program to your thoughts. Frameworks can be worth it, but they always exact a significant cost.

The lack of decent syntactic support for simple imperative programming (i.e., functions) also doesn't help Smalltalk be any simpler or more accessible.

I've become distracted from my main point here: Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects. Maybe we'll get to that world of objects, but there needs to be a path leading there that starts here.

So maybe my new conclusion is that Smalltalk is uncompromising in its vision, but the world is not ready for that vision. I say "the world is not ready" from an empirical basis, not as a judgement. Nor do I judge the world or rail against its ignorance for not embracing a good thing. The world is what it is, we are where we are. We can push the world in the direction we choose, but we can only move it, not wish it elsewhere.

(Maybe that's not fair -- we as individuals can leap about as we wish, for our minds are light; perhaps this is the nature of invention; thus my conclusion is self-doubting)