Forkiness, Standards, and the Balkans

> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of
> Ronald Spengler
> Sent: Friday, 12 February 2010 2:16 PM
> To: [hidden email]
> 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
>
>
>