[mpweiher]

Familiarity and, since it is based on words, not parens, the actual names matter. You're going to have a hard time parsing with foo bar baz, just like you are going to have a hard time parsing a sentence with made up words.

   1 to: 20 do:[ :i | Transcript show:i. ]  

or in Obj-S

   1 to: 20 do:{ stdout println:$0. }

The keyword syntax makes a LOT of other syntax unnecessary, and allows you to create APIs that read like DSLs.

https://youtu.be/Ao9W93OxQ7U?t=628

[skohan]

How do you chain function calls in smalltalk syntax? I think delineating the argument set for a single function is the main job parens fulfill.

[mpweiher]

You've nailed one of the few issues with keyword message syntax in Smalltalk-80.

While binary and unary messages chain w/o problems, it's not possible to disentangle two keyword messages:

     receiver msg1:arg1 msg2:arg1

is indistinguishable from

     receiver msg1:arg1 msg1:arg2

So ST-80 chooses the latter. If you mean the former, you have to parenthesize.

But not always, it turns out. If you actually chain messages to the same receiver, you can use the semicolon to chain those messages:

   myRect x:20;
          y:10;
          width:100;
          height:100.

This looks like the single message x:y:width:height: but is actually four separate messages, all sent to myRect. It makes additional compound messages, particularly setters, less necessary.

In Objective-S[1], you can use the pipe ("|") to chain message-sends that go to the result of the previous message, rather than its receiver. For example:

   self dictionariesForQuery: "select {column} from {table}" | collect | at:column.

Since Objective-S also supports dataflow, the similarity to Unix pipes is intentional, and it pretty much works semantically as well: the result of the previous expression gets piped into the next expression. Very intention-revealing. In fact, I've found it to be so useful in communicating the structure of expressions that I use it even when it's not strictly necessary, for example the second instance in the example above.

> delineating the argument set for a single function is the main job parens fulfill.

Right. Which is one of the many reasons why the case of Swift is so mind-boggling: there some of the parameters go inside the parens, some outside. I think you can make a good case for either all in or all out (better for all-out, IMHO, but whatever). But partly in and partly out?

[1] http://objective.st/