3 ms·

What I dislike about this situation is that Apple wants me to make software that only works, or works best, on their device. I want to make software that is as

What I dislike about this situation is that Apple wants me to make software that only works, or works best, on their device. I want to make software that is as portable as possible. I don't want my next programming language to come from someone who wants to lock me in. This makes me uncomfortable with Swift.

toyg 10y ago
Like Objective-C is a realistic choice anywhere but on OSX... If you play with Apple, you can only ask how high you have to jump. They will certainly not help you write cross-platform code, if they can avoid it. They practice lock-in very aggressively at all levels.
- valleyer 10y ago
  Yeah, it really was sneaky of Apple to convince NeXT to write their development framework in Objective-C a decade before they acquired them.
  - pjmlp 10y ago
    NeXT had a portable version of NeXTStep for Solaris and Windows, called OpenStep.
  - toyg 10y ago
    I didn't say that, no need to be snarky.
- simonh 10y ago
  Ok I'll grant that this is true, but it's completely irrelevant to this discussion. What platform vendor prioritises cross-platform development options over their native offering? Exactly. The reason Apple developed Swift rather than adopting another existing language is that they needed something that was a compatible and interoperable as possible with Obj-C. No other existing language had that to anywhere near the level Swift does. So really existing languages weren't a viable option given that goal. Meanwhile Apple doesn't aggressively try to prevent cross platform development offerings from working fine on their platform. You can write Apps for iOS in pretty much any language you choose, even C#. Sure you lose some platform specific features, but that's due to the nature of cross platform lowest common denominator dynamics, not because Apple has 'aggressively' tried to block anything. Finally, the fact that Swift was developed from scratch specifically in order to be as compatible with Obj-C argues strong against the premise of the article. If they'd adopted e.g. Dart or Go or something the article might make some sense, but Swift's Obj-C underpinnings are as clear a statement as Apple could possibly make that they're planning on supporting their existing Obj-C code base for the long haul.
  - toyg 10y ago
    > I'll grant that this is true, but it's completely irrelevant to this discussion Parent said he's uncomfortable with the choices Apple gives him; I pointed out that they are very much in line with standard Apple behaviour so it's unrealistic to expect anything better. I don't see how that's not relevant. > Apple doesn't aggressively try to prevent cross platform development offerings I see we've already forgotten everything about the fight to get cross-platform toolkits and runtimes accepted in iOS apps. It took a huge amount of pressure from developers for Apple to (partially) relent in this area, and still cross-platform toolkits have to jump through a lot of hoops to produce something the AppStore will accept. Apple use "quality" as an excuse to enforce technological lock-in. That's fine, everyone runs his own race, but let's not pretend that stercus non olet. > Swift's Obj-C underpinnings are as clear a statement as Apple could possibly make that they're planning on supporting their existing Obj-C code base for the long haul. I completely agree there. This is very much like VC++ and CLR: neither is going away anytime soon, they have very different roles. On one side, you have OS underpinnings that have to be close to the metal and as efficient as possible; on the other, you have userland apps for which speed of development is more important. I think this is the main take-away of the last 20 years of OS evolution: what is good for the OS is not necessarily good for app developers, and vice-versa. So all big players now have an OS story and an userland story: VC++/C# (MS), ObjC/Swift (Apple), C/Java (Android), C/Python-Java-JS (Linux)... Best tool for the job, and all that.

toyg 10y ago

Like Objective-C is a realistic choice anywhere but on OSX... If you play with Apple, you can only ask how high you have to jump. They will certainly not help you write cross-platform code, if they can avoid it. They practice lock-in very aggressively at all levels.

valleyer 10y ago
Yeah, it really was sneaky of Apple to convince NeXT to write their development framework in Objective-C a decade before they acquired them.
- pjmlp 10y ago
  NeXT had a portable version of NeXTStep for Solaris and Windows, called OpenStep.
- toyg 10y ago
  I didn't say that, no need to be snarky.
simonh 10y ago
Ok I'll grant that this is true, but it's completely irrelevant to this discussion. What platform vendor prioritises cross-platform development options over their native offering? Exactly. The reason Apple developed Swift rather than adopting another existing language is that they needed something that was a compatible and interoperable as possible with Obj-C. No other existing language had that to anywhere near the level Swift does. So really existing languages weren't a viable option given that goal. Meanwhile Apple doesn't aggressively try to prevent cross platform development offerings from working fine on their platform. You can write Apps for iOS in pretty much any language you choose, even C#. Sure you lose some platform specific features, but that's due to the nature of cross platform lowest common denominator dynamics, not because Apple has 'aggressively' tried to block anything. Finally, the fact that Swift was developed from scratch specifically in order to be as compatible with Obj-C argues strong against the premise of the article. If they'd adopted e.g. Dart or Go or something the article might make some sense, but Swift's Obj-C underpinnings are as clear a statement as Apple could possibly make that they're planning on supporting their existing Obj-C code base for the long haul.
- toyg 10y ago
  > I'll grant that this is true, but it's completely irrelevant to this discussion Parent said he's uncomfortable with the choices Apple gives him; I pointed out that they are very much in line with standard Apple behaviour so it's unrealistic to expect anything better. I don't see how that's not relevant. > Apple doesn't aggressively try to prevent cross platform development offerings I see we've already forgotten everything about the fight to get cross-platform toolkits and runtimes accepted in iOS apps. It took a huge amount of pressure from developers for Apple to (partially) relent in this area, and still cross-platform toolkits have to jump through a lot of hoops to produce something the AppStore will accept. Apple use "quality" as an excuse to enforce technological lock-in. That's fine, everyone runs his own race, but let's not pretend that stercus non olet. > Swift's Obj-C underpinnings are as clear a statement as Apple could possibly make that they're planning on supporting their existing Obj-C code base for the long haul. I completely agree there. This is very much like VC++ and CLR: neither is going away anytime soon, they have very different roles. On one side, you have OS underpinnings that have to be close to the metal and as efficient as possible; on the other, you have userland apps for which speed of development is more important. I think this is the main take-away of the last 20 years of OS evolution: what is good for the OS is not necessarily good for app developers, and vice-versa. So all big players now have an OS story and an userland story: VC++/C# (MS), ObjC/Swift (Apple), C/Java (Android), C/Python-Java-JS (Linux)... Best tool for the job, and all that.