[squeak-dev] Re: [Pharo-project] Pharo changing the game

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 11 22:05:08 UTC 2010

On Thu, Feb 11, 2010 at 1:28 PM, Lukas Renggli <renggli at gmail.com> wrote:

> >        get stuck with a ANSI bad standard?
> The ANSI standard is not bad. It is minimal, maybe too minimal? But it
> does not forbid anything like #and:and: or Traits. The ANSI standard
> gives a minimal common dominator. It is absolutely essential to
> projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier,
> ...

I think at best it's a curate's egg<http://en.wikipedia.org/wiki/Curate%27s_egg>

First it's hard to browse and lots of the names are un-Smalltalky.

Second, it doesn't standardize Smalltalk, only its core libraries.  It's all
very well to specify a minimal library, but to leave the vast array of
reflective facilities unspecified is, for Smalltalk, a huge mistake.  The
standard, if it wasn't an attempt at a rubber stamp by the vendors, have
included optional sections.  So that were an implementation to include
execution reflection (thisContext) the standard could define what that
looked like, but not require an implementation to include execution
reflection.  The same goes for run-time class creation and method

Third, it isn't an extensible standard. If it were forward looking the
standard would have put in place some mechanism for adding to the standard
(such as a voting scheme) so that over the years excellent extensions to the
base library such as beginsWith: first: et al could be added.  It would also
have defined the kind of versioning facilities that people need to know what
version of the standard they can expect (we recently discussed something
similar in the context of Metacello and Grease on the Pharo list).  There
needs to be a global object which can be queried for version information,
what core facilities exist and which don't, etc.  All of these lacks really
hurt projects like Grease (there have been numerous attempts over the years)
because there is a raft of dialect-specific code, and one either has to
introduce a new global (SmalltalkVersion) or hang the functionality off
existing dialect classes (Smalltalk, System, etc, etc).

We need a standard that standardises Smalltalk, not C with Smalltalk syntax.
 Smalltalk is reflective, dynamic and evolves rapidly.  That implies a
different kind of standard, not overseen by ANSI, whose objective is
self-preservation, not standardisation (see Clay Shirkey; do you know how
much money ANSI want for a standards process??).  We need a living standard
that can evolve.

I know it is impractical, if not impossible, to standardize the
language-development side of Smalltalk, a standard that could extend to e.g.
Newspeak.  But this is also pointless.  No one needs a standard for blue
plane.  But we have a string need for a standard that standardises Smalltalk
as it is used in the industry; one that supports systems like Seaside.
 There /is/ mutual self-interest in a standard that can help convergence in
agreed-upon functionality, that is open, and that can evolve at the right
pace (not too fast, or it has no value, not too slow or it has no
relevance).  Some bright minds at universities that use VW, Pharo, Squeak
and VisualAge could do some really interesting work here.  The dialects,
including those from the vendors, would surely be willing to pitch in if the
standard was what Smalltalk is, malleable, incremental, open,


> Now Seaside is developed on pharo and run on nearly all the dialects so
> there
> > is a path. It is not easy.
> Because we strictly adhere to the ANSI standard and because we have
> our own platform layer called Grease.
> http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html
> Lukas
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100211/a7cbfab3/attachment.htm

More information about the Squeak-dev mailing list