3 ms·
Have you worked with Swift at all? Because the features you're complaining about aren't really difficult to understand in practice, and they're a major part of
by skohan 6y ago
Have you worked with Swift at all? Because the features you're complaining about aren't really difficult to understand in practice, and they're a major part of what makes Swift really clear and nice to work with.
> Keywords? Or parens? Both!
Why should they be mutually exclusive?
Swift's named parameters are great! For instance they allow for default parameters, which is something I really miss in Rust for instance where I have to use the builder pattern everywhere.
> And the weird case of having two keywords, one with a colon and one without, because we decided to make the keywords the names of the parameters. Sometimes.
Swift's rules for parameter naming are very simple, consistent, and easy to understand. Given the signature:
func foo(first second: Type)
`first` is the name used outside of the function, or the keyword for this argument, and `second` is the name used inside the function, or the parameter name. If the two names are the same, the second name can simply be elided. So for instance this signature:
func foo(x: Int)
Is just syntactic sugar for this:
func foo(x x: Int)
It's super simple and something which every swift developer can pick up within minutes of starting their first tutorial. I don't really understand why you seem to getting so agitated over this non-issue.
- mpweiher 6y ago> Have you worked with Swift at all? Yes, regretfully. >> Keywords? Or parens? Both! > Why should they be mutually exclusive? Because of parsimony. The comment I was replying to made the claim that the original Swift design war parsimonious. It wasn't. > Swift's named parameters are great! Named parameters are great. Swift's implementation of named parameters is deficient, and not parsimonious. Yes, even that design is better than not having named parameters, but once you have named parameters, you don't need the parens.
- rudedogg 6y ago> once you have named parameters, you don't need the parens. Can you share an example of what this would look like in practice? I'm having trouble thinking of how this syntax would work.
- pcr910303 6y agoYou can look at Smalltalk, which is a great example where names parameters without parens works great. But that doesn't mean that named parameters with parens are bad, yet that's what GP is suggesting. (For context, he's the designer/implementor of Obj-Smalltalk that runs on the Obj-C runtime.)
- rudedogg 6y agoThanks, here's an example I found: var a, b, c; ... a = b.fooBar(1, 2); c = a.fooBarBaz(1, 2, a); vs |a b c| ... a := b foo:1 bar:2. c := a foo:1 bar:2 baz:a. ... From: https://live.exept.de/doc/online/english/programming/stForJavaGuys.html https://live.exept.de/doc/online/english/programming/stForJa... The Smalltalk syntax is hard for me to parse, but it's probably just a familiarity thing. I remember when I first learned Swift I wasn't fond of not ending lines with semicolons. Now I dislike having to type them in languages where they're required.
- mpweiher 6y agoFamiliarity 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 https://youtu.be/Ao9W93OxQ7U?t=628
- skohan 6y agoHow 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 6y agoYou'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/ http://objective.st/