7 ms·

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't e

I really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language. (There's a decent argument it encountered it in iOS and macOS too.) [1] https://github.com/swiftlang/swift-evolution/blob/main/proposals/0507-borrow-accessors.md https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. [2] https://medium.com/goodones/pareto-optimal-apple-devtools-b47e79b6676f https://medium.com/goodones/pareto-optimal-apple-devtools-b4...

tarentel 8mo ago
I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.
- ardit33 8mo ago
  I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves. Simple example: Objective-C if myObject { } in swift if myObject != nil { } Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]
  - andrekandre 8mo ago
    > you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-array/10767/135 https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...
    - umpalumpaaa 8mo ago
      Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind.. Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all. Infinite recursion is still a thing (not sure if this would even detectable - probably not). Misuse of APIs. And it introduces new issues: which methods are being called depends on your imports. In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.
      - andrekandre 8mo ago
        > And it introduces new issues: which methods are being called depends on your imports. also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift) > objc also has lightweight generics. In practice this is all you need. i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...
  - nielsbot 8mo ago
    I love Obj-C, but the Swift version isn't as bad as you say: if let myObject { // myObject is non-nil in here } The Swift version is also usingfirst-class optionals. In Obj-C there is very small chance you'll confuse `NULL` with `nil` or `0`. Or that you'll message `nil` resulting in `nil`.. and in well-built software you have to guard against that. Aside: Obj-C is narrowly focused on adding objects (in the Smalltalk sense) to C whereas Swift is trying to deliver a compiler and language with memory safety _guarantees_... Turns out that means you need a lot more language. Not to mention the `async` syntax/feature explosion. Obj-C is "hippie" and Swift is "corporate suit" + "we're doing serious work here!" Finally I want to say: I believe Obj-C was a huge competitive advantage and secret weapon that let Apple deliver an OS with so much more built-in functionality than any competitor for years and years. (Obj-C is great for system APIs) That's under-appreciated.
- simondotau 8mo ago
  A few years from now O'reilly will publish a bestseller called Swift: The Good Parts
cosmic_cheese 8mo ago
Obj-C’s simplicity can be nice, but on the other hand I don’t miss having to bring in a laundry list of CocoaPods to have features that are standard in Swift. I don’t miss maintaining header files or having to operate in old codebases that badly manage Obj-C’s looseness either.
- umpalumpaaa 8mo ago
  You can simply import Swift packages and either they expose an Objc interface or you can provide it yourself – by wrapping it in Swift and exposing the things you need via @objc etc. You can - at the same time - also hide the wrapped framework and make it an impl. detail of the wrapper so that you could switch the wrapped framework while keeping your app code mostly stable. This also reduces the number of imported symbols… import 3rdPartyFramework imports all symbols, extensions, classes, types etc. vs. import MyWrapper only brings in the things you really need.
nicoburns 8mo ago
> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.
- estebank 8mo ago
  One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
  - coliveira 8mo ago
    C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.
    - astrange 8mo ago
      C++ is trying to make something EASIER to use?
    - anthk 8mo ago
      C++ if any made C user friendly.
    - jcelerier 8mo ago
      how would you write something like #include <print> #include <map> #include <string> int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map<std::string, int> m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C
anextio 8mo ago
>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.
- glhaynes 8mo ago
  The "Swift has too many keywords now" meme makes me want to go insane. The vast majority of Swift code never runs into any of that stuff; so, what advocates of it are saying is in effect "we don't want Swift to expand into these new areas (that it has potential to be really good at) even if it's in a way that doesn't affect current uses at all." That said, the Swift 6 / Strict Concurrency transitions truly have been rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.
  - jshier 8mo ago
    Swift's concurrency story is what happens when a multi-year project meets Apple's fixed six month Swift release timeline. And being written by highly knowledgeable but low level engineers who've never written an iOS app in their life, means that there was a huge approachability hole they've only recently worked their way out of, but even that has major issues (MainActor default on in Xcode but not Swift itself).
    - ardit33 8mo ago
      Such a mess. You can tell the people that designed it never wrote a client or an app in their lives. It is pure academic pendatry in display.
pjmlp 8mo ago
I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it. I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead. However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Programming languages are products, even those that praise C's simplicity have certainly not read compiler manuals about language extensions, or the mailings from WG14 proposals.
- sinnsro 8mo ago
  > we wanted Delphi and got Haskell instead Please elaborate. > However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility. This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
  - pjmlp 8mo ago
    > Please elaborate. Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it. Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags. > Users also request those features. Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next. Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.
apple4ever 7mo ago
I never have to miss Objective-C because I still write in it! I never hopped on the Swift train because I saw it as an inferior language to Objective-C. And a decade later I'm more sure of that. It's such a joy to still write in an amazing language. Yes I use Python too and that is a joy. But nothing like Objective-C.

tarentel 8mo ago

I go back and forth. I do miss the simplicity of objc at times though. I think in a short amount of time someone can become close to an expert in objc. Swift is already incredibly complicated and there's no end in sight.

ardit33 8mo ago
I hate how pendantic and useless some of the features of swift being pushed down by academics that don't write apps or services themselves. Simple example: Objective-C if myObject { } in swift if myObject != nil { } Also opitionals in swift could have totally be avoided if they adopted a prototype based langue (basically object are never nil). Lua did this, and it is very elegant But meanwhile, we got a half backed optional system, which is backwards (similiar to Java), and didn't help with the practicality of the language at all, and meanwhile you still can crash an app doing myArray[1]
- andrekandre 8mo ago
  > you still can crash an app doing myArray[1] the first thing i do when starting a new project: extension Array { subscript(safe: Int) -> Element? { ... } } there was talk in the swift forms about adding that as standard that but it seems to have died off... [0] https://forums.swift.org/t/draft-adding-safe-indexing-to-array/10767/135 https://forums.swift.org/t/draft-adding-safe-indexing-to-arr...
  - umpalumpaaa 8mo ago
    Even with that there is nothing from you accidentally using [i]. Also there are just a ton of Swift APIS and bridge API that take an index and then crash… for full coverage you would need hundreds of safe wrappers… (doing what you propose though at least gives you. Some peace of mind.. Also Swift has a lot of other areas where it just lacks any safeguards… Memory issues are still a thing. It’s using ARC under the hood after all. Infinite recursion is still a thing (not sure if this would even detectable - probably not). Misuse of APIs. And it introduces new issues: which methods are being called depends on your imports. In my experience Swift lulls you into a false sense of safety while adding more potential safety issues and “only” solving some of the less important ones. objc has null ability as well. Which can warn u if used appropriately. objc also has lightweight generics. In practice this is all you need.
    - andrekandre 8mo ago
      > And it introduces new issues: which methods are being called depends on your imports. also depending on how you casted it, it will call the method of the cast, not the actual one in the instance (which completely caught be off-guard when i started swift) > objc also has lightweight generics. In practice this is all you need. i feel this too sometimes; sometimes simple really is best... tho i think some of these decisions around complexity is to allow for more optimization so c++ can be chucked away at some point...
- nielsbot 8mo ago
  I love Obj-C, but the Swift version isn't as bad as you say: if let myObject { // myObject is non-nil in here } The Swift version is also usingfirst-class optionals. In Obj-C there is very small chance you'll confuse `NULL` with `nil` or `0`. Or that you'll message `nil` resulting in `nil`.. and in well-built software you have to guard against that. Aside: Obj-C is narrowly focused on adding objects (in the Smalltalk sense) to C whereas Swift is trying to deliver a compiler and language with memory safety _guarantees_... Turns out that means you need a lot more language. Not to mention the `async` syntax/feature explosion. Obj-C is "hippie" and Swift is "corporate suit" + "we're doing serious work here!" Finally I want to say: I believe Obj-C was a huge competitive advantage and secret weapon that let Apple deliver an OS with so much more built-in functionality than any competitor for years and years. (Obj-C is great for system APIs) That's under-appreciated.
simondotau 8mo ago
A few years from now O'reilly will publish a bestseller called Swift: The Good Parts

cosmic_cheese 8mo ago

Obj-C’s simplicity can be nice, but on the other hand I don’t miss having to bring in a laundry list of CocoaPods to have features that are standard in Swift. I don’t miss maintaining header files or having to operate in old codebases that badly manage Obj-C’s looseness either.

umpalumpaaa 8mo ago
You can simply import Swift packages and either they expose an Objc interface or you can provide it yourself – by wrapping it in Swift and exposing the things you need via @objc etc. You can - at the same time - also hide the wrapped framework and make it an impl. detail of the wrapper so that you could switch the wrapped framework while keeping your app code mostly stable. This also reduces the number of imported symbols… import 3rdPartyFramework imports all symbols, extensions, classes, types etc. vs. import MyWrapper only brings in the things you really need.

nicoburns 8mo ago

> Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. Rust? Rust is basically a simpler Swift. The objective-c bindings are really nice too, and when you're working with obj-c you don't have have worry about lifetimes too much, because you can lean on the objective-c runtime's reference counting. I think the way to think about it is that with Rust, it's as if all the goodness in Swift was implemented with in the "C" level, and the Objective-C but is still just library-level a runtime layer on top. Whereas Swift brings it's own runtime which greatly complicates things.

estebank 8mo ago
One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
- coliveira 8mo ago
  C++ is trying to make C easier to use for 40 years, and it's still not there. So I wouldn't call that easier.
  - astrange 8mo ago
    C++ is trying to make something EASIER to use?
  - anthk 8mo ago
    C++ if any made C user friendly.
  - jcelerier 8mo ago
    how would you write something like #include <print> #include <map> #include <string> int main(int argc, char** argv) { using namespace std::literals; std::string foo = "foo:"; foo += argv[0]; std::map<std::string, int> m{ {foo, 123} , {"count: "s + std::to_string(argc), 456} }; std::println("{}", m); } in C

anextio 8mo ago

>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C. These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.

glhaynes 8mo ago
The "Swift has too many keywords now" meme makes me want to go insane. The vast majority of Swift code never runs into any of that stuff; so, what advocates of it are saying is in effect "we don't want Swift to expand into these new areas (that it has potential to be really good at) even if it's in a way that doesn't affect current uses at all." That said, the Swift 6 / Strict Concurrency transitions truly have been rough and confusing. It's not super clear to me that much of it could have been avoided (maybe if the value of Approachable Concurrency mode had been understood to be important from the beginning?), and the benefits are real, but my gut feeling is that a lot of the "Swift is too complicated" stuff is probably just misplaced annoyance at this.
- jshier 8mo ago
  Swift's concurrency story is what happens when a multi-year project meets Apple's fixed six month Swift release timeline. And being written by highly knowledgeable but low level engineers who've never written an iOS app in their life, means that there was a huge approachability hole they've only recently worked their way out of, but even that has major issues (MainActor default on in Xcode but not Swift itself).
  - ardit33 8mo ago
    Such a mess. You can tell the people that designed it never wrote a client or an app in their lives. It is pure academic pendatry in display.

pjmlp 8mo ago

I don't miss @ and [] all over the place, even if Objective-C has some cool ideas into it. I do agree Swift's design has gone a bit overbord, we wanted Delphi and got Haskell instead. However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Programming languages are products, even those that praise C's simplicity have certainly not read compiler manuals about language extensions, or the mailings from WG14 proposals.

sinnsro 8mo ago
> we wanted Delphi and got Haskell instead Please elaborate. > However note the same phenomen happening with other languages, as soon as you have a team being paid to develop a language, their job depends on adding features in every single release. Users also request those features. You said yourself that programming languages are products. In that sense, people are always evaluating them through the lenses of utility (the economics concept), and if they have to pick between two languages, with similar capabilities, they will pick up the one that maximises that utility. This to weird design decisions getting inserted into the fabric as a consequence (the current state of C++ comes to mind). And given developers are too opinionated about everything, we get politics as a side effect.
- pjmlp 8mo ago
  > Please elaborate. Ideally Swift would have been something with compile speed of Delphi, its RAD capabilities, strong typing with a good enough type system to support the transparent migration path from Objective-C, and that was it. Instead we have quite a few type systems ideas going back and forth, with some hard changes across language versions, as if playing with Haskell type system, and GHC feature flags. > Users also request those features. Some users request those features, most of them come from team themselves roadmap, regarding what cool features to add next. Then as politics get into the game, naturally the process of what features land into the stable implementation, and what fail by the wayside depends pretty much how they get pushed into adoption.

apple4ever 7mo ago

I never have to miss Objective-C because I still write in it! I never hopped on the Swift train because I saw it as an inferior language to Objective-C. And a decade later I'm more sure of that. It's such a joy to still write in an amazing language. Yes I use Python too and that is a joy. But nothing like Objective-C.