3 ms·

I do not believe stability was the problem in iOS land (from my personal user perspective). The problems with iOS apps I experience most frequently come from a

I do not believe stability was the problem in iOS land (from my personal user perspective). The problems with iOS apps I experience most frequently come from a lack of handling asynchronous events and state management. I can frequently get programs into weird states due to clearly not handling edge cases in the way animations finish, or things loading before something else is ready, etc. I think attacking asynchronous flow management (the way countless other languages like JavaScript and Python and C# have with async/await for example) would have really demonstrated and understanding of the key space this language was going to be initially used for. Instead, async primitives are going to be missing for at least another version of the language, and programmers will remain using very primitive synchronous tools for managing increasingly complex asynchronous states demanded from ever more animation-heavy and internet-talking apps. I believe investing in asynchronous language additions for Objective-C would have lead to much more stability from a user perspective. And they aren't even mutually exclusive, Objective-C was already moving in the direction of more type safety and could have continued down that path. Separately, I think people that have used languages like elm or Haskell would argue that Swift does not present a particularly strong example of "real type safety". Both from a language perspective (yes certainly stricter than some languages, but not as strong as others), but also from a culture perspective. Haskell/elm people I think have a true culture of correctness in code (and arguably Rust as well from the type-for-ownership-safety perspective), which Swift does not particularly share as far as I can tell. Don't get me wrong, it is in fact "stronger" than Objective-C, but I don't think its the slam dunk go-to language for mission critical software, or guaranteed to be safe software either mind you. Again, I think an indicator of this is the fact that the creator is convinced it could rock both systems programming AND scripting. I think most other languages, if asked the big "why?", would tell you THE raison d'être for its existence. Aside for "the standard language for iOS apps" default answer, I don't get a strong sense of that from Swift, if I did, I think there would be a lot of work in "Swift is for X, we don't want to be distracted by Y right now" (I think many people want to write server code in elm, but they staunchly want to NAIL UI programming, Rust wants to NAIL systems programming with safety, etc.) With Swift its always "oh once we add this feature, then it'll be perfect for that too".

mpweiher 10y ago
> I do not believe stability was the problem in iOS land (from my personal user perspective) This. (And the parent). Almost everything that's an improvement in Swift rated at best a "nice to have" in my experience with development pain points. And what's really surprising is that, due to the flexibility of Objective-C, we actually had some fairly good ideas of where those pain points were: all the places runtime-dynamicism/metaprogramming was used to "extend" the language. So address these points, and better yet, create better metasystems that allow users of the language to tackle these issues with less hackery. Instead, pretty much crickets on all of these fronts, and at best grudging incorporation of minimal bridges to those same hacks. Wut? Instead a "playground" for the compiler to show how incredibly smart it is.
dep_b 10y ago
I think compatibility with Objective-C and existing libraries is one of the main reasons things like fragile callbacks [weak self] strong self dance still exists in Swift. I once got a different object returned than a Swift interface promised. That's definitely because of some kind of Objective-C library returning something completely else and still passing a compile. I like Objective-C and would still use it when I would need to use a lot of C or C++ libraries. But the compile time guarantees are simply better and forcing me to write safer code or removing a ton of boiler plate checks altogether.

mpweiher 10y ago

> I do not believe stability was the problem in iOS land (from my personal user perspective) This. (And the parent). Almost everything that's an improvement in Swift rated at best a "nice to have" in my experience with development pain points. And what's really surprising is that, due to the flexibility of Objective-C, we actually had some fairly good ideas of where those pain points were: all the places runtime-dynamicism/metaprogramming was used to "extend" the language. So address these points, and better yet, create better metasystems that allow users of the language to tackle these issues with less hackery. Instead, pretty much crickets on all of these fronts, and at best grudging incorporation of minimal bridges to those same hacks. Wut? Instead a "playground" for the compiler to show how incredibly smart it is.

dep_b 10y ago

I think compatibility with Objective-C and existing libraries is one of the main reasons things like fragile callbacks [weak self] strong self dance still exists in Swift. I once got a different object returned than a Swift interface promised. That's definitely because of some kind of Objective-C library returning something completely else and still passing a compile. I like Objective-C and would still use it when I would need to use a lot of C or C++ libraries. But the compile time guarantees are simply better and forcing me to write safer code or removing a ton of boiler plate checks altogether.