16 ms·

Swift Regrets

173 points by tempodox 5y ago

msoad 5y ago
Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?
- bsaul 5y ago
  i think there's a growing concern about the language complexity. I hope next releases are going to be about trimming down the language, and consolidating the not-so-sexy but very important other aspects (multiplatform, compilation speed, spm, tooling, etc) following golang's example.
  - deleted 5y ago
    [deleted]
- diskzero 5y ago
  The shorthands mystify me as well. I have taught a few courses using Swift and the shorthand notation, as well as implicit variables like oldValue and newValue in setters, are confusing. You can try to ignore them, but eventually a student will find them. In my experience, teaching courses using Racket have had better outcomes. At the end of the Racket courses, I can quickly transition students to other languages, including Swift. It hasn't worked out so well with Swift. I am still gathering data so I can come to a better conclusion as to why.
- throwdecro 5y ago
  > Swift has way too man shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. 100% agree. As a late adopter of Swift, I spent a lot of time looking at code that was so stingy with information that it was challenging to even formulate a Google-able question from it.
- SV_BubbleTime 5y ago
  > So I'm not sure who's the real beneficiary for all those shorthands? Coffee shop and college project app developers who are chasing the cool (be it tricks or frameworks). That’s not a knock, but that’s who I see using these things. We were hiring a guy for a Flutter app that had no previous experience in Dart, but turned us down because Dart lacked some whiz bang feature he had too grown accustomed to. I did not see this as a loss.
  - skavi 5y ago
    Could I ask what feature they were looking for? I haven't used Flutter in a while, but it left a good impression. I remember being far less annoyed using Flutter than I am using other declarative frameworks like SwiftUI.
    - SV_BubbleTime 5y ago
      I’m an embedded C guy, so you’ll have to forgive my ignorance on this. All this high level stuff is magic to me. But I want to say it was something larger than a conditional style or pattern matching and probably a state management framework. IDK, I had a good laugh about it and moved on. EDIT: As to good impression, yes, we’re very happy with Flutter.
- kyralis 5y ago
  Very much this. The original discussions around Swift talked about the value of being explicit rather than implicit and reducing surface area (for instance, no ++/-- increment/decrement operators). That goal appears to have been completely lost recently.
  - bsaul 5y ago
    My impression following swift forums is that original core team members were very concerned about relying a lot on first principles, whereas the new generation is more about building powerful constructs, in a fast paced way.
    - selcuka 5y ago
      The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible. [1] https://www.cocoaphile.com/posts/string-slicing-in-swift https://www.cocoaphile.com/posts/string-slicing-in-swift
      - kitten_mittens_ 5y ago
        This is a product of UTF-8 encoding, isn’t it? What’s the third index of “Füß”?
        selcuka 5y ago
        There is no reason they can't come up with a more readable API that works. Python says it's 'ß' and I'm fine with it as long as it's consistent: >>> "Füß"[2] 'ß'
      - bsaul 5y ago
        You can find a few extensions on stackoverflow that makes subscripting work with integers on strings. I'm still unsure why this isn't part of the stdlib..
      - fingerlocks 5y ago
BuyMyBitcoins 5y ago
I don’t know if this is Swift’s fault, per se but I find Xcode to be a real pain to use. There’s something about the Apple Way for UI/UX that just doesn’t jive well with an IDE experience. I find myself constantly jockeying around the various windows and panes within Xcode that I usually never have to bother with inside of Visual Studio.
- gwking 5y ago
  Xcode's faults preceded Swift by many years.
  - gurkendoktor 5y ago
    Some, yes. But in my experience, Xcode is/was amazingly responsive right until the first Swift file or IBDesignable class is added to a project. Then something happens in the background and everything starts to crawl.
- kennywinker 5y ago
  There is swift language tooling for vscode, if you’re so inclined.
- drclau 5y ago
  If you develop for iOS|macOS professionally, you may be interested in Jetbrains' AppCode [0]. Note: I'm not connected in any way to Jetbrains, and I have not used AppCode myself, but I used other tools from them, and they're quite competent, I'd say. [0]: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
  - w0mbat 5y ago
    Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.
    - 5y ago
rapsey 5y ago
Before Swift/Kotlin our iOS team was way more productive than android. Everything was done in half the time. They both switched to new languages. Now it has flipped. Android does things in half the time the other team needs.
- zionic 5y ago
  That's just your team then. Swift is far superior to Objective-C(rap) in terms of both speed and overall productivity.
  - jorgemf 5y ago
    Don't forget kotlin. It is a really game changer.
    - jshier 5y ago
      Yeah, this sounds like a tooling issue. I have no difficultly believing Kotlin + Android Studio might be faster or more reliable than Swift + Xcode. Hard to say with any certainty though, it could be any number of things, if the perceived difference is even real.
      - rapsey 5y ago
        From my outside looking in perspective: * Android studio is reliable and just works. * Kotlin is simple, easy to learn and productive. * xcode is buggy and with their rapid pace of development it is just getting worse. * Swift is complex. They had to rethink and redesign multiple times. Also the language was constantly changing under them.
        jshier 5y ago
        Swift hasn't changed much in the last 2.5 years, and was stable for the year before that, so it really shouldn't be an issue any more.
protomyth 5y ago
I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile. Bringing a new language into the world requires massive amounts of high quality documentation.
- zionic 5y ago
  > I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC, the sooner they get rid of that garbage the better.
  - protomyth 5y ago
    How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.
    - jbluepolarbear 5y ago
      No it’s not. If you have multiple parameters Obj-C is much longer and ugly.
      - iainmerrick 5y ago
        Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.
novok 5y ago
I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion during the compile step, in swift it does not and it tends to effectively max out at around 8 to 16-ish build threads. Even with 3 view toy apps made with SwiftUI on a M1 macbook is slow to build & run relative to it's size! Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. And you would actually have fast, responsive compile and indexing times, unlike swift.
- jshier 5y ago
  The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.
  - zozbot234 5y ago
    Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)
    - azakai 5y ago
      That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.
ink 5y ago
Honestly, I can't get my head around how anyone could prefer Objc over Swift. I suppose it's just years of writing Objc and not wanting the change? Like Swift is not a perfect language and Apple's developer docs lack useful examples a lot of times, but Objective-C has to be the least approachable language in all of app development.
wodenokoto 5y ago
This introduction post to the series of swift regrets is placed somewhere in the middle of all the posts. If you want to read these, it might be easier to start here: https://belkadan.com/blog/tags/swift-regrets/ https://belkadan.com/blog/tags/swift-regrets/
sharp11 5y ago
Unlike many commenters here, I came to praise Swift. Of course there will be regrets -- nothing's perfect -- but on the whole I think the designers (and community) did an amazing job with Swift. I say that after having written multiple apps in Objective C -- I would never consider going back. Optionals and null safety, first class enums, first class functions are just lovely in swift, all in a language that is super readable when well-written.
deleted 5y ago
[deleted]
dekhn 5y ago
I remember when the creator of Swift joined google and there was a lot of noise about Swift and Tensorflow. i told people while it seemed like a nice idea, it was never going to replace Python/C++. Eventually Lattner lost interest and the project died.
whiddershins 5y ago
So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.
- jamesfinlayson 5y ago
  I thought Objective C was dead - it'll still be supported (probably) but https://developer.apple.com/ https://developer.apple.com/ calls out Swift a lot but makes no mention of Objective C.
  - pjmlp 5y ago
    Then Metal is dead as well.
- johnthuss 5y ago
  Yes, you should learn Swift. The naming of things in Apple's APIs still comes through strong in Swift (due to named parameters), so it feels at home to programmers who were familiar with ObjC. Swift protects you from many crashes/bugs with its null safety and more strict compiler. In ObjC many clear coding mistakes are only marked with warnings, which is not helpful. Apple has clearly moved to Swift for all future development of new libraries, etc. So it would be foolish to stay in the past.
  - pjmlp 5y ago
    Metal is a mix of Objective-C and C++ (MSL C++14 dialect). So it will stay around for a while.
    - comex 5y ago
      What in MSL is based on Objective-C?
      - pjmlp 5y ago
asimpletune 5y ago
A lot of these things are odd cases that I would never encounter, but I'm surprised that there aren't bigger, more idea stuff in here. For example, not having an expression oriented syntax is really hard for me (I.e. everything returns a value, even if that value is void or whatever). Swift claims to have a lot of functional features, but it actually misses some of the most basic things.
deleted 5y ago
[deleted]
mafalda 5y ago
My main takeaway is that Swift is complex and tries to solve many problems. As a result it is going to frustrate almost everyone in one bit or another. I'm not an expert in the Swift Evolution process but I must praise it in terms of ease of reading. Back when I was invested in learning more about Swift, reading some proposals helped me understand it better. But I believe the Swift team/community will need to define a boundary some time in the future on what must be added or not to the language as its complexity grows. In the long run, even if a proposal makes sense, is implemented and was reviewed, it usually will also add a new thing to the language that implies in a bigger documentation and another way to code/solve a given problem. In the AnyObject dispatch regret [0], the author wrote "As I’ve mentioned many times (though not so much on this blog), Swift had to be as good as Objective-C at making most Cocoa apps, or people wouldn’t use it no matter how good the new stuff was". My first real contact with Cocoa was while learning Swift and I can imagine all the hard work that was put into it. Then SwiftUI came on together with a bunch of new features to a language that I was still getting used to. After getting frustrated with the lack of documentation (combined with the lack of knowledge about some patterns) and no clear way to solve small problems while studying it, I've decided to dive again into Objective-C to not only grasp most of in one week but also to find that I did not need most of the features Swift delivered. And this is something that is part of Swift. By design it offers you multiple ways to tackle your problems and by design it is only going to offer you more ways as time passes. I consider this a trait that is bad for the language itself in the long run. Looking back 7 years after the introduction of Swift I guess Apple would be better served if it just kept investing in Objective-C. But who knows what will Swift and its ecosystem look like in 2028. [0] https://belkadan.com/blog/2021/08/Swift-Regret-AnyObject-Dispatch/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-AnyObject-Dis...
gary17the 5y ago
I think a part of the problem with Swift is Swift's community apparent devotion to the "look, ma, advanced Swift!" mentality. The shorter, the more compressed and the more arcane the code, the better programmer one is perceived to be. For example, I've been criticized by code reviewers for using simple, short if/else block runs, while convoluted, multiply-composed higher-order function chains with platform API mixed in were recommended instead, yielding entire micro-features that no part of a problem statement even asked for. Moreover, if you also consider that Swift heavily uses type inference (if a compiler is allowed to infer something, your brain will have to as well, when you look at the code) and includes lots of edge-case syntactic variation (say, multiple trailing closures) or special-purpose features (say, SwiftUI builders), it is no wonder that even an advanced programmer can look at a piece of Swift and go: "WTF does this thing even do??". On top of all that, add a complicated generics system (i.e., Protocol-Oriented Programming) with conditional interface adoption and default implementation inclusion and you get a Frankenstein that only Apple fanatics can love. Swift seems to be great for only two kinds of programmers: the small snippet "Hello World" crowd and absolute Swift experts. Intermediate programmers probably just get lost in the language with a sinking feeling. Regardless of the fact that I have over 10 years of C++ under my belt, I experienced so much unexpected, recurring frustration with Swift over the course of a couple of years that I started migrating away toward Python. The devotion to simplicity, predictability and elegance expressed by the Python community feels, by comparison, revitalizing to me. Not a rant, just my $0.02.

173 points by tempodox 5y ago

Swift has way too many shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. In larger codebases a lot of shorthands are forbidden by the organizations for consistency. So I'm not sure who's the real beneficiary for all those shorthands?

bsaul 5y ago
i think there's a growing concern about the language complexity. I hope next releases are going to be about trimming down the language, and consolidating the not-so-sexy but very important other aspects (multiplatform, compilation speed, spm, tooling, etc) following golang's example.
- deleted 5y ago
  [deleted]
diskzero 5y ago
The shorthands mystify me as well. I have taught a few courses using Swift and the shorthand notation, as well as implicit variables like oldValue and newValue in setters, are confusing. You can try to ignore them, but eventually a student will find them. In my experience, teaching courses using Racket have had better outcomes. At the end of the Racket courses, I can quickly transition students to other languages, including Swift. It hasn't worked out so well with Swift. I am still gathering data so I can come to a better conclusion as to why.
throwdecro 5y ago
> Swift has way too man shorthand syntaxes. It feels nice from a language design perspective but when teaching Swift, you can see how confusing it is for the students. 100% agree. As a late adopter of Swift, I spent a lot of time looking at code that was so stingy with information that it was challenging to even formulate a Google-able question from it.
SV_BubbleTime 5y ago
> So I'm not sure who's the real beneficiary for all those shorthands? Coffee shop and college project app developers who are chasing the cool (be it tricks or frameworks). That’s not a knock, but that’s who I see using these things. We were hiring a guy for a Flutter app that had no previous experience in Dart, but turned us down because Dart lacked some whiz bang feature he had too grown accustomed to. I did not see this as a loss.
- skavi 5y ago
  Could I ask what feature they were looking for? I haven't used Flutter in a while, but it left a good impression. I remember being far less annoyed using Flutter than I am using other declarative frameworks like SwiftUI.
  - SV_BubbleTime 5y ago
    I’m an embedded C guy, so you’ll have to forgive my ignorance on this. All this high level stuff is magic to me. But I want to say it was something larger than a conditional style or pattern matching and probably a state management framework. IDK, I had a good laugh about it and moved on. EDIT: As to good impression, yes, we’re very happy with Flutter.
kyralis 5y ago
Very much this. The original discussions around Swift talked about the value of being explicit rather than implicit and reducing surface area (for instance, no ++/-- increment/decrement operators). That goal appears to have been completely lost recently.
- bsaul 5y ago
  My impression following swift forums is that original core team members were very concerned about relying a lot on first principles, whereas the new generation is more about building powerful constructs, in a fast paced way.
  - selcuka 5y ago
    The new generation doesn't seem to have a need for extracting substrings from strings then. The existing Swift syntax for slicing strings [1] is horrible. [1] https://www.cocoaphile.com/posts/string-slicing-in-swift https://www.cocoaphile.com/posts/string-slicing-in-swift
    - kitten_mittens_ 5y ago
      This is a product of UTF-8 encoding, isn’t it? What’s the third index of “Füß”?
      - selcuka 5y ago
        There is no reason they can't come up with a more readable API that works. Python says it's 'ß' and I'm fine with it as long as it's consistent: >>> "Füß"[2] 'ß'
    - bsaul 5y ago
      You can find a few extensions on stackoverflow that makes subscripting work with integers on strings. I'm still unsure why this isn't part of the stdlib..
    - fingerlocks 5y ago

BuyMyBitcoins 5y ago

I don’t know if this is Swift’s fault, per se but I find Xcode to be a real pain to use. There’s something about the Apple Way for UI/UX that just doesn’t jive well with an IDE experience. I find myself constantly jockeying around the various windows and panes within Xcode that I usually never have to bother with inside of Visual Studio.

gwking 5y ago
Xcode's faults preceded Swift by many years.
- gurkendoktor 5y ago
  Some, yes. But in my experience, Xcode is/was amazingly responsive right until the first Swift file or IBDesignable class is added to a project. Then something happens in the background and everything starts to crawl.
kennywinker 5y ago
There is swift language tooling for vscode, if you’re so inclined.
drclau 5y ago
If you develop for iOS|macOS professionally, you may be interested in Jetbrains' AppCode [0]. Note: I'm not connected in any way to Jetbrains, and I have not used AppCode myself, but I used other tools from them, and they're quite competent, I'd say. [0]: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
- w0mbat 5y ago
  Apple professionals use Xcode. Using different tools than the ones Apple uses leads to a lot of problems that Apple are not interested in fixing. The days when a company like Metrowerks or Symantec could be a viable third party IDE supplier are long gone.
  - 5y ago

rapsey 5y ago

Before Swift/Kotlin our iOS team was way more productive than android. Everything was done in half the time. They both switched to new languages. Now it has flipped. Android does things in half the time the other team needs.

zionic 5y ago
That's just your team then. Swift is far superior to Objective-C(rap) in terms of both speed and overall productivity.
- jorgemf 5y ago
  Don't forget kotlin. It is a really game changer.
  - jshier 5y ago
    Yeah, this sounds like a tooling issue. I have no difficultly believing Kotlin + Android Studio might be faster or more reliable than Swift + Xcode. Hard to say with any certainty though, it could be any number of things, if the perceived difference is even real.
    - rapsey 5y ago
      From my outside looking in perspective: * Android studio is reliable and just works. * Kotlin is simple, easy to learn and productive. * xcode is buggy and with their rapid pace of development it is just getting worse. * Swift is complex. They had to rethink and redesign multiple times. Also the language was constantly changing under them.
      - jshier 5y ago
        Swift hasn't changed much in the last 2.5 years, and was stable for the year before that, so it really shouldn't be an issue any more.

protomyth 5y ago

I guess I was in the minority who loved Objective-C and it's selector syntax. I think my main objection to Swift is that it seems to be written by people who hate Objective-C and made the calling syntax much more complicated. I dearly wish a more mature F-Script had been the next Apple language. A lot of the other problems is Apple not providing good documentation and making sure sample programs continue to compile. Bringing a new language into the world requires massive amounts of high quality documentation.

zionic 5y ago
> I think my main objection to Swift is that it seems to be written by people who hate Objective-C I mean that's the vast majority of people >and made the calling syntax much more complicated. How is this true? Swift is very straightforward, and similar to other languages Meanwhile Objective-C is slow, unsafe by default, with super ugly syntax only a mother could love. More than half of Apple's CVE/iOS vulnerabilities lately have been from parts of the OS that still use ObjC, the sooner they get rid of that garbage the better.
- protomyth 5y ago
  How is this true? Swift is very straightforward, and similar to other languages That's the argument, most people want to program in JavaScript or C++, learning is such a bother. The Swift syntax is more characters than ObjC's syntax.
  - jbluepolarbear 5y ago
    No it’s not. If you have multiple parameters Obj-C is much longer and ugly.
    - iainmerrick 5y ago
      Where are you getting this from? Swift’s mandatory named parameters come from Objective-C. For the most part only the bracket placement is different.

novok 5y ago

I'm surprised he doesn't bring up minor features that lead to huge compile time issues, like operator overloading and imports being module sized vs file or folder wide and type inference in some cases. Not to mention how the language doesn't actually scale that well with core count vs. many, many other programming languages. Throwing 64 cores / 128 threads at a C++ code base speeds up builds in a linear fashion during the compile step, in swift it does not and it tends to effectively max out at around 8 to 16-ish build threads. Even with 3 view toy apps made with SwiftUI on a M1 macbook is slow to build & run relative to it's size! Honestly you would have gotten %80-%90 of the benefits of swift by making Obj-C use a new syntax that looked like swift and continued to improve Obj-C as a language than what you would have gotten with swift. A lot of the ugly of obj-c could have been translated away with very simple 1:1 syntactic sugar macros. And you would actually have fast, responsive compile and indexing times, unlike swift.

jshier 5y ago
The main point of Swift was to create a memory-safe language Apple could use across its OSes. Trying to change Obj-C's syntax doesn't help with that goal.
- zozbot234 5y ago
  Swift does not provide memory safety for concurrent code. It has comparable pitfalls to Go. (You can use Thread Sanitizer to try and diagnose these issues, but that's best-effort and runtime-only; it does not make your code totally safe.)
  - azakai 5y ago
    That is true, but the great majority of memory safety issues are not concurrent ones. In practice Swift and Go are huge improvements over C, C++, and Objective-C in terms of memory safety. I'd also say they are in a reasonable space in the state of the art of safety in general. While they do not make concurrency safe and Rust does, in Rust you need to use unsafe to write things like doubly-linked lists and graphs (or resort to things like indexes-in-an-array), which you can do safely in Swift and Go. So there are interesting tradeoffs all around - our industry has not found a perfect solution here yet.

ink 5y ago

Honestly, I can't get my head around how anyone could prefer Objc over Swift. I suppose it's just years of writing Objc and not wanting the change? Like Swift is not a perfect language and Apple's developer docs lack useful examples a lot of times, but Objective-C has to be the least approachable language in all of app development.

wodenokoto 5y ago

This introduction post to the series of swift regrets is placed somewhere in the middle of all the posts. If you want to read these, it might be easier to start here: https://belkadan.com/blog/tags/swift-regrets/ https://belkadan.com/blog/tags/swift-regrets/

sharp11 5y ago

Unlike many commenters here, I came to praise Swift. Of course there will be regrets -- nothing's perfect -- but on the whole I think the designers (and community) did an amazing job with Swift. I say that after having written multiple apps in Objective C -- I would never consider going back. Optionals and null safety, first class enums, first class functions are just lovely in swift, all in a language that is super readable when well-written.

deleted 5y ago

[deleted]

dekhn 5y ago

I remember when the creator of Swift joined google and there was a lot of noise about Swift and Tensorflow. i told people while it seemed like a nice idea, it was never going to replace Python/C++. Eventually Lattner lost interest and the project died.

whiddershins 5y ago

So is Objective-C kinda going away after all? If I did a greenfield iOS or OSX app would it be malpractice to do it in Objective-C? Because I actually adore that language. Haven’t used it lately, but I do love it.

jamesfinlayson 5y ago
I thought Objective C was dead - it'll still be supported (probably) but https://developer.apple.com/ https://developer.apple.com/ calls out Swift a lot but makes no mention of Objective C.
- pjmlp 5y ago
  Then Metal is dead as well.
johnthuss 5y ago
Yes, you should learn Swift. The naming of things in Apple's APIs still comes through strong in Swift (due to named parameters), so it feels at home to programmers who were familiar with ObjC. Swift protects you from many crashes/bugs with its null safety and more strict compiler. In ObjC many clear coding mistakes are only marked with warnings, which is not helpful. Apple has clearly moved to Swift for all future development of new libraries, etc. So it would be foolish to stay in the past.
- pjmlp 5y ago
  Metal is a mix of Objective-C and C++ (MSL C++14 dialect). So it will stay around for a while.
  - comex 5y ago
    What in MSL is based on Objective-C?
    - pjmlp 5y ago

asimpletune 5y ago

A lot of these things are odd cases that I would never encounter, but I'm surprised that there aren't bigger, more idea stuff in here. For example, not having an expression oriented syntax is really hard for me (I.e. everything returns a value, even if that value is void or whatever). Swift claims to have a lot of functional features, but it actually misses some of the most basic things.

deleted 5y ago

[deleted]

mafalda 5y ago

My main takeaway is that Swift is complex and tries to solve many problems. As a result it is going to frustrate almost everyone in one bit or another. I'm not an expert in the Swift Evolution process but I must praise it in terms of ease of reading. Back when I was invested in learning more about Swift, reading some proposals helped me understand it better. But I believe the Swift team/community will need to define a boundary some time in the future on what must be added or not to the language as its complexity grows. In the long run, even if a proposal makes sense, is implemented and was reviewed, it usually will also add a new thing to the language that implies in a bigger documentation and another way to code/solve a given problem. In the AnyObject dispatch regret [0], the author wrote "As I’ve mentioned many times (though not so much on this blog), Swift had to be as good as Objective-C at making most Cocoa apps, or people wouldn’t use it no matter how good the new stuff was". My first real contact with Cocoa was while learning Swift and I can imagine all the hard work that was put into it. Then SwiftUI came on together with a bunch of new features to a language that I was still getting used to. After getting frustrated with the lack of documentation (combined with the lack of knowledge about some patterns) and no clear way to solve small problems while studying it, I've decided to dive again into Objective-C to not only grasp most of in one week but also to find that I did not need most of the features Swift delivered. And this is something that is part of Swift. By design it offers you multiple ways to tackle your problems and by design it is only going to offer you more ways as time passes. I consider this a trait that is bad for the language itself in the long run. Looking back 7 years after the introduction of Swift I guess Apple would be better served if it just kept investing in Objective-C. But who knows what will Swift and its ecosystem look like in 2028. [0] https://belkadan.com/blog/2021/08/Swift-Regret-AnyObject-Dispatch/?tag=swift-regrets https://belkadan.com/blog/2021/08/Swift-Regret-AnyObject-Dis...

gary17the 5y ago

I think a part of the problem with Swift is Swift's community apparent devotion to the "look, ma, advanced Swift!" mentality. The shorter, the more compressed and the more arcane the code, the better programmer one is perceived to be. For example, I've been criticized by code reviewers for using simple, short if/else block runs, while convoluted, multiply-composed higher-order function chains with platform API mixed in were recommended instead, yielding entire micro-features that no part of a problem statement even asked for. Moreover, if you also consider that Swift heavily uses type inference (if a compiler is allowed to infer something, your brain will have to as well, when you look at the code) and includes lots of edge-case syntactic variation (say, multiple trailing closures) or special-purpose features (say, SwiftUI builders), it is no wonder that even an advanced programmer can look at a piece of Swift and go: "WTF does this thing even do??". On top of all that, add a complicated generics system (i.e., Protocol-Oriented Programming) with conditional interface adoption and default implementation inclusion and you get a Frankenstein that only Apple fanatics can love. Swift seems to be great for only two kinds of programmers: the small snippet "Hello World" crowd and absolute Swift experts. Intermediate programmers probably just get lost in the language with a sinking feeling. Regardless of the fact that I have over 10 years of C++ under my belt, I experienced so much unexpected, recurring frustration with Swift over the course of a couple of years that I started migrating away toward Python. The devotion to simplicity, predictability and elegance expressed by the Python community feels, by comparison, revitalizing to me. Not a rant, just my $0.02.