4 ms·

It's an officially sanctioned language for the apple ecosystem, meaning the bar has been lowered to "is it better than objective-c?", rather than "why bother".

SideburnsOfDoom 12y ago
Well, precisely. But there are a number of existing languages that would also be better than objective-c. And they had the benefit of pre-existing. Like with C#, a language "officially sanctioned language for the ... ecosystem" is not going to be a radical experiment, it will reflect proven wins. So it seems that apple made the decision that the benefits of rolling their own take on the current state of the art outweighed the costs associated with rolling their own.
- rsynnott 12y ago
  > But there are a number of existing languages that would also be better than objective-c. Which ones, exactly, would be better for Apple's purposes?
  - SideburnsOfDoom 12y ago
    I'm not that concerned with Apple's purposes. You could pick a third of the languages on this list and improve on Obj-C: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Or rust, D or go which you mentioned elsewhere. None of therm are ideal, all of them are > ObjC You could have an open ecosystem where all of them exist. That you don't is an indication of how "Apple's purposes" diverge from programmers' purposes.
    - rsynnott 12y ago
      > You could have an open ecosystem where all of them exist. That you don't... But you do, at least for two of them (D doesn't seem to support ARM yet). Here's Rust: https://github.com/rust-lang/rust/wiki/Doc-building-for-ios https://github.com/rust-lang/rust/wiki/Doc-building-for-ios And here's Go: https://bitbucket.org/minux/goios/wiki/Home https://bitbucket.org/minux/goios/wiki/Home Or you could write your iOS app in C, or C++, or Python, or... In all cases, you'll be calling objc_send a lot, and that's the problem. A Swift class can subclass an Objective C class, and implement Objective C protocols; good luck with that in a language with an incompatible object system. Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense; using existing APIs and third party libraries would be horrendous.
      - SideburnsOfDoom 12y ago
        > Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense Apple isn't stopping anyone, and Apple certainly isn't encouraging anyone from using any language that doesn't issue forth from Apple.
Kurtz79 12y ago
I don't have much experience in writing iOs apps, but the impression I always had is that the language is not nearly as important as it seems, to that end. Regardless of the language, the important (and most difficult) part is getting used to iOS framework, the patterns and models it uses, not to mention all the UI widgets and how they interact with each other. I don't think Swift will make it easier to deal with all that, regardless of how well has been thought out.

SideburnsOfDoom 12y ago

Well, precisely. But there are a number of existing languages that would also be better than objective-c. And they had the benefit of pre-existing. Like with C#, a language "officially sanctioned language for the ... ecosystem" is not going to be a radical experiment, it will reflect proven wins. So it seems that apple made the decision that the benefits of rolling their own take on the current state of the art outweighed the costs associated with rolling their own.

rsynnott 12y ago
> But there are a number of existing languages that would also be better than objective-c. Which ones, exactly, would be better for Apple's purposes?
- SideburnsOfDoom 12y ago
  I'm not that concerned with Apple's purposes. You could pick a third of the languages on this list and improve on Obj-C: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... Or rust, D or go which you mentioned elsewhere. None of therm are ideal, all of them are > ObjC You could have an open ecosystem where all of them exist. That you don't is an indication of how "Apple's purposes" diverge from programmers' purposes.
  - rsynnott 12y ago
    > You could have an open ecosystem where all of them exist. That you don't... But you do, at least for two of them (D doesn't seem to support ARM yet). Here's Rust: https://github.com/rust-lang/rust/wiki/Doc-building-for-ios https://github.com/rust-lang/rust/wiki/Doc-building-for-ios And here's Go: https://bitbucket.org/minux/goios/wiki/Home https://bitbucket.org/minux/goios/wiki/Home Or you could write your iOS app in C, or C++, or Python, or... In all cases, you'll be calling objc_send a lot, and that's the problem. A Swift class can subclass an Objective C class, and implement Objective C protocols; good luck with that in a language with an incompatible object system. Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense; using existing APIs and third party libraries would be horrendous.
    - SideburnsOfDoom 12y ago
      > Apple isn't stopping anyone from using those languages; it's just that adopting them would make very little sense Apple isn't stopping anyone, and Apple certainly isn't encouraging anyone from using any language that doesn't issue forth from Apple.

Kurtz79 12y ago

I don't have much experience in writing iOs apps, but the impression I always had is that the language is not nearly as important as it seems, to that end. Regardless of the language, the important (and most difficult) part is getting used to iOS framework, the patterns and models it uses, not to mention all the UI widgets and how they interact with each other. I don't think Swift will make it easier to deal with all that, regardless of how well has been thought out.