|
|
Articles in the Extending Smalltalk series:
Shaping Evolution with Iterative Design
written by Peter William Lount version 1, 20050216 8:33am PDT version 2, 20050216 9:46am PDT version 3, 20050216 10:40am PDT version 4, 20050216 4:20pm PDT, typo corrections. In answer to Richard Demming's question How does Smalltalk evolve? (which now has an interesting indepth comment thread going) Patrick Logan wrote:
My answer is "very little". Smalltalk is not perfect, but is high up on the list of near-perfect languages.
Any radical changes are better off being put into a new language.
Otherwise the change can be put into one of the open source Smalltalk implementations and adopted ad hoc.
That's your choice and right. If the change succeeds wildly the community will adopt it for you.
This view could be characterized as Darwinian Evolution, or is that Loganian Evolution (to coin a phrase)?
It's an interesting and appealing approach to software evolution. Let the market of ideas succeed.
Let the changes become thought memes that live by being consumed by the designers and users of the language, or
that die by not being recognized as valuable or not being communicated to the right people who can make the
changes needed. For changes will be needed to the virtual machines.Where in the above view does a new ANSI Smalltalk Standard come to be? Is it even relevant? With many, so far at least twenty five, versions of Smalltalk in existance standards are becoming essential. Extension by Syntax or by Semantics? The forking of the Smalltalk langauge seems to be the predominate way that changes get made. Although we have Squeak pushing ahead some changes such as the intruduction of curly braces as a short cut for arrays. For example:
{ 1. 2. 3. 'one'. 'two'. 'three'. Point x: 100 y: 10}
produces an array of
the obvious objects 1, 2, 3, 'one', 'two', 'three', and a Point object with it's x value set to 100 and y set to 10.As I wrote in the curly braces link above this seems like a good enhancement because it expands the expressive power of Smalltalk and simplifies creation of Arrays it's also adds complexity by adding new "syntax" and a new "syntatic character" to the language. During research in developing a new derivative of Smalltalk it became clear that it's possible to add the same semantic feature to Smalltalk blocks by simply endowing blocks with a new message, namely "asAarray" (or "array" or "objectArray" or whatever is best as a method name). Using this approach the above example now becomes:
[1. 2. 3. 'one'. 'two'. 'three'. Point x: 100 y: 10] asArray.
Simple, elegant and natural Smalltalk.Oh, and you'd want variations such as "asSet", "asCollection", and whatever else you can think of. It's clear that this additional semantic can be added to the Smalltalk langauge by using message sends to disambiguate the existing block semantics from the new block semantics. So far in the work on Zoku there are around ten such cases that can be disambiguated with messages and support in the virtual machine. The choice of using new syntax to extend Smalltalk must be carefully considered, benefits weighed and balanced aginst costs and pitfalls, lest we head down the path to the syntatic complexities of PERL and the horde of languages such as C, C++, C#, Java, etc.... The choice of using semantics to extend Smalltalk means using messages to get the job done. Hey, this is the natural path for Smalltalk! This is especially important in keeping Smalltalk's essense when "meta programming" and "meta data" extentions are being considered. How can this extension be done with messages? The above example illustrates why I'd not vote for the "curly braces" extension becoming part of a new standard. It's clear that I'd vote for extension of blocks to accomplish the same result for the reasons listed above and because it's simply more flexible and powerful to extend a language with message semantics when possible. Another thought on this, extension by messaging semantics is the normal process by which objects get extended in Smalltalk. It's the natural Smalltalk approach for day to day object programming as well as the occasional meta programming. Be natural, be free, live the dynamic life. It seems that Richard Demmnigs is pointing out the need for the above with his proposal for evaluated literal arrays of the form:
x := 10.
"which", he correctly says, "would eliminate a lot of with:with: with: ugliness.".y := #(1 x 30 (x 4) 50). Translating his example into the Squeak curly brace (in bold) syntax approach we get:
x := 10.
and using the Zoku block semantic approach we end up with:y := { 1. x. 30. { x. 4} 50}
x := 10.
Pretty printing it to clarify the nesting we get:
y := [ 1. x. 30. [x. 4] asArray. 50] asArray.
x := 10.
or if you prefer:
y := [ 1. x. 30. [ x. 4 ] asArray. 50 ] asArray.
x := 10.
The Zoku block dynamic object form allows for other variations such as Sets and is thus more flexible
and natural as it uses Smalltalk messaging paradigm to disambiguate:
y := [ 1. x. 30. [ x. 4 ] asArray. 50 ] asArray.
x := 10.
y := [ 1. x. 30. [ x. 4 ] asSet. 50 ] asArray. What's happening in the Squeak extension and in the Zoku block dynamic object form is that as each Smalltalk statement within the curly braces or block is evaluated it's also stored into a collection object. Usually in Smalltalk only the last object is returned (unless you save one in a variable or another object). The Zoku block dynamic object approach uses the "deferred" nature of blocks and the use of a message "asArray" or "asSet" to disambiguate between blocks that are code to be evaluated with "value" using the usual Smalltalk block semantics and between blocks that consist of dynamic objects being constructed at runtime. The Zoku approach is the most powerful and general of these three proposals as it enables variation on what can be done with the "sequenced collection" of Smalltalk statements contained within the block. This is really an fundamental extension to the power of Smalltalk blocks and how code gets evaluated. It's also more natural since it doesn't introduce unnecessary additional syntax characters such as the curly braces. Assuming the semantics are the same (which I'm not fully clear on) this makes Richard Demmings proposal for "literal arrays" the third such proposal. So far the Squeak curly brace proposed extension (I consider it a proposal) is the only one implemented that I'm aware of. In fact with the "literal dynamic object" approach (the above Squeak curly brace and Zoku approaches) the need for the compile time "literal array" forms diminishes and could be considered legacy aspects of the language suitable for depreciation. This is the approach that the Zoku Language is taking, the removal of literal arrays completely. (Literal symbols are still required). However Zoku Smalltalk will support standard Smalltalk forms. A purpose of having a place that collects together the various extensions and proposed extensions to Smalltalk is for clarifying which language extensions are related to each other and to open the discussion on which will survive the tests of the community and time. This is why this article series is attempting to catalog the various extensions and resources to discussions about them. Please contribute your links, articles, and ideas to Smalltalk.org and we'll post them for the community to digest. Patrick makes a second excellent point:
Fork the language under a new name for radical changes. Let Smalltalk be Smalltalk at this point.
T h e r e i s o n e e x t e n s i o n i n t h e Z o k u L a n g u a g e t h a t d o e s a d j u s t t h e s y n t a x b y a d d i n g a s e c o n d k i n d o f " p a r s i n g s e q u e n c e "
t o t h e l a n g a u g e . D u e t o t h i s e n h a n c e m e n t t o t h e l a n g u a g e a n d a n a c c u m u l a t i o n o f t h e t e n o r s o e n h a n c e m e n t s t o b l o c k s e m a n t i c s
Z o k u r e a l l y i s a d i f f e r e n t l a n g u a g e y e t c l e a r l y w i t h i n t h e S m a l l t a l k s p h e r e . Z o k u t h e r e f o r i s a d e r i v a t i v e o f S m a l l t a l k
a n d n o t s i m p l y a n e x t e n s i o n . A s a r e s u l t i t b e c a m e c l e a r t h a t Z o k u w o u l d n e e d t o s u p p o r t t w o l a n g u a g e s : S m a l l t a l k a n d
Z o k u . T h e s e a r e k n o w n a s t h e Z o k u L a n g u a g e ( Z o k u T a l k "! o r Z o k u S c r i p t "! ) a n d Z o k u S m a l l t a l k "! . S i n c e Z o k u i s
a n a t u r a l s u p e r s e t o f S m a l l t a l k i t ' s s t r a i g h t f o r w a r d t o a u t o m a t i c a l l y c o n v e r t S m a l l t a l k i n t o t h e Z o k u L a n g u a g e a n d
e x e c u t e i t t h e r e , w i t h t h e o n l y l i m i t a t i o n b e i n g t h e d i f f e r e n c e s i n t h e o b j e c t l i b r a r i e s s u p p o r t e d . T h e Z o k u S m a l l t a l k
s y s t e m i s n e e d e d t o s u p p o r t t h e " l e g a c y " S m a l l t a l k o b j e c t l i b r a r y a s m u c h a s p o s s i b l e . O f c o u r s e i t w i l l t a k e w o r k
t o i m p l e m e n t t h i s , b u t t h a t ' s t h e a p p r o a c h b e i n g u s e d t o s o l v e t h e s e i s s u e s . Patrick contineus with another excellent point that cuts to the heart of major issues in software development:
I think the limitations of other languages lead their communities into a
mindset of constantly adding features as if it were a Microsoft Office product.
Unfortunately most language designers seem to tinker almost exclusively in the syntax domain of the possible language space.
Most of the features that use syntax in languages such as PERL, C, C++, C#, Java, etc... can be easily and seemlessly integrated
into Smalltalk (or a derivative) using messaging semantics. This avoids many aspects that Partick is pointing to.
Be prepared for and actively seek out the opportunities, for it (Java, C++, C#,
PERL, Python, PHP, JavaScript, Cobol, Fortran, etc...) too shall
pass due to their own mortal coils
(i.e. when the majority of those
infected realize the waste inherent in using those systems).
Choose dynamic freedom as it's the Future of IT now!"
However, anyone can take a path that leads them to produce systems as complex and bloated as Microsoft Office.
The main problem with systems so large is that there is no way to access the full power embodied in the program.
It's as if all the money spend by Microsoft on Office (and that's likely more money than most, as in 90% of,
companies will ever earn in their respective corporate lifetimes) is locked up behind a static shield to protect it from
the users. Almost like a museum artifact. Unfortunately for the users of static applications and operating systems
this isn't a metaphore it's reality, the functionally is really locked away behind, usually, clunky user interfaces
that almost seem to coddle the user. This forcably shape the user to fit through tiny uncomfortable holes in the dark
so that they can follow imprenetratble and often inexplicablly torturous paths to get some trivial task done. Who wants to
take Frodo's journey into Mordor everyday just to get something done? There is a better way.- The Prophet Small talks The better way provides users access to the features they really need and empowers them to create their own features as they see fit. It also enables a marketplace of ideas to sping up and be shared. Oh, that's that darn open source thingi rearing it's ugly head again, right Microsoft, oh mightly oppressor. Jest aside, the true power of software systems has yet to be unleashed. The best hope for the users revolution are systems that are open and accessible. In Smalltalk Evolution Blain Buxton writes:
"Code removed is code earned."
Blain is pointing to the process of iterative design where improvements make systems smaller, cleaner, leaner
and yes, even actually functional!Removing code means you are simplifying the code and the result is a net gain. So, next time, you're refactoring and deleting code. Don't think of it as deleting, but as gaining code via simplicity. The Process of Evolving Smalltalk In response to some of Richard Demmings comments about what is needed for the process of the evolution of smalltalk an essential part is collecting, organizing, analysing and communicating the proposed extensions. More on this in later articles in this series.
Articles in the Extending Smalltalk series:
Copyright 1 9 9 9 - 2 0 1 0 b y S m a l l t a l k . o r g "! , A l l R i g h t s R e s e r v e d . |
|