To Pipe Or Not To Pipe
5 September, 2007
The squeak-dev mailing list is currently fired up with a debate that will be of great interest for students of the theory of language design – and for students of the politics of language design!
It started with a question by Fabio Filasieno wondering why Squeak doesn’t have a “pipe” construct to the language to allow the result of a message-send to be the recipient of the next message, thus removing the need for parentheses, so
((1 to: 100) select: [ :each | each odd ] ) sum.
becomes
1 to: 100 | select: [ :each | each odd ] | sum.
The debate has continued for days, including topics such as:
Is piping the right term?
What characters could be used without confusion?
Should a proliferation of parentheses should be seen as a ‘code smell’, so the algorithm is the thing to fix, rather than the syntax?
Why not just use an “asPipe” message which would alter the operation of the cascades to give this without changing the language?
Is the benefit of this change enough to make it worth changing the syntax of Smalltalk?
Do languages that don’t change stagnate?
Was the brace syntax a step too far?
What’s the EBNF for Smalltalk? (This got a definitive answer [for 2.7])
What are the differences between Smalltalk, Lisp and Perl approaches (with Randal Schwartz revealing himself to be a long-time Smalltalker)?
Alan Kay has also contributed some remarks on the early development of Smalltalk, and possible future directions.
Follow the discussion:
Fabio’s original email
The harvesting thread
or look for any of the myriad threads with “pipe” in the title.
The Weekly Squeak 
5 September, 2007 at 21:06
The parenthesis construct is semantically clearer, information that is lost with the pipe construct.
5 September, 2007 at 22:17
It’s more correct to formulate the question as why doesn’t Smalltalk have a “pipe” construct for keyword messages. “3 factorial negated + 4 / 5” is a perfectly valid chain (“pipe”) of messages in classic Smalltalk.
6 September, 2007 at 00:13
Fabio showed all the hallmarks of a talented troll, and successfully started quite a significant flamewar!
My concern is that the release team / harvesters would take this suggestion seriously. Some people on the list were pushing for this to be integrated into Squeak while the technical merits of this approach were questionable.
As with the arguments about Smalltalk stagnating, these are strawman fallacies. The argument was that if this is not integrated, then Squeak is stagnant and as a stagnant language would die out. Certainly this is not the case; Squeak and Smalltalk are very flexible languages and have a lot more potential to explore without needing to resort to syntax changes in the language.
6 September, 2007 at 06:55
A bit like Haskell’s >>= operator (for monads) … A bit. Interesting.
6 September, 2007 at 08:07
I don’t think he was trolling, he actually started this discussion on my blog, and moved to the list after a few posts and some having some issues posting on the blog.