On 28/08/07, Fabio Filasieno fabio.filasieno@gmail.com wrote:
On Aug 28, 2007, at 1:38 PM, Alan Lovejoy wrote:
Denis Kudriashov wrote:
2007/8/27, Alan Lovejoy <squeak-dev.sourcery@forum-mail.net mailto:squeak-dev.sourcery@forum-mail.net>:
There haven't been all that many syntax changes to Smalltalk since its public release as ST80. Off the top of my head, I can list the following:
These changes does not have an influence on language core, language semantics. Its just was some convenient constructions for building special objects. But when we put in Smalltalk new operator we change it semantics. Why we must do it? Bert implemented it in clean Smalltalk without any language changes. Why it is not enough?
There are two issues:
- Are the proposed "pipes" a good idea at all? Is it good programming
style--or an abusive practice?
I remember a sentence of Alan Kay related to education stating that education is about learning powerful ideas and it was said in the context of describing what a metacircular interpreter is. Understanding this powerful ideas is difficult and requires experience.
In my opinion, the homoiconic system written is itself is the powerful idea in Smalltalk. But before trying what it means to work in an homoiconic system, my judgement was "who cares". But then my opinion changed, as soon as I tried squeak.
Same for the pipe. The pipe is one of those powerful ideas. And you will need experience in using it. Look at what the pipe did for Unix. The pipe IS the powerful idea in UNIX around which a whole culture of sharing was built. I'm not talking only of quality software artifacts, but an entire culture of people sharing small pieces of art. Showing how a piece of code written for specific context can be used in another one. This is the job of the artist, to show that there is always a new context.
- one guy would write `ls`
- another guy would write `grep`
- another guy would write `tar`
- another guy would write `gzip`
... etc ...
And everyone has a scriptable archiving system for free, absolutely for free.
Things like:
select:thenCollect:
It very very ugly bloat. It should removed instantly. To a unix user and to functional programmer this is something to be ashamed of. This is REALLY bad as it also appears in general purpose collection libraries !!!
Bloat you say? but if implemented differently it can improve performance and transform collection using single loop. Instead of: ^ (self select: selectBlock) collect: collectBlock or with pipe syntax: ^ self select: selectBlock | collect: collectBlock
it can be rewritten to: | newColl | newColl := self species new. self do: [ :each | (selectBlock value: each) ifTrue: [ newColl add: (collectBlock value:each) ] ] ^ newColl.
But yes, as a general approach it will be a bloat to implement tons of methods which will be a composition of different methods of collection transformations. That's where the pipes can propose something better and cleaner. But at the same time, often suboptimal.