5 ms·

I read the entire thing, and didn't get the impression you got. This arricle is pointing out two clear issues for Swift that need to be overcome. 1) that the de

I read the entire thing, and didn't get the impression you got. This arricle is pointing out two clear issues for Swift that need to be overcome. 1) that the default language to have the broadest support is obj-c; I see a lot of companies preferring to ship obj-c when they need to support a framework for both obj-c and Swift. 2) Apple needs to more fully commit to replacing code internally with Swift, by say making the decision to stop building new feature support into obj-c and only target Swift. This is more of a project management issue. It will be interesting to see what Apple ends up doing, but I agree with the article that long term support of both is not in Apple's best interests. Though my money is on Swift...

simonh 10y ago
Why are either of those problems? 1) If some developers still prefer to develop in Obj-C, good for them. Of course Obj-C still has the broadest support, Swift is still in the process of taking it's training wheels off. 2) Why should Apple want to replace any of their Obj-C code? If it's good code and works well and a lot of other code depends on it, replacing it just for the sake of it would be pointless. Partly all this depends on what you consider to be long term. Swift is coming to 3 years old. To my mind 5 years hence is the immediate future. Long term is like 20 years plus.
- bluejekyll 10y ago
  1) it is my understanding that libraries still need to be in obj-c for maximal compatibility. That is, there are some limitations to Swift code usage from obj-c. If I'm wrong about this, this would be excellent news! 2) code rot. As new feature development is started, if all the Devs are more comfortable with Swift, it is practical that it should be done in Swift. The obj-c libraries will languish. This is just a statement that if Swift becomes the default language, then Apple should only build new features in Swift. You're correct that code doesn't need to be replaced... if it ain't broke don't fix it, though in my experience eventually someone will find a way to break it, and it's at that point that someone ideally replaces it.
- rdsnsca 10y ago
  Apple has totally rewrote the dock , in macOS Sierra in Swift.
  - simonh 10y ago
    And presumably they had a reason for wanting to do so other than Swift Rulz. What I'm arguing against is not the idea that new code or new versions of things shouldn't be in Swift. Maybe they should, maybe they would be better in Obj-C on a case by case basis. I'm arguing against the idea that all the existing Obj-C code is an embarrassing legacy that must be purged as a matter of urgency or else we should all start panicking about it. Heck, large scads of the OS and the application services frameworks are written in plain old C - HealthKit is plain C. Long may that continue. Same for Obj-C.
    - rdsnsca 10y ago
      There is a thread on the old Apple Swift forum that addresses why they like Swift. Its an old post from 2014 called : Why Swift? And why now?. You will need at least a free developer account to be able to log in and see it. https://devforums.apple.com/message/986257#986257 https://devforums.apple.com/message/986257#986257 "13 of the security issues fixed in 10.9.4 could have been prevented or mitigated by Swift (9 buffer overruns, 2 int under/overflows, 2 null derefs). That alone makes it worth it from my point of view. As for performance, that's a work in progress but is improving rapidly; Swift is already faster than ObjC in some cases."

simonh 10y ago

Why are either of those problems? 1) If some developers still prefer to develop in Obj-C, good for them. Of course Obj-C still has the broadest support, Swift is still in the process of taking it's training wheels off. 2) Why should Apple want to replace any of their Obj-C code? If it's good code and works well and a lot of other code depends on it, replacing it just for the sake of it would be pointless. Partly all this depends on what you consider to be long term. Swift is coming to 3 years old. To my mind 5 years hence is the immediate future. Long term is like 20 years plus.

bluejekyll 10y ago
1) it is my understanding that libraries still need to be in obj-c for maximal compatibility. That is, there are some limitations to Swift code usage from obj-c. If I'm wrong about this, this would be excellent news! 2) code rot. As new feature development is started, if all the Devs are more comfortable with Swift, it is practical that it should be done in Swift. The obj-c libraries will languish. This is just a statement that if Swift becomes the default language, then Apple should only build new features in Swift. You're correct that code doesn't need to be replaced... if it ain't broke don't fix it, though in my experience eventually someone will find a way to break it, and it's at that point that someone ideally replaces it.
rdsnsca 10y ago
Apple has totally rewrote the dock , in macOS Sierra in Swift.
- simonh 10y ago
  And presumably they had a reason for wanting to do so other than Swift Rulz. What I'm arguing against is not the idea that new code or new versions of things shouldn't be in Swift. Maybe they should, maybe they would be better in Obj-C on a case by case basis. I'm arguing against the idea that all the existing Obj-C code is an embarrassing legacy that must be purged as a matter of urgency or else we should all start panicking about it. Heck, large scads of the OS and the application services frameworks are written in plain old C - HealthKit is plain C. Long may that continue. Same for Obj-C.
  - rdsnsca 10y ago
    There is a thread on the old Apple Swift forum that addresses why they like Swift. Its an old post from 2014 called : Why Swift? And why now?. You will need at least a free developer account to be able to log in and see it. https://devforums.apple.com/message/986257#986257 https://devforums.apple.com/message/986257#986257 "13 of the security issues fixed in 10.9.4 could have been prevented or mitigated by Swift (9 buffer overruns, 2 int under/overflows, 2 null derefs). That alone makes it worth it from my point of view. As for performance, that's a work in progress but is improving rapidly; Swift is already faster than ObjC in some cases."