Hi fellow Squeakers!
First - I haven't followed this particular thread that much so consider me fairly uneducated in the variations and nuisances of "pipes" as proposed.
But that has never stopped me from sharing my few cents :) :
Yes, Alan Kay wants Smalltalk to evolve - but he is IMHO not considering the practical aspects that we as ONE Smalltalk implementation among others (crossplatform issues) must do.
I personally also think that we should drive Smalltalk forward and not be glued to the frozen ANSI standard. And including Traits was the first such "move" in a long time, and even though we still don't know how it plays out I think it was a healthy sign that we did it. :)
BUT... pipe? Come on - IMHO this is not even solving a *real* problem - just giving us some syntactic sugar - and I generally dislike sugar in languages. I think it will just create more problems than it will ever "solve". I mean, what problem is it actually "solving"? Removing some parenthesis? Is it really worth throwing away compatibility for that?
If we want to move Smalltalk forward I think we have lots of other much more *interesting* bits to chew on like new notions of dealing with concurrency or cleaning up base libraries (those covered by the std) or whatever.
Having said that I also think that we could start some kind of simple way for us to experiment without having to "choose" like this. One way is to create an official continuously maintained "patch set" called "Smalltalk-2000" or whatever that can be loaded on top of regular Squeak. Maintained meaning that we "port" it onto each new version of Squeak. It can contain several of these more drastical changes to Smalltalk and work as a test bed.
This way people can try out these additions "in real life" and Smalltalk-2000 could even build a strong following - and eventually we could then consider bringing it into the slightly more conservative Squeak line.
I think we also considered a similar approach to rewriting the Collection classes - by making a new package called NewCollections that can be installed without conflicts.
regards, Göran
On Tue, 04 Sep 2007 00:24:54 -0700, Göran Krampe goran@krampe.se wrote:
I think we also considered a similar approach to rewriting the Collection classes - by making a new package called NewCollections that can be installed without conflicts.
In the parlance of our times: +1
Of course, I have to think a truly revolutionary change isn't going to be at all painless.
"Göran" == Göran Krampe goran@krampe.se writes:
Göran> BUT... pipe? Come on - IMHO this is not even solving a *real* problem - Göran> just giving us some syntactic sugar - and I generally dislike sugar in Göran> languages. I think it will just create more problems than it will ever Göran> "solve". I mean, what problem is it actually "solving"? Removing some Göran> parenthesis? Is it really worth throwing away compatibility for that?
Hear Hear. My point as well.
On 4-Sep-07, at 6:20 AM, Randal L. Schwartz wrote:
"Göran" == Göran Krampe goran@krampe.se writes:
Göran> BUT... pipe? Come on - IMHO this is not even solving a *real* problem - Göran> just giving us some syntactic sugar - and I generally dislike sugar in Göran> languages. I think it will just create more problems than it will ever Göran> "solve". I mean, what problem is it actually "solving"? Removing some Göran> parenthesis? Is it really worth throwing away compatibility for that?
Hear Hear. My point as well.
I'm of a similar opinion.
They're not pipes. It's a pointless bit of syntactic flummery (and not even saving any keystrokes!) that accesses no new semantics and actually looks *worse* than the thing it is supposed to improve. It is nothing whatsoever to do with functional programming. Daft.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One clown short of a circus.
On 9/4/07, tim Rowledge tim@rowledge.org wrote:
I'm of a similar opinion.
They're not pipes. It's a pointless bit of syntactic flummery (and not even saving any keystrokes!) that accesses no new semantics and actually looks *worse* than the thing it is supposed to improve. It is nothing whatsoever to do with functional programming. Daft.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One clown short of a circus.
Lol. I hope you never leave this list, such directness in our PR times is quite refreshing. :)
But I think you might be looking at the OP's examples. Vassili's blog [1] had some better examples like:
somethings thingsAt: aKey :> includes: aThing :> ifTrue: [...] ifFalse [...]
Though for me it's not vastly better then:
((somethings thingsAt: aKey) includes: aThing) ifTrue: [...] ifFalse: [...]
But it does make you backtrack a bit to type it (well, at least highlight the exp and type a ( ).
The obvious counter argument is: is this going to make it less obvious when some code should be refactored ala "Smalltalk Best Practice Patterns".
Vassili's best proposition is to use coma , which is consistent with existing use of punctuation (period . and semicolon ;)
Unfortunately, it breaks compatibility with message selector #, Rephrasing Tim, is it really worth?
Nicolas
Jason Johnson a écrit :
Lol. I hope you never leave this list, such directness in our PR times is quite refreshing. :)
But I think you might be looking at the OP's examples. Vassili's blog [1] had some better examples like:
somethings thingsAt: aKey :> includes: aThing :> ifTrue: [...] ifFalse [...]
Though for me it's not vastly better then:
((somethings thingsAt: aKey) includes: aThing) ifTrue: [...] ifFalse: [...]
But it does make you backtrack a bit to type it (well, at least highlight the exp and type a ( ).
The obvious counter argument is: is this going to make it less obvious when some code should be refactored ala "Smalltalk Best Practice Patterns".
agree.
BUT... pipe? Come on - IMHO this is not even solving a *real* problem - just giving us some syntactic sugar - and I generally dislike sugar in languages. I think it will just create more problems than it will ever "solve". I mean, what problem is it actually "solving"? Removing some parenthesis? Is it really worth throwing away compatibility for that?
If we want to move Smalltalk forward I think we have lots of other much more *interesting* bits to chew on like new notions of dealing with concurrency or cleaning up base libraries (those covered by the std) or whatever.
I think we also considered a similar approach to rewriting the Collection classes - by making a new package called NewCollections that can be installed without conflicts.
This is my todo list but I cannot find them for that now. I would love to see if we could do the same a with stream (Nile - damien is rethinking simplifying it) but for collections.
squeak-dev@lists.squeakfoundation.org
-
Blake -
Göran Krampe -
Jason Johnson -
merlyn＠stonehenge.com -
nicolas cellier -
stephane ducasse -
tim Rowledge