[squeak-dev] Forkiness, Standards, and the Balkans

Ronald Spengler ron.spengler at gmail.com
Fri Feb 12 03:15:41 UTC 2010


Warning: this post is entirely about philosophy, and is around 10
paragraphs long.

So I couldn't help jumping in on this topic, which came up again in
the context of Eliot's post.

Andreas: Balkanized is totally the word!

So the first statement is an opinion of mine: Smalltalk needs a new
standard, but won't be ready for one for some time.

Second is both an observation and an opinion of mine:

Smalltalk, as a research platform, was *designed* to evolve, and
outside of PARC, evolve == fork. I think forks are not just okay,
they're fantastic. They are resources from which new ideas can be
gleaned.

It reminds me a bit of the idea that every working copy of a Git
repository is effectively it's own branch. There are really only two
ways to build ST apps (if this is naive, please call me out on it.)
You can write new code atop the existing system, or you can mutate the
existing system.

The latter is dangerous, and I think it's only dangerous because it's
powerful; eToys might have been much harder to build in a system that
didn't support the evolutionary approach. The cost though, was that
eToys became very difficult to decouple from the "underlying system"
as a result of this approach. That the first part of this work has
been accomplished in Trunk is to me proof that the new community
development model has been an incredible success.

The former approach, as used by Seaside, brings me to my point. End
users just want to run their favorite applications. The end users of a
programming environment are programmers who want to run things like
Seaside.

Here's the kicker: the Balcanization of the underlying system will
*only* be mitigated by the requirements of the applications which
become dominant on the platform. In otherwords, the likes of Seaside,
Magma, SUnit, eToys, etc., etc., will ultimately inform the community
about what tomorrow's Smalltalk standard should look like.

What we really need is for the *applications* to agree about the shape
of the underlying system (as it is plastic and mutable by design,) but
our experience leads us to believe the opposite: our experience with
closed, static systems.

While I say this in all seriousness, my tongue is also halfway lodged
in my cheek when I say: The closest thing we have to a modern
Smalltalk standard is the document on the Seaside website which
explains best practices around making sure your Seaside app works as
well on Pharo as it does on Visual Works.

To the reader: these are my thoughts, and while I enjoy them very
much, my relationship with them in not religous. In other words, if
you didn't enjoy reading them, it's a shame you read all the way
down:)

-- 
Ron



More information about the Squeak-dev mailing list