Platform surface area

Don Box via Patrick Logan:

Contain the growth of platform surface area - it's easy to design a complex framework - it's much harder to design a simple one. Now factor in ~30-50% growth in functionality with each release and my ears start to bleed.

Patrick raises the flag for Smalltalk, and notest that it took ten years to get to the current version, Smalltalk-80. Which is now over 20 years old an substantially unchanged. There's an interesting question in there about how much of that stability is from it being "just right", and how much from the fact that once it's out there, it's harder to change. The balance is well over in favour of the former in Smalltalk's case. So "release early, release often" isn't necessarily the right way to go with language development?

[While I'm here, Patrick links the Google directory Smalltalk implementations page, which is an impressive statement in itself.]

So how long will it take to build a true modelling platform? Have I got the staying power to "hoe that row"? How can one do so without getting trapped into releasing half baked ideas, first attempts which do little more than tell you how not to do it?

And what underlying platforms should it be built on?

Comments

[BillHarvey]

This isn't just a sad old man who doesn't talk to his son enough! Hamish and I started playing with SmallTalk when he was 12 and still called David and I was a boy of 40. We both loved it, though I think he understands why better than I do.

One of the joys of SmallTalk was the speed of the development cycle. You could have an idea, make something that worked and chase it round a couple of circles before realising what was wrong and junking it for a better model. If what you are trying to do is to design something NEW, what you need is tools that let you play and throw away. Most software tools are designed for building business software, in which it is possible to plan in advance what you want and how to get it. If you only have half an idea what you want, you have to be able to play with ideas. That isn't the same as releasing stuff, of course.

The real problem, if you want to change the world is finding a sponsor prepared to support a year or two of silence. Xerox Parc did that and Smalltalk dropped out. I fear that these days we may all be just too greedy.

[Hamish]

You know it was when I was twelve? I've wondered a few times how old I was. I had already been exposed by that time to a rather more static form of object oriented programming on the form of the first OO versions of Turbo Pascal, but hadn't spent much time there. I also demonstrated way back the first time you paid me to program the ... er ... skill of being unable to just use flawed libraries to do the job that needs doing, rather insisting on trying to replace them with less flawed ones. How much time have I wasted that way in my life?

[Bill Harvey]

Sorry, I'm being slow. No more than most good programmers I'm sure.

[Patrick Logan]

I think the original Smalltalk team did release early and often. But they were in the advantageous position to radically alter their design between revisions.

A commercial product like you say, once it is out there is hard to change. So it depends on what "release" means.

One product released to a small number of customers can change more easily than a suite of products (like the dotnet f/w) released to the entire world.

[Hamish Harvey]

I wonder how much freedom being open source buys?

There is a certain amount of self regulation, I suppose. Just releasing early doesn't constrain you at all; no promise is implied. If what is released is rough, and frequent releases follow, then it will be clear to all that stability is not what they are getting here, now.

And having the early adopters -- who can be expected to understand how it goes -- involved should help make the result practically useful as well as an interesting academic exercise.

[I now wait for Dad to pick me up for abusing "academic"; I protest that an academic exercise need not, but can, be practical. The goal is to make sure that what I am doing is both interesting *and* practical.]