To Pipe Or Not To Pipe

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.