17 ms·

The Curious Case of Swift's Adoption of Smalltalk Keyword Syntax

147 points by mwcampbell 6y ago

asplake 6y ago
Arguably, the new syntax makes the anonymous trailing closure the special case now. Having done a bit of Ruby in the past I can see why it might be reasonable to have both.
AJRF 6y ago
I would really hate to be learning Swift now. I started using it around the v2 release and I think it had nice syntax & was relatively small and opinionated. Now there are so many ways to the same thing it must be a nightmare to teach. Each way of doing the same thing is in its own way nice, but they seem to just be accepting every half-way decent proposal for things they've already solved. I feel like SwiftUI had brought a number of challenges that have massively complicated the language and you can really feel it when you bump up against things that have been tacked on to make SwiftUI work (which it looks like they are getting around to smoothing out now - multiple trailing closures is very a much a problem compounded by SwiftUI). It's a shame, I loved this language from v2 -> v4, v5 was a good release but started to muddy the waters and now its just getting continually worse.
- skohan 6y ago
  > feel like SwiftUI had brought a number of challenges that have massively complicated the language and I've been a huge fan of Swift for years, and it's still one of the languages I reach for most for personal projects, but I was really put off by the way the rollout was handled for the features supporting SwiftUI, specifically property wrappers and function builders. Property wrappers in particular feel like a half-baked solution to paper over the lack of real meta-programming facilities. I think it was especially disheartening the way these changes were sprung on the community after being shown at WWDC. It just made the promise of Swift being an open source project built through a community-based process seem like a bit of a farce, and made me a bit more apprehensive about investing in a language which might radically change in direction based on the product needs of Apple.
- tonyedgecombe 6y ago
  It's difficult to dip in and out of, you really need to be focussed on it to become productive. It's interesting to compare it to C# which I learnt by opening the IDE and writing code. There was far less to trip you up in C# despite it also being a fairly big language.
- j-pb 6y ago
  That description sadly applies to every apple product, software or hardware wise, except for iPhone hardware maybe.
- matt2000 6y ago
  I agree with you. When Swift was introduced it was billed as a modern replacement for ObjC that was easier to learn, even a good choice as a language for learning to program. I'm not sure it was ever that, but it sure isn't now. I just got back into a project written in Swift 3 and had to change a bunch of stuff to get it to work in Swift 5. Why? I keep hearing the language is going to be stable "soon" but that doesn't appear to be happening. Swift appears to be a language for the captive audience of iOS devs, who are able to keep up if that's all they're doing. I don't really see it being adopted anywhere else.
  - wool_gather 6y ago
    For what it's worth, source stability is definitely a much firmer constraint now in the minds of the core team: https://forums.swift.org/t/principles-for-trailing-closure-evolution-proposals/37265/18 https://forums.swift.org/t/principles-for-trailing-closure-e... Of course this comes with its own concerns, as you can see from that thread.
  - skohan 6y ago
    To be fair, the pace of source breaking changes has slowed down considerably. From Swift 1 to Swift 3 there were many breaking changes between versions, and automated migration was very necessary. Between 3 and 4 there were some changes, and between 4 and 5 almost no source breaking changes. I think it's actually fair for a new language to take a somewhat cavalier approach to backward compatibility. I would rather not be stuck with all the naive mistakes made in the first version of a language just to avoid migration.
  - JimDabell 6y ago
    > I just got back into a project written in Swift 3 and had to change a bunch of stuff to get it to work in Swift 5. Why? I keep hearing the language is going to be stable "soon" but that doesn't appear to be happening. Swift 3 was released in 2016. Swift is ABI / source / module stable now, but that doesn't make it retroactively stable with a version released four years ago.
  - seandougall 6y ago
    > I keep hearing the language is going to be stable "soon" I think you may be referring to the promises of ABI stability? They kept promising that "soon" starting around Swift 3 (IIRC) and kicking the can down the road for a while there, but it is stable now on Apple's OSes. But I don't recall seeing promises of source stability back then; they were pretty open about the fact that the language was still evolving.
- hombre_fatal 6y ago
  Swift is trivial compared to the rest of iOS/macOS/iDevice development. CoreData, nasty Cocoa/AppKit APIs, SwiftUI buggyness, all the legacy objc cruft, 99% of resources online being for iOS, not macOS. Swift idiosyncrasies don't even put a dent in the learning curve imo. I don't think anything gets this across quite like onboarding experienced devs into a client app that haven't done mobile client dev before. They'll ask you completely reasonable questions about Appkit/UIKit/CoreData like why is NSBox used here and you realize 90% of the time your best answer is just "well, that's just kind of how you learn to do it over time." Very few questions about Swift itself.
  - blondin 6y ago
    i agree with you on the iOS vs macOS comment! apple allowed this problem to happen. it's the same as allowing people to abuse SEO to get on the first page of results. apple told people that there is money in iOS and they went there. we are the worse. nobody is teaching you how to write a macOS app. heck, metal has been out for 6 years and there is zero book that will tell you how to set it up on the mac. if that goes on, metal will die because only few will use it. people are like metal is for library and framework and game engine builders. don't use it directly. yeah, and it is competing with and replacing opengl or vulkan. and people are using those directly. and there are bazillions of resources on those. kids are writing shaders in unity. oh let me give some kudos to the apple programming guides because they deserve it! i stopped looking for books and watching videos because of the iOS thing mentioned above. everything i needed was on developer.apple.com and i didn't know it. i started with the metal programming guide on my phone a few weeks ago. but that guide made it clear that i needed to understand the ecosystem first. so my detour took me through many others: the cocoa, the event system, the view hierarchy, etc. these guides have been the highlight of the past few weeks for me. they are better than most programming documentation out there. and i read them on my phone! i have 3 of them loaded in chrome on my phone right now. i still don't know what makes them so great but i intend to write about that at some point. one thing i figured is that they are light on code sample. reading code on the phone is really the worst. sorry long comment, but yeah, swift is not the best thing. i am finding great joy in objective-c and what came before because i went through these guides.
- julius_set 6y ago
  This really just sounds like nit-picking, the language is miles ahead of most other languages.
  - saagarjha 6y ago
    You can criticize a language where it fails even if it is overall better than others.
- deleted 6y ago
  [deleted]
- ksec 6y ago
  >I would really hate to be learning Swift now. I started using it around the v2 release and I think it had nice syntax & was relatively small and opinionated. But the Swift team / Apple doesn't seems to be aware of it. ( At least a few internal Apple devs completely reject Swift for their project.) That is why I think Chris Lattner trying to make Swift scale from Javascript down to C was wrong from the start. And Swift will be like C# on Windows.
simias 6y ago
>And that's the frustrating part: this stuff was and is available and well-known. At least if you bother to look and/or ask. But instead, we just choose these things willy-nilly and everybody has to suffer the consequences. That could be it, or that could be that these days any language that doesn't have a syntax vaguely resembling C on one hand or Python on the other it is considered niche or "weird". You'll also have an endless stream of people commenting (mostly from the Python side) that your language is noisy, because they won't take the time to understand its syntax and it won't read like pseudocode, and that's a bad thing for some reason. But I digress, because that's a pet peeve of mine. Anyway, my point is that if Swift had Smalltalk-like syntax it would not have been nearly quite as marketable. The situation with Javascript is somewhat similar: under the hood the language is more like a Lisp than C, yet it awkwardly uses C-style syntax (and weird rules for automatic semicolon insertion, because that's more like peusdocode that way, and that's a good thing for some reason).
- mpweiher 6y ago
  > Smalltalk-like syntax would not have been nearly quite as marketable This was one bit I left out: with Objective-C, Apple had firmly established keyword syntax in a Tiobe top 3 language, albeit within square brackets, so there was absolutely no need to do this for "marketing". It truly was snatching defeat from the jaws of victory. > that your language is noisy Smalltalk is about as syntactically quiet as you can get.
  - simias 6y ago
    To be clear I wasn't making the "noisy" critique myself, it's just a qualifier I've seen, in my opinion unfairly, applied to the syntax of certain languages in the past. I think the problem is not whether the language is really noisy or not, it's more whether the language is familiar or not. Nobody complains that "(x + 1) / (y * 4)" is noisy, even though it's more symbols than numbers or letters. Everybody is familiar with mathematical notation. I think deep down a lot of the "noisy" complaints are really about unfamiliarity, and that was my point: most coders aren't familiar with Smalltalk but most coders are familiar with C-style syntax, so it wins by default in the marketability department. It's a bit like when people who are first exposed to Lisp say "oh my god all these parens!" or when Python-first coders have to code in C and say "wow, I can't believe I have to put semicolons everywhere". Yet when one is familiar with these languages the parens/semicolon kind of fade away because you see the structure behind the tokens, so to speak. I don't even consciously notice semicolons anymore, and I type them without thinking as naturally as I hit "return" at the end of a line. But if you're just starting it does take a while to get used to them.
jtdev 6y ago
The closure obsession in Swift is really off putting. The amount of indirection in the language is frustrating and seems to be there due to an FP zealot somewhere in the language design team at Apple.
- skohan 6y ago
  I tend to find it really powerful and nice. The lightweight closure syntax is something I often miss in other languages
weiming 6y ago
Curious question as I am not a compiler expert. I have to do front-end iOS work from time to time and it's surprising how bad auto-complete can be in Xcode with Swift even after all these years: still randomly sluggish, randomly stops working inside closures including completely losing syntax highlighting inside the closure, and even Cmd+clicking to see the definition is a hit-or-miss as it sometimes opens up a blank editor and just spins. I would have thought that Swift having a strict type system would have made the IDE experience better, not worse. Don't know if the grammar is too complex or if it is the bridging with ObjC stuff or something else that made it difficult to build a robust solution. Can anyone shed light on this? My points of reference are rust-analyzer, or just VSCode with Typescript, both very snappy although of course the languages are very different. If anything I'd expect Swift to be closer to Rust experience-wise since they both have pretty strict grammars.
- tonyedgecombe 6y ago
  The JetBrains IDE[1] seems much better at this so I would assume it is an Xcode problem. [1]: https://www.jetbrains.com/objc/features/swift.html https://www.jetbrains.com/objc/features/swift.html
- jmenter 6y ago
  10 year iOS developer here. I don't have any answers for you (not a compiler expert either) but yeah, auto-complete of Swift in Xcode continues to suck in a lot of different ways. It's a shame because autocomplete in Obj-C was so good for so long (I'd put it up there with VSCode/TypeScript with some caveats), and is still pretty great, but seemed to get a little worse itself when Swift showed up.
  - novok 6y ago
    I think it comes down to swift being a way slower performance language on the compiler side because of some bad early design decisions their compiler engineers will grumble about on twitter occasionally and xcode struggling with that fact. And apple underfunding their developer tools team that creates all of this.
- 6y ago
skohan 6y ago
I don't really get this complaint: > The already weird-ish addition of Smalltalk/Objective-C keywords inside the f(x) syntax: f(arg:x) I'm a huge fan of named arguments in Swift. It's one of the things I miss most when working with languages which don't have it. For instance, I do a lot of work with computer graphics, and in that case you end up with a lot of functions with a lot of arguments for things like configuration. With named arguments, code becomes almost self-documenting. Without them, I just end up using comments in their place, but of course then I don't have the compiler making sure this is correct. It's a totally optional language feature, and adds a lot of value in some cases.
- choeger 6y ago
  Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward. Think: f(fst:x, snd:y), what is the type of f(snd:4)? I think this can be implemented, but then f(3, fst:5) is either an error or counter-intuitive.
  - skohan 6y ago
    Swift's approach to this is pretty good. Arguments have a fixed order, and whether or not they are named at the call-site is explicitly decided by the author of the function signature. In practice the order and identity of the arguments is quite clear in Swift.
    - codetrotter 6y ago
      As someone who kind of jumped into Swift coming from other languages, I still find this kind of stuff confusing. Is there a good intro to Swift that goes through only what is unique/peculiar about Swift and explains that in a good way to someone that already knows how to program?
      - bluk 6y ago
        I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.
jmull 6y ago
Swift language evolution seems to be heading in a bad direction. This is another change that adds nothing but extra, obfuscating complexity to the syntax. Now you’ll have to read and write yet another syntax variant, with slightly scrambled separators and brackets.
saagarjha 6y ago
As is tradition, I'm going to take the discussion one level up and talk about the language as a whole, although my issue is related to this syntactical change. The problem Swift has right now is that the review process is marred by huge conflicts-of-interests. The people reviewing proposals are very closely affiliated with, or sometimes the same people, that proposed it and want it implemented. And that's not to say they aren't smart, reasonable people; quite the opposite: it's just that they have their own interests when they're adding features to the language, and they ignore the community when doing so. When initial SwiftUI changes came through, they were "proposed" by Apple engineers even though they already shipped in Xcode. Sure, they got a bit of feedback and change, but everyone largely knew they were going in regardless and they did. When callAsFunction came in (which I actually think is a useful feature, just spelled horribly) it was obvious that it was being pushed heavily by the Swift for TensorFlow people. And who reviewed it? Chris Lattner, who approved it even though nobody really liked the name at all. And with this case we see a fairly dubious benefit being pushed forward by the team at Apple, and everyone knows it's going to be for some sort of SwiftUI DSL thing, except they can't really tell us what it is and currently it provides a new the way to call a bunch of functions that is unergonomic and extremely special-purposed. When people say that Swift is adding "useless features" they don't really think that Swift should stop evolving; it's just that they're frustrated that stupid things like these keep getting added and that the Swift Evolution community as a whole is unable to stop them from being merged in or modified substantially.
- wool_gather 6y ago
  The multiple trailing closures case is also frustrating because they said "we're totally open to future evolution of this"...and then ruled out every proposed alternative with the "Principles" post.
- deleted 6y ago
  [deleted]
- alexashka 6y ago
  I'd take it up a few more levels and ask about the elephant in the room: in what significant way is this language better than C#? This outrage over closures reminds me of tabs vs spaces - it's one level above utter lunacy. Who gives a shit what the syntax is? Didn't we use Objective-C not long ago? Programming languages are a tool for me, not an artistic expression of text on a screen. What has this language allowed me to build that I couldn't in Objective-C? Let's use empirical evidence - why do we have electron apps for something as basic as a chat app (Slack) instead of a native app? We're going backwards in software tools as far as I can tell. Everything is more complicated and fragmented and Swift is a part of this mess, not a solution. Sorry, carry on with expressing opinions about syntax and pointing out that those who pay for the juke box, get to select the songs and are hypocrites when they pretend otherwise and press 'Billie Jean' when most people wanted 'Thriller'.
chmaynard 6y ago
It seems like every Swift-related discussion here eventually devolves into a debate about the design and evolution of the language. Okay, I'll weigh in. Comparing Swift with other important languages I have used such as C and SML, I think what's missing in Swift is a philosophy that inspires, motivates, and guides its development. I think Chris Lattner described Swift as a modern, practical language. Those are general characteristics but not the basis for a real philosophy. Others have described Swift as a "car crash" or "kitchen sink" language and I think those metaphors are apt. Swift seems to be trying to be imperative, functional, OO, and reactive all at the same time, with Obj-C compatibility thrown in for good measure. Complexity and intractability will inevitably follow.
- skohan 6y ago
  I actually like the kitchen-sink nature of Swift. If I could articulate a philosophy of Swift, it would be that the language prioritizes expressive, ergonomics and safety (in the single threaded case) over everything else. The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer. In spite of that, it might be a matter of opinion but I generally find Swift code among the most readable given the nature of the type system, and decisions around named arguments and when and how type inference may be applied.
  - hu3 6y ago
    The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink language can vary wildly. > The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer.
    - chmaynard 6y ago
      Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.
wool_gather 6y ago
I enjoy reading Marcel's Swift contrarianism (even if I don't always entirely agree with it). I work with Swift and ObjC on a daily basis. I remember the entirely appropriate skepticism that we in the Apple ecosystem had for ObjC when it was the main language. And I'm getting more and more tired of that healthy skepticism having turned into pointless bashing, accompanied by tall frosty pitchers of Swift kool-aid. No language is perfect, and it's important to be cognizant of the tradeoffs and flaws. There's no denying that Swift is a powerful language in many ways. But there's also no denying that the chosen means to that power has costs. The most obvious is a lot of complexity, both essential and non-essential. Which brings us back to the article and the peculiar way multiple trailing closures ended up being integrated.
c-smile 6y ago
Just in case, in Sciter script that could be written simply as: element.animate { duration: 300ms, completion: () => this.remove() } Explanation, this syntax construct nmtoken {...} is just a sugar for this: nmtoken ({...}) And that is good old function call with single object/map literal as a sole argument. By the way this construct can be added to JavaScript without breaking existing code.
- logicprog 6y ago
  Hashmap literals are the right approach to named arguments and functions-as-control-structures IMHO. Ruby does this too IIRC. It's great because it re-uses existing syntax and semantics instead of adding edge cases. You can even add syntax sugar like you just demonstrated.
- lioeters 6y ago
  I like this syntax improvement. It simplifies the very common case of calling a function with an object as a way to pass named arguments. It reminds me, I believe Lua has similar syntax sugar that works with tables as well as strings. fn "hello" is equivalent to fn("hello")
logicprog 6y ago
I checked Swift out really early on in its lifecycle, and, ignoring all the bugs, what immediately turned me off was this sense of to many features, even then. Not that a language having a lot of feature is bad - I use Rust for heaven's sake! - but there didn't seem to be a consistent purpose or logic behind it. I just got a really bad feeling in my gut about how the language would develop. So I left it alone ASAP. Now, my fears are confirmed. Swift is now iPerl.
neilv 6y ago
After spending a lot of time with Scheme (which is both relatively clean, and strong at syntactic extension), but doing iOS SwiftUI work at the moment, some of the Swift sugar is a reminder that Swift is a very different language. But I'm not above playing with sugar, including Smalltalk-inspired ones. In Racket, as an exercise, I implemented a straightforward way to do Smalltalk-like syntax for procedure calls. If the head of a list expression is a symbol that ends in a colon, then it was assumed to be the Smalltalk-ish procedure name sugar. A syntax like this: (foo: bar from: (+ 1 2) to: (funky 3)) would be translated by the reader to this procedure application: (foo:from:to: bar (+ 1 2) (funky 3)) You'd probably define the procedure in the usual Scheme way, like this: (define (foo:from:to: source start end) ...) Of course, I wouldn't use this complicating sugar in real code without a good reason.
kitd 6y ago
The trailing closure syntax is used in Groovy too. It is very useful for creating builders that look almost declarative, but provide access to flow control features in the language.
musicale 6y ago
Like the author, I also wouldn't mind a Smalltalk syntax flavor for the whole Swift language. ;-) Though having used Python a lot, I've also become something of a fan of braceless, indented syntax, which I find to be clear and conserving of vertical space. But I do understand the main argument for making it C-like: they wanted to make an easier transition for Apple developers who were already using Objective-C, and others who might be coming from Java/C#/C++/JavaScript/et al.. Also Smalltalk's syntax, while simple, orthogonal and versatile, simply never caught on the way C's did.

147 points by mwcampbell 6y ago

Arguably, the new syntax makes the anonymous trailing closure the special case now. Having done a bit of Ruby in the past I can see why it might be reasonable to have both.

AJRF 6y ago

I would really hate to be learning Swift now. I started using it around the v2 release and I think it had nice syntax & was relatively small and opinionated. Now there are so many ways to the same thing it must be a nightmare to teach. Each way of doing the same thing is in its own way nice, but they seem to just be accepting every half-way decent proposal for things they've already solved. I feel like SwiftUI had brought a number of challenges that have massively complicated the language and you can really feel it when you bump up against things that have been tacked on to make SwiftUI work (which it looks like they are getting around to smoothing out now - multiple trailing closures is very a much a problem compounded by SwiftUI). It's a shame, I loved this language from v2 -> v4, v5 was a good release but started to muddy the waters and now its just getting continually worse.

skohan 6y ago
> feel like SwiftUI had brought a number of challenges that have massively complicated the language and I've been a huge fan of Swift for years, and it's still one of the languages I reach for most for personal projects, but I was really put off by the way the rollout was handled for the features supporting SwiftUI, specifically property wrappers and function builders. Property wrappers in particular feel like a half-baked solution to paper over the lack of real meta-programming facilities. I think it was especially disheartening the way these changes were sprung on the community after being shown at WWDC. It just made the promise of Swift being an open source project built through a community-based process seem like a bit of a farce, and made me a bit more apprehensive about investing in a language which might radically change in direction based on the product needs of Apple.
tonyedgecombe 6y ago
It's difficult to dip in and out of, you really need to be focussed on it to become productive. It's interesting to compare it to C# which I learnt by opening the IDE and writing code. There was far less to trip you up in C# despite it also being a fairly big language.
j-pb 6y ago
That description sadly applies to every apple product, software or hardware wise, except for iPhone hardware maybe.
matt2000 6y ago
I agree with you. When Swift was introduced it was billed as a modern replacement for ObjC that was easier to learn, even a good choice as a language for learning to program. I'm not sure it was ever that, but it sure isn't now. I just got back into a project written in Swift 3 and had to change a bunch of stuff to get it to work in Swift 5. Why? I keep hearing the language is going to be stable "soon" but that doesn't appear to be happening. Swift appears to be a language for the captive audience of iOS devs, who are able to keep up if that's all they're doing. I don't really see it being adopted anywhere else.
- wool_gather 6y ago
  For what it's worth, source stability is definitely a much firmer constraint now in the minds of the core team: https://forums.swift.org/t/principles-for-trailing-closure-evolution-proposals/37265/18 https://forums.swift.org/t/principles-for-trailing-closure-e... Of course this comes with its own concerns, as you can see from that thread.
- skohan 6y ago
  To be fair, the pace of source breaking changes has slowed down considerably. From Swift 1 to Swift 3 there were many breaking changes between versions, and automated migration was very necessary. Between 3 and 4 there were some changes, and between 4 and 5 almost no source breaking changes. I think it's actually fair for a new language to take a somewhat cavalier approach to backward compatibility. I would rather not be stuck with all the naive mistakes made in the first version of a language just to avoid migration.
- JimDabell 6y ago
  > I just got back into a project written in Swift 3 and had to change a bunch of stuff to get it to work in Swift 5. Why? I keep hearing the language is going to be stable "soon" but that doesn't appear to be happening. Swift 3 was released in 2016. Swift is ABI / source / module stable now, but that doesn't make it retroactively stable with a version released four years ago.
- seandougall 6y ago
  > I keep hearing the language is going to be stable "soon" I think you may be referring to the promises of ABI stability? They kept promising that "soon" starting around Swift 3 (IIRC) and kicking the can down the road for a while there, but it is stable now on Apple's OSes. But I don't recall seeing promises of source stability back then; they were pretty open about the fact that the language was still evolving.
hombre_fatal 6y ago
Swift is trivial compared to the rest of iOS/macOS/iDevice development. CoreData, nasty Cocoa/AppKit APIs, SwiftUI buggyness, all the legacy objc cruft, 99% of resources online being for iOS, not macOS. Swift idiosyncrasies don't even put a dent in the learning curve imo. I don't think anything gets this across quite like onboarding experienced devs into a client app that haven't done mobile client dev before. They'll ask you completely reasonable questions about Appkit/UIKit/CoreData like why is NSBox used here and you realize 90% of the time your best answer is just "well, that's just kind of how you learn to do it over time." Very few questions about Swift itself.
- blondin 6y ago
  i agree with you on the iOS vs macOS comment! apple allowed this problem to happen. it's the same as allowing people to abuse SEO to get on the first page of results. apple told people that there is money in iOS and they went there. we are the worse. nobody is teaching you how to write a macOS app. heck, metal has been out for 6 years and there is zero book that will tell you how to set it up on the mac. if that goes on, metal will die because only few will use it. people are like metal is for library and framework and game engine builders. don't use it directly. yeah, and it is competing with and replacing opengl or vulkan. and people are using those directly. and there are bazillions of resources on those. kids are writing shaders in unity. oh let me give some kudos to the apple programming guides because they deserve it! i stopped looking for books and watching videos because of the iOS thing mentioned above. everything i needed was on developer.apple.com and i didn't know it. i started with the metal programming guide on my phone a few weeks ago. but that guide made it clear that i needed to understand the ecosystem first. so my detour took me through many others: the cocoa, the event system, the view hierarchy, etc. these guides have been the highlight of the past few weeks for me. they are better than most programming documentation out there. and i read them on my phone! i have 3 of them loaded in chrome on my phone right now. i still don't know what makes them so great but i intend to write about that at some point. one thing i figured is that they are light on code sample. reading code on the phone is really the worst. sorry long comment, but yeah, swift is not the best thing. i am finding great joy in objective-c and what came before because i went through these guides.
julius_set 6y ago
This really just sounds like nit-picking, the language is miles ahead of most other languages.
- saagarjha 6y ago
  You can criticize a language where it fails even if it is overall better than others.
deleted 6y ago
[deleted]
ksec 6y ago
>I would really hate to be learning Swift now. I started using it around the v2 release and I think it had nice syntax & was relatively small and opinionated. But the Swift team / Apple doesn't seems to be aware of it. ( At least a few internal Apple devs completely reject Swift for their project.) That is why I think Chris Lattner trying to make Swift scale from Javascript down to C was wrong from the start. And Swift will be like C# on Windows.

simias 6y ago

>And that's the frustrating part: this stuff was and is available and well-known. At least if you bother to look and/or ask. But instead, we just choose these things willy-nilly and everybody has to suffer the consequences. That could be it, or that could be that these days any language that doesn't have a syntax vaguely resembling C on one hand or Python on the other it is considered niche or "weird". You'll also have an endless stream of people commenting (mostly from the Python side) that your language is noisy, because they won't take the time to understand its syntax and it won't read like pseudocode, and that's a bad thing for some reason. But I digress, because that's a pet peeve of mine. Anyway, my point is that if Swift had Smalltalk-like syntax it would not have been nearly quite as marketable. The situation with Javascript is somewhat similar: under the hood the language is more like a Lisp than C, yet it awkwardly uses C-style syntax (and weird rules for automatic semicolon insertion, because that's more like peusdocode that way, and that's a good thing for some reason).

mpweiher 6y ago
> Smalltalk-like syntax would not have been nearly quite as marketable This was one bit I left out: with Objective-C, Apple had firmly established keyword syntax in a Tiobe top 3 language, albeit within square brackets, so there was absolutely no need to do this for "marketing". It truly was snatching defeat from the jaws of victory. > that your language is noisy Smalltalk is about as syntactically quiet as you can get.
- simias 6y ago
  To be clear I wasn't making the "noisy" critique myself, it's just a qualifier I've seen, in my opinion unfairly, applied to the syntax of certain languages in the past. I think the problem is not whether the language is really noisy or not, it's more whether the language is familiar or not. Nobody complains that "(x + 1) / (y * 4)" is noisy, even though it's more symbols than numbers or letters. Everybody is familiar with mathematical notation. I think deep down a lot of the "noisy" complaints are really about unfamiliarity, and that was my point: most coders aren't familiar with Smalltalk but most coders are familiar with C-style syntax, so it wins by default in the marketability department. It's a bit like when people who are first exposed to Lisp say "oh my god all these parens!" or when Python-first coders have to code in C and say "wow, I can't believe I have to put semicolons everywhere". Yet when one is familiar with these languages the parens/semicolon kind of fade away because you see the structure behind the tokens, so to speak. I don't even consciously notice semicolons anymore, and I type them without thinking as naturally as I hit "return" at the end of a line. But if you're just starting it does take a while to get used to them.

jtdev 6y ago

The closure obsession in Swift is really off putting. The amount of indirection in the language is frustrating and seems to be there due to an FP zealot somewhere in the language design team at Apple.

skohan 6y ago
I tend to find it really powerful and nice. The lightweight closure syntax is something I often miss in other languages

weiming 6y ago

Curious question as I am not a compiler expert. I have to do front-end iOS work from time to time and it's surprising how bad auto-complete can be in Xcode with Swift even after all these years: still randomly sluggish, randomly stops working inside closures including completely losing syntax highlighting inside the closure, and even Cmd+clicking to see the definition is a hit-or-miss as it sometimes opens up a blank editor and just spins. I would have thought that Swift having a strict type system would have made the IDE experience better, not worse. Don't know if the grammar is too complex or if it is the bridging with ObjC stuff or something else that made it difficult to build a robust solution. Can anyone shed light on this? My points of reference are rust-analyzer, or just VSCode with Typescript, both very snappy although of course the languages are very different. If anything I'd expect Swift to be closer to Rust experience-wise since they both have pretty strict grammars.

tonyedgecombe 6y ago
The JetBrains IDE[1] seems much better at this so I would assume it is an Xcode problem. [1]: https://www.jetbrains.com/objc/features/swift.html https://www.jetbrains.com/objc/features/swift.html
jmenter 6y ago
10 year iOS developer here. I don't have any answers for you (not a compiler expert either) but yeah, auto-complete of Swift in Xcode continues to suck in a lot of different ways. It's a shame because autocomplete in Obj-C was so good for so long (I'd put it up there with VSCode/TypeScript with some caveats), and is still pretty great, but seemed to get a little worse itself when Swift showed up.
- novok 6y ago
  I think it comes down to swift being a way slower performance language on the compiler side because of some bad early design decisions their compiler engineers will grumble about on twitter occasionally and xcode struggling with that fact. And apple underfunding their developer tools team that creates all of this.
6y ago

skohan 6y ago

I don't really get this complaint: > The already weird-ish addition of Smalltalk/Objective-C keywords inside the f(x) syntax: f(arg:x) I'm a huge fan of named arguments in Swift. It's one of the things I miss most when working with languages which don't have it. For instance, I do a lot of work with computer graphics, and in that case you end up with a lot of functions with a lot of arguments for things like configuration. With named arguments, code becomes almost self-documenting. Without them, I just end up using comments in their place, but of course then I don't have the compiler making sure this is correct. It's a totally optional language feature, and adds a lot of value in some cases.

choeger 6y ago
Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward. Think: f(fst:x, snd:y), what is the type of f(snd:4)? I think this can be implemented, but then f(3, fst:5) is either an error or counter-intuitive.
- skohan 6y ago
  Swift's approach to this is pretty good. Arguments have a fixed order, and whether or not they are named at the call-site is explicitly decided by the author of the function signature. In practice the order and identity of the arguments is quite clear in Swift.
  - codetrotter 6y ago
    As someone who kind of jumped into Swift coming from other languages, I still find this kind of stuff confusing. Is there a good intro to Swift that goes through only what is unique/peculiar about Swift and explains that in a good way to someone that already knows how to program?
    - bluk 6y ago
      I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.

jmull 6y ago

Swift language evolution seems to be heading in a bad direction. This is another change that adds nothing but extra, obfuscating complexity to the syntax. Now you’ll have to read and write yet another syntax variant, with slightly scrambled separators and brackets.

saagarjha 6y ago

As is tradition, I'm going to take the discussion one level up and talk about the language as a whole, although my issue is related to this syntactical change. The problem Swift has right now is that the review process is marred by huge conflicts-of-interests. The people reviewing proposals are very closely affiliated with, or sometimes the same people, that proposed it and want it implemented. And that's not to say they aren't smart, reasonable people; quite the opposite: it's just that they have their own interests when they're adding features to the language, and they ignore the community when doing so. When initial SwiftUI changes came through, they were "proposed" by Apple engineers even though they already shipped in Xcode. Sure, they got a bit of feedback and change, but everyone largely knew they were going in regardless and they did. When callAsFunction came in (which I actually think is a useful feature, just spelled horribly) it was obvious that it was being pushed heavily by the Swift for TensorFlow people. And who reviewed it? Chris Lattner, who approved it even though nobody really liked the name at all. And with this case we see a fairly dubious benefit being pushed forward by the team at Apple, and everyone knows it's going to be for some sort of SwiftUI DSL thing, except they can't really tell us what it is and currently it provides a new the way to call a bunch of functions that is unergonomic and extremely special-purposed. When people say that Swift is adding "useless features" they don't really think that Swift should stop evolving; it's just that they're frustrated that stupid things like these keep getting added and that the Swift Evolution community as a whole is unable to stop them from being merged in or modified substantially.

wool_gather 6y ago
The multiple trailing closures case is also frustrating because they said "we're totally open to future evolution of this"...and then ruled out every proposed alternative with the "Principles" post.
deleted 6y ago
[deleted]
alexashka 6y ago
I'd take it up a few more levels and ask about the elephant in the room: in what significant way is this language better than C#? This outrage over closures reminds me of tabs vs spaces - it's one level above utter lunacy. Who gives a shit what the syntax is? Didn't we use Objective-C not long ago? Programming languages are a tool for me, not an artistic expression of text on a screen. What has this language allowed me to build that I couldn't in Objective-C? Let's use empirical evidence - why do we have electron apps for something as basic as a chat app (Slack) instead of a native app? We're going backwards in software tools as far as I can tell. Everything is more complicated and fragmented and Swift is a part of this mess, not a solution. Sorry, carry on with expressing opinions about syntax and pointing out that those who pay for the juke box, get to select the songs and are hypocrites when they pretend otherwise and press 'Billie Jean' when most people wanted 'Thriller'.

chmaynard 6y ago

It seems like every Swift-related discussion here eventually devolves into a debate about the design and evolution of the language. Okay, I'll weigh in. Comparing Swift with other important languages I have used such as C and SML, I think what's missing in Swift is a philosophy that inspires, motivates, and guides its development. I think Chris Lattner described Swift as a modern, practical language. Those are general characteristics but not the basis for a real philosophy. Others have described Swift as a "car crash" or "kitchen sink" language and I think those metaphors are apt. Swift seems to be trying to be imperative, functional, OO, and reactive all at the same time, with Obj-C compatibility thrown in for good measure. Complexity and intractability will inevitably follow.

skohan 6y ago
I actually like the kitchen-sink nature of Swift. If I could articulate a philosophy of Swift, it would be that the language prioritizes expressive, ergonomics and safety (in the single threaded case) over everything else. The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer. In spite of that, it might be a matter of opinion but I generally find Swift code among the most readable given the nature of the type system, and decisions around named arguments and when and how type inference may be applied.
- hu3 6y ago
  The issue is we don't work alone. There are different people, teams and third-party code we have to deal with. And their preferred subset of a kitchen sink language can vary wildly. > The fact that you have a kitchen sink of language features lets you carve out the language of your choice and write code according to whichever paradigm suits you as a developer.
  - chmaynard 6y ago
    Agreed. My only experience with someone else's Swift project was discouraging, to say the least. I thought I understood the basic language syntax and semantics, but the source code I reviewed was almost incomprehensible.

wool_gather 6y ago

I enjoy reading Marcel's Swift contrarianism (even if I don't always entirely agree with it). I work with Swift and ObjC on a daily basis. I remember the entirely appropriate skepticism that we in the Apple ecosystem had for ObjC when it was the main language. And I'm getting more and more tired of that healthy skepticism having turned into pointless bashing, accompanied by tall frosty pitchers of Swift kool-aid. No language is perfect, and it's important to be cognizant of the tradeoffs and flaws. There's no denying that Swift is a powerful language in many ways. But there's also no denying that the chosen means to that power has costs. The most obvious is a lot of complexity, both essential and non-essential. Which brings us back to the article and the peculiar way multiple trailing closures ended up being integrated.

c-smile 6y ago

Just in case, in Sciter script that could be written simply as: element.animate { duration: 300ms, completion: () => this.remove() } Explanation, this syntax construct nmtoken {...} is just a sugar for this: nmtoken ({...}) And that is good old function call with single object/map literal as a sole argument. By the way this construct can be added to JavaScript without breaking existing code.

logicprog 6y ago
Hashmap literals are the right approach to named arguments and functions-as-control-structures IMHO. Ruby does this too IIRC. It's great because it re-uses existing syntax and semantics instead of adding edge cases. You can even add syntax sugar like you just demonstrated.
lioeters 6y ago
I like this syntax improvement. It simplifies the very common case of calling a function with an object as a way to pass named arguments. It reminds me, I believe Lua has similar syntax sugar that works with tables as well as strings. fn "hello" is equivalent to fn("hello")

logicprog 6y ago

I checked Swift out really early on in its lifecycle, and, ignoring all the bugs, what immediately turned me off was this sense of to many features, even then. Not that a language having a lot of feature is bad - I use Rust for heaven's sake! - but there didn't seem to be a consistent purpose or logic behind it. I just got a really bad feeling in my gut about how the language would develop. So I left it alone ASAP. Now, my fears are confirmed. Swift is now iPerl.

neilv 6y ago

After spending a lot of time with Scheme (which is both relatively clean, and strong at syntactic extension), but doing iOS SwiftUI work at the moment, some of the Swift sugar is a reminder that Swift is a very different language. But I'm not above playing with sugar, including Smalltalk-inspired ones. In Racket, as an exercise, I implemented a straightforward way to do Smalltalk-like syntax for procedure calls. If the head of a list expression is a symbol that ends in a colon, then it was assumed to be the Smalltalk-ish procedure name sugar. A syntax like this: (foo: bar from: (+ 1 2) to: (funky 3)) would be translated by the reader to this procedure application: (foo:from:to: bar (+ 1 2) (funky 3)) You'd probably define the procedure in the usual Scheme way, like this: (define (foo:from:to: source start end) ...) Of course, I wouldn't use this complicating sugar in real code without a good reason.

kitd 6y ago

The trailing closure syntax is used in Groovy too. It is very useful for creating builders that look almost declarative, but provide access to flow control features in the language.

musicale 6y ago

Like the author, I also wouldn't mind a Smalltalk syntax flavor for the whole Swift language. ;-) Though having used Python a lot, I've also become something of a fan of braceless, indented syntax, which I find to be clear and conserving of vertical space. But I do understand the main argument for making it C-like: they wanted to make an easier transition for Apple developers who were already using Objective-C, and others who might be coming from Java/C#/C++/JavaScript/et al.. Also Smalltalk's syntax, while simple, orthogonal and versatile, simply never caught on the way C's did.