Hi,

I found your very e-mail interesting. I myself feel undecided about some
of the bigger issues you have struck upon. In such a young industry, one
which is moving blazingly fast, it is often hard to know what is
required to be successful in the next phase.

Bruce Badger started an ANSI Smalltalk group with the intention of
trying to shape a standard. This might be a little different to the
application standards you had in mind however I believe there some
common ground.

I lost track of it last year but I believe it got some traction. I
believe this is their website, although I'll admit it looks slightly
out-dated:
http://smalltalk.gnu.org/wiki/ansi-smalltalk-project-application

You might be able to entertain some of your ideas alongside the thoughts
of this group.

I have a great fondness for Smalltalk and I would love to see it
continue to thrive in the future.

Regards,
Zak

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Ronald Spengler
Sent: Friday, 12 February 2010 2:16 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: [squeak-dev] Forkiness, Standards, and the Balkans

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