5 ms·

Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), an

Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds). https://www.quora.com/Which-features-overcomplicate-Swift-What-should-be-removed?share=1 https://www.quora.com/Which-features-overcomplicate-Swift-Wh... That was 2015, when Swift was far simpler than today. Heck, they added almost all of Smalltalk syntax recently to address one special case of a special case. https://blog.metaobject.com/2020/06/the-curious-case-of-swift-adoption-of.html https://blog.metaobject.com/2020/06/the-curious-case-of-swif... And the method syntax that this is a special case of a special case of is many pages of spec. And of course there's initialization, which was 14 pages of the Swift spec at the time, with crazy overlaps and gotchas. Unsurprisingly and predictably (as in: I predicted it), it wasn't enough, or rather far too specific, so for SwiftUI they had to create an entirely new way of creating/initializing: function builders. https://blog.metaobject.com/2020/04/swift-initialization-swiftui-and.html https://blog.metaobject.com/2020/04/swift-initialization-swi...

skohan 6y ago
I find it funny when people complain about Smalltalk syntax in Swift, since in my experience keyword arguments and trailing closures are two of the features which make Swift clear and nice to work with.
- simondw 6y ago
  It would have been nice and simple if Swift had used Smalltalk syntax from the start. It's quite another thing to reject it at first, and then also bolt it on later alongside the non-Smalltalk syntax.
  - auggierose 6y ago
    It just shows an ability to learn. There is nothing wrong with that.
    - simondw 6y ago
      Sure, morally speaking, I completely agree. It might mean the language ends up more awkward and complicated than it had to, though.
      - auggierose 6y ago
        I am not familiar with the history of keywords in Swift. But I like both using keywords for function arguments, and to be able to leave them out. What other design would you propose?
  - skohan 6y ago
    It’s wise for a language to be parsimonious with syntactic constructs at first, and then gradually introduce concepts which seem like they should obviously be there. Multiple trailing closures fit a common use case and seem like a natural extension of the language.
    - mpweiher 6y ago
      > wise for a language to be parsimonious with syntactic constructs at first Absolutely. But Swift wasn't parsimonious at first. Not even close. It unwisely rejected the parsimonious case and chose tremendous complexity. Keywords? Or parens? Both! And we'll throw in a bunch of other stuff as well. 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. And then afterwards they noticed that the parsimonious choice that they had initially rejected in favor of their much more complex choice was needed in addition to all that initial complexity.
      - pcr910303 6y ago
        > It unwisely rejected the parsimonious case and chose tremendous complexity. Swift's keyword syntax isn't complex at all. > Keywords? Or parens? Both! I know you like Smalltalk, but keywords and parens are used together in a lot of languages (e.g. Python) so it's a tested idea. > 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. You don't have two keywords, you have an optional variable name. It's intuitive at the first time you see it - you're phrasing makes it seem much more complex than it really is. I think you're trying to imply that Swift isn't an elegant language with it's syntax fitting in a postcard, but that doesn't mean it's 'tremendous complexity'. This whole comment is a bit too harsh to Swift, calling the legitimate differences between Swift and Smalltalk as 'complexity'.
        mpweiher 6y ago
        >> It unwisely rejected the parsimonious case and chose tremendous complexity. > Swift's keyword syntax isn't complex at all. Yes it is, particularly compared to the parsimonious options. Either parens or Smalltalk-style keywords can do the job, so you absolutely, positively do not need both. Particularly, if you are going to have keywords, you just don't need parens. So it's already more complex than it needs to be (not parsimonious). Just explaining the various omitted or extra keywords takes 4 pages in the Swift book, the entire Smalltalk syntax fits on a Postcard. What is complex or not obviously depends on what your baseline is. If it's C++, Swift might seem simple (though many disagree). > (e.g. Python) so it's a tested idea. The question was not whether it was tested, but whether it was a parsimonious design, which it is not. It was also not a good design, because it led to a number of follow-on problems that they had to incrementally fix while adding even more complexity. Python is not a good comparison because they didn't really have a choice: they already had the paren syntax, which they could hardly deprecate. However, choosing that design without a backwards compatibility restriction is unconscionable, IMHO, particularly if you already have a different keyword design all over your code-base. That's cutting off your nose to spite your face. Anyway, even the baseline keywords-in-parens is complex and more complex than it needs to be (because it isn't parsimonious), but then you get follow-on problems: blocks inside parens are really ugly, so you add trailing closure syntax. Yet another special case, which is very different from arguments inside the parens. But then you discover that sometimes you need more than one trailing closure, and then you need yet another special case, the open-keyword-trailing-block syntax, which is different yet again. Of course, instead of having 3-4 different syntactic mechanisms, you could have chosen just the one and not needed any of the others. > You don't have two keywords, you have an optional variable name. It's intuitive at the first time you see it No, it's absolutely positively not the least bit intuitive. And it makes no sense, because internal variable names have no business leaking to the interface. If you want to rename the names of your variables inside your method, it changes the signature! Not even C does this. > that doesn't mean it's 'tremendous complexity' Although the argument could be made, I wouldn't, not by itself, no. However, this is just one example of countless others, see for example Rob Rix, whom I quoted before: Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds). I also talk more about it here: https://blog.metaobject.com/2015/05/i-am-jealous-of-swift.html https://blog.metaobject.com/2015/05/i-am-jealous-of-swift.ht... > is a bit too harsh to Swift, Nope. The comment I replied to made the indefensible claim that Swift was parsimonious. Which it's not. Not even close.
pcr910303 6y ago
I don't think that adopting a syntax that looks similar to Smalltalk means it has 'adopted Smalltalk syntax'. I like Smalltalk as a language, I do think that Swift would have been better if it's runtime model was more similar to Objective-C and Smalltalk, but it's not fair to say Swift 'added Smalltalk syntax to address a special case'. I do agree in general that Swift can benefit from a reduction of special cases, but my personal feeling is that Swift is getting more consistent every version (at least in the features that already existed). YMMV, of course.
- mpweiher 6y ago
  > I don't think that adopting a syntax that looks similar to Smalltalk means it has 'adopted Smalltalk syntax'. How so? That is literally what they did. The trailing closure syntax is Smalltalk keyword syntax, and so Smalltalk keyword syntax is used for that one special case. Which exists in addition to the non-keyword trailing closure syntax and the non-trailing (regular argument) closure syntax. > but it's not fair to say Swift 'added Smalltalk syntax to address a special case'. Can you explain how it is "unfair" when that is exactly what happened? Smalltalk syntax is really compact, there just isn't that much there.
  - pcr910303 6y ago
    Well, the syntax is same - the ideas are different. Trailing closure syntax is basically 'you can remove the parens if there are trailing closures'. Which, if you apply that to multiple closures, you get the syntax that also looks like Smalltalk. Which is understandable, since Swift keyword calling syntax was always 'keyword followed with a colon' since Swift 1, which was inspired by Objective-C, which was inspired by Smalltalk. But then that's not adding Smalltalk syntax in a later stage, it was baked into the language since day 1. That multiple trailing closure syntax - that syntax can come out from anyone knowing Swift without any Smalltalk knowledge, it's a logical next step. So it feels a bit weird to call it 'adopting Smalltalk syntax' since I don't think Smalltalk influenced that syntax any more than other parts of the language.
    - mpweiher 6y ago

skohan 6y ago

I find it funny when people complain about Smalltalk syntax in Swift, since in my experience keyword arguments and trailing closures are two of the features which make Swift clear and nice to work with.

simondw 6y ago
It would have been nice and simple if Swift had used Smalltalk syntax from the start. It's quite another thing to reject it at first, and then also bolt it on later alongside the non-Smalltalk syntax.
- auggierose 6y ago
  It just shows an ability to learn. There is nothing wrong with that.
  - simondw 6y ago
    Sure, morally speaking, I completely agree. It might mean the language ends up more awkward and complicated than it had to, though.
    - auggierose 6y ago
      I am not familiar with the history of keywords in Swift. But I like both using keywords for function arguments, and to be able to leave them out. What other design would you propose?
- skohan 6y ago
  It’s wise for a language to be parsimonious with syntactic constructs at first, and then gradually introduce concepts which seem like they should obviously be there. Multiple trailing closures fit a common use case and seem like a natural extension of the language.
  - mpweiher 6y ago
    > wise for a language to be parsimonious with syntactic constructs at first Absolutely. But Swift wasn't parsimonious at first. Not even close. It unwisely rejected the parsimonious case and chose tremendous complexity. Keywords? Or parens? Both! And we'll throw in a bunch of other stuff as well. 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. And then afterwards they noticed that the parsimonious choice that they had initially rejected in favor of their much more complex choice was needed in addition to all that initial complexity.
    - pcr910303 6y ago
      > It unwisely rejected the parsimonious case and chose tremendous complexity. Swift's keyword syntax isn't complex at all. > Keywords? Or parens? Both! I know you like Smalltalk, but keywords and parens are used together in a lot of languages (e.g. Python) so it's a tested idea. > 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. You don't have two keywords, you have an optional variable name. It's intuitive at the first time you see it - you're phrasing makes it seem much more complex than it really is. I think you're trying to imply that Swift isn't an elegant language with it's syntax fitting in a postcard, but that doesn't mean it's 'tremendous complexity'. This whole comment is a bit too harsh to Swift, calling the legitimate differences between Swift and Smalltalk as 'complexity'.
      - mpweiher 6y ago
        >> It unwisely rejected the parsimonious case and chose tremendous complexity. > Swift's keyword syntax isn't complex at all. Yes it is, particularly compared to the parsimonious options. Either parens or Smalltalk-style keywords can do the job, so you absolutely, positively do not need both. Particularly, if you are going to have keywords, you just don't need parens. So it's already more complex than it needs to be (not parsimonious). Just explaining the various omitted or extra keywords takes 4 pages in the Swift book, the entire Smalltalk syntax fits on a Postcard. What is complex or not obviously depends on what your baseline is. If it's C++, Swift might seem simple (though many disagree). > (e.g. Python) so it's a tested idea. The question was not whether it was tested, but whether it was a parsimonious design, which it is not. It was also not a good design, because it led to a number of follow-on problems that they had to incrementally fix while adding even more complexity. Python is not a good comparison because they didn't really have a choice: they already had the paren syntax, which they could hardly deprecate. However, choosing that design without a backwards compatibility restriction is unconscionable, IMHO, particularly if you already have a different keyword design all over your code-base. That's cutting off your nose to spite your face. Anyway, even the baseline keywords-in-parens is complex and more complex than it needs to be (because it isn't parsimonious), but then you get follow-on problems: blocks inside parens are really ugly, so you add trailing closure syntax. Yet another special case, which is very different from arguments inside the parens. But then you discover that sometimes you need more than one trailing closure, and then you need yet another special case, the open-keyword-trailing-block syntax, which is different yet again. Of course, instead of having 3-4 different syntactic mechanisms, you could have chosen just the one and not needed any of the others. > You don't have two keywords, you have an optional variable name. It's intuitive at the first time you see it No, it's absolutely positively not the least bit intuitive. And it makes no sense, because internal variable names have no business leaking to the interface. If you want to rename the names of your variables inside your method, it changes the signature! Not even C does this. > that doesn't mean it's 'tremendous complexity' Although the argument could be made, I wouldn't, not by itself, no. However, this is just one example of countless others, see for example Rob Rix, whom I quoted before: Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds). I also talk more about it here: https://blog.metaobject.com/2015/05/i-am-jealous-of-swift.html https://blog.metaobject.com/2015/05/i-am-jealous-of-swift.ht... > is a bit too harsh to Swift, Nope. The comment I replied to made the indefensible claim that Swift was parsimonious. Which it's not. Not even close.

pcr910303 6y ago

I don't think that adopting a syntax that looks similar to Smalltalk means it has 'adopted Smalltalk syntax'. I like Smalltalk as a language, I do think that Swift would have been better if it's runtime model was more similar to Objective-C and Smalltalk, but it's not fair to say Swift 'added Smalltalk syntax to address a special case'. I do agree in general that Swift can benefit from a reduction of special cases, but my personal feeling is that Swift is getting more consistent every version (at least in the features that already existed). YMMV, of course.

mpweiher 6y ago
> I don't think that adopting a syntax that looks similar to Smalltalk means it has 'adopted Smalltalk syntax'. How so? That is literally what they did. The trailing closure syntax is Smalltalk keyword syntax, and so Smalltalk keyword syntax is used for that one special case. Which exists in addition to the non-keyword trailing closure syntax and the non-trailing (regular argument) closure syntax. > but it's not fair to say Swift 'added Smalltalk syntax to address a special case'. Can you explain how it is "unfair" when that is exactly what happened? Smalltalk syntax is really compact, there just isn't that much there.
- pcr910303 6y ago
  Well, the syntax is same - the ideas are different. Trailing closure syntax is basically 'you can remove the parens if there are trailing closures'. Which, if you apply that to multiple closures, you get the syntax that also looks like Smalltalk. Which is understandable, since Swift keyword calling syntax was always 'keyword followed with a colon' since Swift 1, which was inspired by Objective-C, which was inspired by Smalltalk. But then that's not adding Smalltalk syntax in a later stage, it was baked into the language since day 1. That multiple trailing closure syntax - that syntax can come out from anyone knowing Swift without any Smalltalk knowledge, it's a logical next step. So it feels a bit weird to call it 'adopting Smalltalk syntax' since I don't think Smalltalk influenced that syntax any more than other parts of the language.
  - mpweiher 6y ago