5 ms·

It's really weird to me that this is (currently) the top-voted comment on this article. This little quip is not what the article is about nor does it represent

It's really weird to me that this is (currently) the top-voted comment on this article. This little quip is not what the article is about nor does it represent the author's views. Do you have any feedback on that article's thesis that the closure syntax could have been handled better?

dsabanin 6y ago
Hindsight is 20/20. Every programming language changes as it evolves and matures and people understand how to use it best or its domain changes significantly. Unfortunately, this always means accumulating these syntactic and semantical warts. Personally, I think Swift manages to keep a good balance, and it's a very powerful language, with lots of users and compatibility requirements, so it's much harder for them than for many others. Alternative is constant redesign of syntax and behavior that just keeps making users unhappy with every release, breaking their code, libraries and obsoleting the docs. If, to mitigate that, you try to make big changes to the language in big releases, once in a long while, you can easily get into the Python 3, Scala 3, Perl 6 fiasco and that can simply kill the language adoption. It's a hard problem.
- lizmat 6y ago
  Indeed. In the Perl 6 case, this has been solved by renaming the language to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).
- aduitsis 6y ago
  Very good point, thank you. As regards Perl 6, a recent development was to rename it to Raku, which (in hindsight) seems like a perfectly sensible decision. The overloading of the name Perl for a language that proved to be something different from Perl 5 caused trouble both ways. Perl 5 was widely considered to be a version that was to be eventually be replaced, whereas Perl 6 was considered a language that was a close and direct iteration of Perl 5. So we basically got the worst of both worlds. Perl 5 is very much in use today, still being actively maintained and is getting new features regularly, while Raku/Perl 6 is a beautiful new different language with interesting ideas being worked on by many brilliant folks, and the notion of trying to be in any way compatible with Perl 5 seems utterly irrelevant today.
- b2gills 6y ago
  The Python 3 changes aren't big changes. They are breaking changes however. I know they aren't big because Perl has had to deal with many of those same type of problems, only it didn't have to break old code to do it. Perl 6 is more of a research project that took Perl 5 as a leap-off point. As it is is such a large departure from every language, it deserves it's own name. So it is now known as Raku.
skohan 6y ago
I have followed the discussion around this on the Swift forums, and I'm actually of the opinion that the debate around this topic amounts to little more than bikeshedding and the proposed syntax for multiple trailing closures is fine. I'm a bit perplexed by the author's position that Swift should just be small-talk as though this is obviously better. As far as the idea of getting rid of parens entirely as the author suggests, I'm not a big fan of this approach. In languages like ruby where parens are not used, I tend to find this makes things a lot less readable. That might be a matter of opinion, but at the very least I think it can be said that Swift's approach to arguments, where only closures can be moved out of the parentheses of a function call is a perfectly consistent and defensible approach. For instance I don't think that this: foo(someArg: 42) { // do something } Is less clear than this: foo doSomething: { do something } someArg: 42 In fact I think it's probably the opposite, and the only reason I can imagine to prefer the second example would be out of some appeal to purity/simplicity of the function call syntax over any level of pragmatism. As far as the whole debate over the inconsistency of the first argument label being removed while the following argument labels are required in multiple-trailing-closure syntax, I just don't think it's that big a deal. I also understand the consistency argument, that it should be handled the same for all arguments (i.e. the author of the function signature should explicitly decide if the label is required or not), and it probably should work that way, but I also understand why it hasn't been proposed that way for the first iteration. It would break a lot of code given how prevalent trailing closures are in Swift. However there are already proposals in the pipeline to introduce an argument label in the first trailing closure (provided the function author hasn't named it `_`). I suspect in the long term this will eventually make it into the language, and automatic migration tools will make it possible to resolve issues with existing code without much fuss. So in short I think multiple trailing closures are a good and natural addition to the language which provide real value, and the proposed syntax is absolutely fine.
- PostThisTooFast 6y ago
  "Bikeshedding?"
gumby 6y ago
FWIW I actually like comments that expand on a side point in an article. After all an author expands on their primary topic pretty much by definition.

dsabanin 6y ago

Hindsight is 20/20. Every programming language changes as it evolves and matures and people understand how to use it best or its domain changes significantly. Unfortunately, this always means accumulating these syntactic and semantical warts. Personally, I think Swift manages to keep a good balance, and it's a very powerful language, with lots of users and compatibility requirements, so it's much harder for them than for many others. Alternative is constant redesign of syntax and behavior that just keeps making users unhappy with every release, breaking their code, libraries and obsoleting the docs. If, to mitigate that, you try to make big changes to the language in big releases, once in a long while, you can easily get into the Python 3, Scala 3, Perl 6 fiasco and that can simply kill the language adoption. It's a hard problem.

lizmat 6y ago
Indeed. In the Perl 6 case, this has been solved by renaming the language to Raku (https://raku.org https://raku.org using the #rakulang tag on social media).
aduitsis 6y ago
Very good point, thank you. As regards Perl 6, a recent development was to rename it to Raku, which (in hindsight) seems like a perfectly sensible decision. The overloading of the name Perl for a language that proved to be something different from Perl 5 caused trouble both ways. Perl 5 was widely considered to be a version that was to be eventually be replaced, whereas Perl 6 was considered a language that was a close and direct iteration of Perl 5. So we basically got the worst of both worlds. Perl 5 is very much in use today, still being actively maintained and is getting new features regularly, while Raku/Perl 6 is a beautiful new different language with interesting ideas being worked on by many brilliant folks, and the notion of trying to be in any way compatible with Perl 5 seems utterly irrelevant today.
b2gills 6y ago
The Python 3 changes aren't big changes. They are breaking changes however. I know they aren't big because Perl has had to deal with many of those same type of problems, only it didn't have to break old code to do it. Perl 6 is more of a research project that took Perl 5 as a leap-off point. As it is is such a large departure from every language, it deserves it's own name. So it is now known as Raku.

skohan 6y ago

I have followed the discussion around this on the Swift forums, and I'm actually of the opinion that the debate around this topic amounts to little more than bikeshedding and the proposed syntax for multiple trailing closures is fine. I'm a bit perplexed by the author's position that Swift should just be small-talk as though this is obviously better. As far as the idea of getting rid of parens entirely as the author suggests, I'm not a big fan of this approach. In languages like ruby where parens are not used, I tend to find this makes things a lot less readable. That might be a matter of opinion, but at the very least I think it can be said that Swift's approach to arguments, where only closures can be moved out of the parentheses of a function call is a perfectly consistent and defensible approach. For instance I don't think that this: foo(someArg: 42) { // do something } Is less clear than this: foo doSomething: { do something } someArg: 42 In fact I think it's probably the opposite, and the only reason I can imagine to prefer the second example would be out of some appeal to purity/simplicity of the function call syntax over any level of pragmatism. As far as the whole debate over the inconsistency of the first argument label being removed while the following argument labels are required in multiple-trailing-closure syntax, I just don't think it's that big a deal. I also understand the consistency argument, that it should be handled the same for all arguments (i.e. the author of the function signature should explicitly decide if the label is required or not), and it probably should work that way, but I also understand why it hasn't been proposed that way for the first iteration. It would break a lot of code given how prevalent trailing closures are in Swift. However there are already proposals in the pipeline to introduce an argument label in the first trailing closure (provided the function author hasn't named it `_`). I suspect in the long term this will eventually make it into the language, and automatic migration tools will make it possible to resolve issues with existing code without much fuss. So in short I think multiple trailing closures are a good and natural addition to the language which provide real value, and the proposed syntax is absolutely fine.

PostThisTooFast 6y ago
"Bikeshedding?"

gumby 6y ago

FWIW I actually like comments that expand on a side point in an article. After all an author expands on their primary topic pretty much by definition.