Re: [Pharo-project] Pharo changing the game
Locked
Re: [Pharo-project] Pharo changing the game
 
|
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
|
|
|
I strongly disagree with Eliot's view of the ANSI standard and the role it can play in the future of Smalltalk. I've spent enough time around standards to know that a good standard is characterized by all of the things that it does not characterize. Ideally, there should be just enough defined to allow interoperability, without undue constraint upon implementation strategies.
Historically, Smalltalk has been defined by its operational definition. From it's first incarnation, it was a working system in which new versions of itself could be gestated. This is great. The reflective design of the runtime makes it a perfect playground for experimentation and learning. Not too surprising since it was the brainchild of the learning research group at Xerox. So what precisely does the standard constrain? It defines clusters of behaviors and the standard names used for accessing those behaviors. It requires that there be global bindings for the standard names that identify these clusters of behaviors. A conforming implementation may have different class names for any of these clusters of behaviors as long as there is a global binding with the standard name. This ensures that applications written to the standard will compile and run. It further defines the notion of a Smalltalk program. In most implementations, the program is the entire development environment. The standard does not require this to be the case. It is possible to define a global program scope that does not include the development tools. This was the strategy that Team/V used to implement name spaces. Browsers were opened on subsystems which were scopes defined by a collection of packages. It was possible in the implementation of Team/V to browse a program that did not include the classes implementing the tools used to browse, edit and compile the program under development. I prefer this approach to namespaces in that there are no changes to the Smalltalk language itself and there is no runtime cost, since the namespace bindings are resolved at compile time in the context of the program to which the definitions belong. Further, I think it is critically important that the metastructure of the standard Smalltalk implementation was declared to be outside of the scope of the standard. Consider the COLA work being done at Viewpoints. Here we have a runtime that implements dynamic dispatch suitable for implementing Smalltalk programs without requiring the standard class metastructure to be present in the runtime. It would be possible to write small programs in a reflective, interactive development environment. When debugged, that program could be compiled into a closed executable targeting the COLA infrastructure. There are lots of small programs and scripts that I would prefer to write in Smalltalk. I am not always running in an image when I want to use these programs. It would be nice to be to compile them into handy utilities I can stuff in my bin. Frankly, I think this would make Smalltalk much more interesting to a new group of developers with needs that may vary from the traditional Smalltalk user. In summary, I think the beauty of the standard is that is admits to a wide variety of implementations without prohibiting or requiring the fully dynamic, reflective implementations that we have used and loved over the years. It tightly constrains a core of behaviors that are required by any interesting program, but does not prohibit interesting extensions and novel runtimes. I strongly suggest that interested parties reread the rationale sections of the proposed spec and spend some time reflecting upon them. John Sarkela :-}> On Feb 11, 2010, at 5:05 PM, Eliot Miranda wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |