<br><br><div class="gmail_quote">On Thu, Feb 11, 2010 at 1:28 PM, Lukas Renggli <span dir="ltr"><<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> get stuck with a ANSI bad standard?<br>
<br>
</div>The ANSI standard is not bad. It is minimal, maybe too minimal? But it<br>
does not forbid anything like #and:and: or Traits. The ANSI standard<br>
gives a minimal common dominator. It is absolutely essential to<br>
projects like Monticello, OmniBrowser, SUnit, Seaside, Magritte, Pier,<br>
...<br></blockquote><div><br></div><div>I think at best it's a <a href="http://en.wikipedia.org/wiki/Curate%27s_egg">curate's egg</a>.</div><div><br></div><div>First it's hard to browse and lots of the names are un-Smalltalky.</div>
<div><br></div><div>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 definition.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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. </div>
<div><br></div><div>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, comprehensible.</div>
<div><br></div><div>best</div><div>Eliot</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Now Seaside is developed on pharo and run on nearly all the dialects so there<br>
> is a path. It is not easy.<br>
<br>
</div>Because we strictly adhere to the ANSI standard and because we have<br>
our own platform layer called Grease.<br>
<br>
<a href="http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html" target="_blank">http://blog.fitzell.ca/2010/01/easing-compatibility-with-grease.html</a><br>
<br>
Lukas<br>
<font color="#888888"><br>
--<br>
Lukas Renggli<br>
<a href="http://www.lukas-renggli.ch" target="_blank">http://www.lukas-renggli.ch</a><br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Pharo-project mailing list<br>
<a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
<a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
</div></div></blockquote></div><br>