Pharo changing the game
Locked
12
12
 
|
Interesting read (read [2] then [1]), maybe Pharo can change the game ...
bye T. [1] http://www.jarober.com/blog/blogView?showComments=true&printTitle=Balkanization_and_Smalltalk&entry=3443331580 [2] http://www.threeriversinstitute.org/blog/?p=466 -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
pfff.... I should say that kent should have not broken his rule.
Don't blog when you are mad. It gives a bad impression and not only about smalltalk Now what is the solution. get stuck with a ANSI bad standard? get with vendors evolution that are not optimal? what if we do not like VW Namespace ? what if we would like to have first class instance variables? Vendors like parceplace did not really ask the community about the changes they did. Now Seaside is developed on pharo and run on nearly all the dialects so there is a path. It is not easy. Now if would be better to think that what is the future of smalltalk. - scripting - first class instance variables - new look at the MOP - better modules system - ... and we will not to that with ANSI kind of standardization process. Stef BTW this is fun because when I read the bio of Kent on his recent book I do not see Smalltalk mentioned so this is good to know that he is back to smalltalk :) > Interesting read (read [2] then [1]), maybe Pharo can change the game ... > > bye > T. > > [1] http://www.jarober.com/blog/blogView?showComments=true&printTitle=Balkanization_and_Smalltalk&entry=3443331580 > [2] http://www.threeriversinstitute.org/blog/?p=466 > -- > NEU: Mit GMX DSL über 1000,- ¿ sparen! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Torsten Bergmann
here is also what I added to the blog entry
"Improvements can be as simple as that. Now the first level is to communicate with people and let them know that they can improve if they want. So we will probably fix that in Pharo. If somebody provides a fix it can be fix in 2 min. The goal of pharo is to create an innovative Smalltalk that can be use to make business but also to reinvent Smalltalk. And this will not be done without breaking stuff. We do not want to live in a museum. http://www.pharo-project.org for more information and vision statement." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
> 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, ... > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Now why don;t people want a better smalltalk?
>> 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, > ... > >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> Now why don;t people want a better smalltalk?
Sure, everybody wants a better Smalltalk. The ANSI standard does not make scripting impossible, it does not forbid first class instance variables, it does not forbid a MOP or a module system. The ANSI standard only talks about the basic Smalltalk syntax, Collections, Magnitudes, Streams. That's it. I don't think it is limiting in any way. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On Thu, Feb 11, 2010 at 1:28 PM, Lukas Renggli <[hidden email]> wrote:
I think at best it's a curate's 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 definition.
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, comprehensible.
best Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with
Ralph's accidental post about cilantro. Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the Smalltalk ANSI INCITS 319-1998 (R2002) standard? I think this fits into Stephane's comment about moving forward. On 2010-02-11, at 1:51 PM, Lukas Renggli wrote: >> Now why don;t people want a better smalltalk? > > Sure, everybody wants a better Smalltalk. > > The ANSI standard does not make scripting impossible, it does not > forbid first class instance variables, it does not forbid a MOP or a > module system. > > The ANSI standard only talks about the basic Smalltalk syntax, > Collections, Magnitudes, Streams. That's it. I don't think it is > limiting in any way. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Thu, Feb 11, 2010 at 3:26 PM, John M McIntosh <[hidden email]> wrote: Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with I haven't seen much movement since Bruce kicked it off (http://openskills.blogspot.com/2007/10/ansi-smalltalk.html). One of the hurdles was the amount of money ANSI wanted for participation in the standard. I for one couldn't afford it and couldn't see how Cadence, my then employer, would fund it. I think that goes for most of the non-vendor community. See Clay Shirky's TED presentation on institutions for why IMO ANSI is a non-starter. ANSI is irrelevant; it meets it's own needs, not the needs of the Smalltalk community. It can only ever create an obsolete standard. We need to design our own standard that meets our needs. If we can design a standard that is relevant the community as a whole will increasingly adhere to it over time, and as that happens it will become more useful, and, because it is defined by us, can evolve over time, both in content and at a meta level in its standards-making processes.
IMO, moving forward means finding new forms, not putting a new badge on the same old corpse. We need a sci-fi movie not a zombie movie ;)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
In reply to this post by johnmci
On 12.02.2010 00:26, John M McIntosh wrote:
> Er, maybe I'll rant here since it' seems to me this the day for that. Perhaps flavoured a bit with > Ralph's accidental post about cilantro. > > Should we not be talking about the Smalltalk 2010 ANSI proposal? Why the lock in to the > Smalltalk ANSI INCITS 319-1998 (R2002) standard? Because even very basic things like Strings, Symbols and Numbers are a minefield that behave in slightly different ways. And you won't find out until later. I don't want to know how many weeks we wasted on #seasideString. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo changing the game
|
|
In reply to this post by Stéphane Ducasse
On 11.02.2010 21:42, Stéphane Ducasse wrote:
> pfff.... I should say that kent should have not broken his rule. > Don't blog when you are mad. It gives a bad impression and not only about smalltalk > > > Now what is the solution. > get stuck with a ANSI bad standard? > get with vendors evolution that are not optimal? > > what if we do not like VW Namespace ? > what if we would like to have first class instance variables? > Vendors like parceplace did not really ask the community about the changes they did. > > Now Seaside is developed on pharo and run on nearly all the dialects so there > is a path. It is not easy. Because what we settled for is that every vendor has to rewrite a chunk of Seaside. Because we left out all the non basic stuff like files, sockets, os access, graphics, sound, logging, xml parsing, database access, crypto, .... Seaside itself is not portable, it's simply possible to only load the parts which we assume to be portable. So yeah, if you're writing a counter application that's probably portable. But as soon as you start to do Pier or Magritte you can write your own portability classes for everything that Seaside does not need. If you're doing a Pier addon like AudioScrobbler or TopFeeder you're almost guaranteed that it's not portable. Believe when I say I speak from experience and it's really frustrating. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> So yeah, if you're writing a counter application that's probably
> portable. But as soon as you start to do Pier or Magritte you can write > your own portability classes for everything that Seaside does not need. > If you're doing a Pier addon like AudioScrobbler or TopFeeder you're > almost guaranteed that it's not portable. Believe when I say I speak > from experience and it's really frustrating. For the average Smalltalk user the ANSI standard does not matter much. It only matters for those that want to be able to port libraries between Smalltalk dialects. I think making portability as easy as possible should be a major focus of all Smalltalk dialects. There are simply not enough good libraries available in any Smalltalk implementation. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
We are not talking only about syntax.
you mean like nil been able to be put in a set? I would like to have nil as any other object and I hope that this is in the standard. I would like to have immutability for certain classes (string, point....) Does the standard says something about it? My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e I want to live in the 2020 years. Stef >> So yeah, if you're writing a counter application that's probably >> portable. But as soon as you start to do Pier or Magritte you can write >> your own portability classes for everything that Seaside does not need. >> If you're doing a Pier addon like AudioScrobbler or TopFeeder you're >> almost guaranteed that it's not portable. Believe when I say I speak >> from experience and it's really frustrating. > > For the average Smalltalk user the ANSI standard does not matter much. > It only matters for those that want to be able to port libraries > between Smalltalk dialects. I think making portability as easy as > possible should be a major focus of all Smalltalk dialects. There are > simply not enough good libraries available in any Smalltalk > implementation. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
another point, what about automatic initialize?
At one point in the past VW (eliot) was really for introducing it in VW since it would not cost anything in presence of the JIT. Dolphin people did it on Model but they told me that if they could they would remove it. and this is a really important change to lower the entry level and burden of newcomers. Now because of "compatibility" we have to code without it for me this is a drawback. Do we imagine Seaside could have been invented by VisualAge Smalltalkers (no punt intended)? No because there is no thisContext!!! Sad! My point is what is the price to pay to compatibility. Stef On Feb 12, 2010, at 8:02 AM, Lukas Renggli wrote: >> So yeah, if you're writing a counter application that's probably >> portable. But as soon as you start to do Pier or Magritte you can write >> your own portability classes for everything that Seaside does not need. >> If you're doing a Pier addon like AudioScrobbler or TopFeeder you're >> almost guaranteed that it's not portable. Believe when I say I speak >> from experience and it's really frustrating. > > For the average Smalltalk user the ANSI standard does not matter much. > It only matters for those that want to be able to port libraries > between Smalltalk dialects. I think making portability as easy as > possible should be a major focus of all Smalltalk dialects. There are > simply not enough good libraries available in any Smalltalk > implementation. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
<summary>My point is that the ANSI standard is **not restrictive**. It
does **not prevent** you from inventing a better future. It allows you to do whatever you like. I argue to not break the ANSI standard unnecessarly, but support it and avoid further fritting of the different Smalltalk implementations. If possible, we should also try to adopt APIs of existing functionality in other dialects.</summary> > you mean like nil been able to be put in a set? > I would like to have nil as any other object and I hope that this is in the standard. ANSI does not say anything about that. We are free to do whatever we want. > I would like to have immutability for certain classes (string, point....) > Does the standard says something about it? ANSI does not say anything about that. We are free to do whatever we want. However, since VW already implements immutability, it would probably be beneficial to chose an API that is close to the VW implementation. > My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e > I want to live in the 2020 years. The ANSI standard doesn't say anything about Exceptions or Pragmas either. - Exceptions: Today all Smalltalk platforms support the same exception API, mainly due to the fact that Seaside makes heavy use of some very specific exception features like resumable exceptions, exception sets, nesting exceptions, etc. VA had a very different implementation. Nowadays they do support basically the same protocol as Pharo, thanks to the tests we wrote for Seaside. - Pragmas: In the beginning only VW had pragmas. I implemented the same API for Squeak 3.9. Today all existing Smalltalk platforms support these kind of pragmas. Pragmas and exceptions are suddenly portable, what is a great win. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Feb 12, 2010, at 10:56 AM, Lukas Renggli wrote: > > - Pragmas: In the beginning only VW had pragmas. I implemented the > same API for Squeak 3.9. Today all existing Smalltalk platforms > support these kind of pragmas. Pragmas and exceptions are suddenly > portable, what is a great win. > It is interesting to note that of course, after this was added to 3.9, there was someone *very hard* arguing that adding Pragmas was a very dumb idea... Who that person was is left as an exercise to the reader of course ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> It is interesting to note that of course, after this was added to 3.9, there was
> someone *very hard* arguing that adding Pragmas was a very dumb idea... > > Who that person was is left as an exercise to the reader of course ;-) Hint: FFI has its own proprietary hardcoded pragma format. It unnecessary complicates the compiler even when not loaded. Not to mention that it breaks all tools that have their own parser, such as RB for example. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
On Feb 12, 2010, at 10:56 AM, Lukas Renggli wrote: > <summary>My point is that the ANSI standard is **not restrictive**. It > does **not prevent** you from inventing a better future. It allows you > to do whatever you like. I argue to not break the ANSI standard > unnecessarly, but support it and avoid further fritting of the > different Smalltalk implementations. If possible, we should also try > to adopt APIs of existing functionality in other dialects.</summary> Yes >> you mean like nil been able to be put in a set? >> I would like to have nil as any other object and I hope that this is in the standard. > > ANSI does not say anything about that. We are free to do whatever we want. it will really break your code in other dialect. >> I would like to have immutability for certain classes (string, point....) >> Does the standard says something about it? > However, since VW already implements immutability, it would probably > be beneficial to chose an API that is close to the VW implementation. Yes this is the idea. I hope the interface is good. >> My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e >> I want to live in the 2020 years. > > The ANSI standard doesn't say anything about Exceptions or Pragmas either. > > - Exceptions: Today all Smalltalk platforms support the same exception > API, mainly due to the fact that Seaside makes heavy use of some very > specific exception features like resumable exceptions, exception sets, > nesting exceptions, etc. VA had a very different implementation. > Nowadays they do support basically the same protocol as Pharo, thanks > to the tests we wrote for Seaside. > > - Pragmas: In the beginning only VW had pragmas. I implemented the > same API for Squeak 3.9. Today all existing Smalltalk platforms > support these kind of pragmas. Pragmas and exceptions are suddenly > portable, what is a great win. I agree. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
I agree with you lukas
but my point is that we should be also cautious about not limiting ourselves because of some reasons. I prefer to see a good idea spread in other smalltalk than abandon/not implemented because not compatible. > <summary>My point is that the ANSI standard is **not restrictive**. It > does **not prevent** you from inventing a better future. It allows you > to do whatever you like. I argue to not break the ANSI standard > unnecessarly, but support it and avoid further fritting of the > different Smalltalk implementations. If possible, we should also try > to adopt APIs of existing functionality in other dialects.</summary> > >> you mean like nil been able to be put in a set? >> I would like to have nil as any other object and I hope that this is in the standard. > > ANSI does not say anything about that. We are free to do whatever we want. > >> I would like to have immutability for certain classes (string, point....) >> Does the standard says something about it? > > ANSI does not say anything about that. We are free to do whatever we want. > > However, since VW already implements immutability, it would probably > be beneficial to chose an API that is close to the VW implementation. > >> My point is that I'm in favor of compatibility but not at the cost of been kept in the 80e >> I want to live in the 2020 years. > > The ANSI standard doesn't say anything about Exceptions or Pragmas either. > > - Exceptions: Today all Smalltalk platforms support the same exception > API, mainly due to the fact that Seaside makes heavy use of some very > specific exception features like resumable exceptions, exception sets, > nesting exceptions, etc. VA had a very different implementation. > Nowadays they do support basically the same protocol as Pharo, thanks > to the tests we wrote for Seaside. > > - Pragmas: In the beginning only VW had pragmas. I implemented the > same API for Squeak 3.9. Today all existing Smalltalk platforms > support these kind of pragmas. Pragmas and exceptions are suddenly > portable, what is a great win. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
>>
>> It is interesting to note that of course, after this was added to 3.9, therae was >> someone *very hard* arguing that adding Pragmas was a very dumb idea... >> >> Who that person was is left as an exercise to the reader of course ;-) > > Hint: FFI has its own proprietary hardcoded pragma format. It > unnecessary complicates the compiler even when not loaded. Not to > mention that it breaks all tools that have their own parser, such as > RB for example. I guess I know who you are talking about. ;D PS: do you know if FFI declarations are compatible with VW ones or they are just funky? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |