Whither Swift?(lapcatsoftware.com)
lapcatsoftware.com
Whither Swift?
http://lapcatsoftware.com/articles/whither-swift.html
125 comments
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...
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...
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.
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.
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.
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.
Apple has totally rewrote the dock , in macOS Sierra in Swift.
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.
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.
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
"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."
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."
Totally agree with you. Further to that he is assuming that picking up Swift or Objective-C is the hard part of developing in the Apple ecosystem, when in my view it's picking up the Cocoa and Cocoa Touch APIs which are shared by either language.
I did receive the same impression as you when I read the article. I am not sure where the idea of pulling the plug on either language came from (that was a huge leap based on zero evidence) but given the investment by Apple themselves and their entire ecosystem for almost 20 years, objective-c is here to stay. If you're looking for where innovation is coming from - thats Swift.
We've got the same strategy on the Jenkins project. Blue Ocean is where the user experience innovation is going to be coming from now on and there will be incremental improvements in Classic. However, there is no way we could ever pull the plug on the classic UI.
We've got the same strategy on the Jenkins project. Blue Ocean is where the user experience innovation is going to be coming from now on and there will be incremental improvements in Classic. However, there is no way we could ever pull the plug on the classic UI.
Or you know, maybe a massive company somehow pushed through a project that was incredibly expensive and time consuming but had no justifications or plan.
Can't refute any of the article's arguments? Go ad hominem instead!
This is a reddit-style comment, not HN.
This is a reddit-style comment, not HN.
The author says, " Many developers have bet their livelihood on Swift."
sounds like you took offense to that and wrote..
"It's like listening to a broken-hearted man explain how his ex-lover will soon return to him."
sounds like you took offense to that and wrote..
"It's like listening to a broken-hearted man explain how his ex-lover will soon return to him."
He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation.
If you look at the source code of the Swift standard library, "toll free" bridging code is everywhere. It even affects the language design of both Swift and Objective-C.
Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable.
So I think the plan is very clear: Don't force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future.
There is a ton of evidence that they are in this dual mode for the long haul.
I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services.
My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs.
The pressure to make a clean break with Cocoa will grow because some un-idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone.
So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.
If you look at the source code of the Swift standard library, "toll free" bridging code is everywhere. It even affects the language design of both Swift and Objective-C.
Yes there are still inefficiencies, but they are small. Apple has done everything humanly possible to make this interface efficient, seamless and sustainable.
So I think the plan is very clear: Don't force people (including Apple itself) to rewrite old code. Make it possible and desirable to add new features to old Objective-C projects in Swift. Maybe let Objective-C die of old age at some point in the very distant future.
There is a ton of evidence that they are in this dual mode for the long haul.
I think the one flaw in their strategy is that people who like Swift will start to hate the antiquated object oriented design of Cocoa and some lower level OS services.
My prediction is that more and more of Cocoa will be wrapped with idiomatic Swift code that Objective-C devs will not want to adopt. At that point, there will effectively be two competing system APIs.
The pressure to make a clean break with Cocoa will grow because some un-idiomatic parts of Cocoa will be hard to wrap and people will call for a modern replacement for Cocoa long before Objective-C is gone.
So I think, most of the friction in this transition will arise on the library side, not with the languages themselves.
I agree with you, but just to play devil's advocate, don't forget that Apple spent a lot of time and effort on toll-free bridging between Objective-C and Java back in the day.
Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since.
I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).
Java was close to a first-class citizen on OS X and could even have eventually supplanted Obj-C (despite lacking some key features). Then Apple decided they didn't like Java any more, and running Java on OS X has been increasingly painful ever since.
I don't mean Swift would be ditched, if an analogous situation arose; rather, Apple could very easily decide to axe Obj-C if they don't feel like supporting it any more. They don't care at all about sunk costs (correctly, in most cases).
The obvious difference is that Apple had absolutely no control on Java's evolution as a language, that is clearly not the case with Swift.
Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap.
Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.
Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.
Yeah, the point I was trying to make is just that Apple could easily decide to ditch Objective-C in the relatively near future.
From our point of view as developers, there are good reasons not to, like maintaining backwards compatibility and keeping developers happy, but Apple generally seems to ignore those issues. Not that they actually want developers to be unhappy, they just expect and require them to fall in line.
(Or they could ditch Swift too and go with something entirely new and crazy, but that seems too unlikely even for me)
Edit to clarify: I think what they do care about is technical issues, and giving themselves the tools to make the slick products they want to make. And their technical strategy is generally pretty sound -- look at their balanced CPU+GPU designs on iOS, for example, both faster and more power-efficient than the ludicrous octo-cores and oversized screens you get on "flagship" Android devices.
To me, making Swift and Objective-C interoperable was a smart decision to give themselves (and coincidentally their developers) a smooth migration path. They also think that reference-counting is better than tracing GC for the types of applications they care about (and I think they're correct). But nothing in that says they care about keeping Objective-C around indefinitely.
From our point of view as developers, there are good reasons not to, like maintaining backwards compatibility and keeping developers happy, but Apple generally seems to ignore those issues. Not that they actually want developers to be unhappy, they just expect and require them to fall in line.
(Or they could ditch Swift too and go with something entirely new and crazy, but that seems too unlikely even for me)
Edit to clarify: I think what they do care about is technical issues, and giving themselves the tools to make the slick products they want to make. And their technical strategy is generally pretty sound -- look at their balanced CPU+GPU designs on iOS, for example, both faster and more power-efficient than the ludicrous octo-cores and oversized screens you get on "flagship" Android devices.
To me, making Swift and Objective-C interoperable was a smart decision to give themselves (and coincidentally their developers) a smooth migration path. They also think that reference-counting is better than tracing GC for the types of applications they care about (and I think they're correct). But nothing in that says they care about keeping Objective-C around indefinitely.
Toll-free bridging between a runtime that uses a tracing GC and one that doesn't share that exact same tracing GC is impossible. It's just a desperate stop gap.
And another thing! I assume this is referring to Java and Obj-C.
There's an alternate-universe proposal where this could have worked: Apple did actually briefly flirt with adding a traditional GC to Obj-C. If that had been successful, they could have essentially imported the Java memory model into Obj-C. However, the GC wasn't popular and was supplanted by Automatic Reference Counting.
I'm not sure if that's what anyone actually had in mind (I can't recall when the Java bridge and Obj-C GC started and stopped) but I think it would have been technically feasible.
I'd guess the iPhone would be very different in that world, or at least delayed, because GC has higher memory requirements and collector pauses make it hard to maintain a smooth UI. But you can make something like an iPhone using mostly Java, as Google proved with Android (eventually!)
And another thing! I assume this is referring to Java and Obj-C.
There's an alternate-universe proposal where this could have worked: Apple did actually briefly flirt with adding a traditional GC to Obj-C. If that had been successful, they could have essentially imported the Java memory model into Obj-C. However, the GC wasn't popular and was supplanted by Automatic Reference Counting.
I'm not sure if that's what anyone actually had in mind (I can't recall when the Java bridge and Obj-C GC started and stopped) but I think it would have been technically feasible.
I'd guess the iPhone would be very different in that world, or at least delayed, because GC has higher memory requirements and collector pauses make it hard to maintain a smooth UI. But you can make something like an iPhone using mostly Java, as Google proved with Android (eventually!)
I think Python is a good example of how things can happen.
Python's standard library includes a lot of pretty frustrating libraries, but offers a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage.
Think about requests vs. urllib (though technically requests' backend can be replaced).
I can imagine that Apple could write Swift libraries that are more idiomatic to the language by just wrapping Cocoa stuff. I mean, React Native can exist, so why can't this?
Python's standard library includes a lot of pretty frustrating libraries, but offers a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage.
Think about requests vs. urllib (though technically requests' backend can be replaced).
I can imagine that Apple could write Swift libraries that are more idiomatic to the language by just wrapping Cocoa stuff. I mean, React Native can exist, so why can't this?
I agree that wrapping can and does work in most cases. But then there are times when it doesn't work without introducing a lot of complexity and/or inefficiency or without limiting design choices.
How will the new concurrency/parallelism facilities they are planning for Swift work with libdispatch queues? Will they want to build on GCD or not? Will whatever they do work for Objective-C just as conveniently? That's an open question in my view.
For an example why wrapping cannot work efficiently in all cases look no further than Python 2 vs Python 3 strings. They are conceptually too different.
With enough "waste" of resources everything can be wrapped. I don't know how React Native works. But React.js uses a virtual DOM that effectively doubles memory usage. That's what gives them the freedom to use a completely different approach to updating the UI.
I put "waste" in quotes because sometimes paying for a more productive and simpler system with higher resource consumption is the right thing to do. But in other cases it is not.
How will the new concurrency/parallelism facilities they are planning for Swift work with libdispatch queues? Will they want to build on GCD or not? Will whatever they do work for Objective-C just as conveniently? That's an open question in my view.
For an example why wrapping cannot work efficiently in all cases look no further than Python 2 vs Python 3 strings. They are conceptually too different.
With enough "waste" of resources everything can be wrapped. I don't know how React Native works. But React.js uses a virtual DOM that effectively doubles memory usage. That's what gives them the freedom to use a completely different approach to updating the UI.
I put "waste" in quotes because sometimes paying for a more productive and simpler system with higher resource consumption is the right thing to do. But in other cases it is not.
To be honest, I don't think the DOM structure itself is what consumes the most memory.
It's about priorities, and having the UI building blocks be a bit slower is probably fine, because the actual UI internals will still be fast. How many times do you need to reflow your UI?
Though I'm not super aware of what Cocoa actually covers, my impression is that it's mainly UI libraries.
It's about priorities, and having the UI building blocks be a bit slower is probably fine, because the actual UI internals will still be fast. How many times do you need to reflow your UI?
Though I'm not super aware of what Cocoa actually covers, my impression is that it's mainly UI libraries.
> a lot of low-level functionality. So people can easily write wrapper libraries with more "pythonic" usage. Think about requests vs. urllib (though technically requests' backend can be replaced).
To my knowledge, requests is implemented on top of urllib3 (a third-party library from which it gets most of its advanced feature), not the stdlib's urllib or urllib2.
To my knowledge, requests is implemented on top of urllib3 (a third-party library from which it gets most of its advanced feature), not the stdlib's urllib or urllib2.
Ah, I stand corrected.
It seems like urllib3 uses Python's socket library stuff though? I guess that part of the code isn't the trickiest part.
It seems like urllib3 uses Python's socket library stuff though? I guess that part of the code isn't the trickiest part.
> He's missing a crucial piece of evidence. Apple has done a lot of work to make sure that Swift and Objective-C can coexist in same project. You can call Swift code from Objective-C and Objective-C code from Swift with little fuss. This is completely unlike Microsoft's C++/.NET situation.
How come?!?
That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.
How come?!?
That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.
.NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm.
Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET.
Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge.
You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc.
Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently.
But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET.
Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge.
You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc.
Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently.
But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
> Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET.
Yet that was exactly what I was doing in 2001.
Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time.
All the remaining layers were written in VB.NET and C#, using those components.
> You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime.
Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications.
> Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently.
They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects.
Since Windows XP, the majority of the new APIs are COM based not Win32.
Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries.
> . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
I can provide similar examples for Oracle, IBM, Apple and Google if you wish.
Yet that was exactly what I was doing in 2001.
Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time.
All the remaining layers were written in VB.NET and C#, using those components.
> You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime.
Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications.
> Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently.
They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects.
Since Windows XP, the majority of the new APIs are COM based not Win32.
Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries.
> . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.
I can provide similar examples for Oracle, IBM, Apple and Google if you wish.
>Yet that was exactly what I was doing in 2001.
Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C [...]
Exposing a low level C library to a .NET application isn't adding .NET to an average C++ application just because you prefer to write some new feature in C#. But that's exactly what Apple wants you to be able to do with Swift.
>Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications.
Like no one would ever do anything that isn't smooth or efficient.
>They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects.
Right. I think you know exactly how communicating strategic intent works. COM was relegated to legacy tech in 2000. They "embraced" it only to stay backwards compatible. They only rediscovered COM as a strategic piece of the puzzle rather recently after realizing what a huge mistake they had made back then.
>I can provide similar examples for Oracle, IBM, Apple and Google if you wish.
I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups?
Exposing a low level C library to a .NET application isn't adding .NET to an average C++ application just because you prefer to write some new feature in C#. But that's exactly what Apple wants you to be able to do with Swift.
>Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications.
Like no one would ever do anything that isn't smooth or efficient.
>They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects.
Right. I think you know exactly how communicating strategic intent works. COM was relegated to legacy tech in 2000. They "embraced" it only to stay backwards compatible. They only rediscovered COM as a strategic piece of the puzzle rather recently after realizing what a huge mistake they had made back then.
>I can provide similar examples for Oracle, IBM, Apple and Google if you wish.
I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups?
> I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups?
Yes, when many in HN and similar online forums pretend it is like that.
Not directly addressed to you, just that it is a common theme.
Yes, when many in HN and similar online forums pretend it is like that.
Not directly addressed to you, just that it is a common theme.
I'm least clear about whether a clean break with Cocoa will be needed. Perhaps most parts of Cocoa that don't match well with Swift will just be given more natural-feeling replacements? Obviously this can be complicated by dependencies, though.
That would almost certainly lead to a break with Cocoa.
Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be.
The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against.
I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action.
A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?)
It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature.
I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.
Those, for Swift programmers, more natural-feeling replacements will be harder to call from Objective-C than an API designed for Objective-C would be.
The only way to make neither side unhappy about it would be to provide two 100% equivalent interfaces, one for Cocoa and one for Carbon. That is unfeasible, so there will be differences. Even if they manage to write functionally and preformance-wise identical interfaces, not shipping them at the exact same time still would make the other side feel discriminated against.
I expect the first Swift-only library to appear on iOS because, on that platform, Apple can know exactly how much new code uses which language. That makes timing the transition easier. I also expect people to write glue code to call it from Objective-C, but that will be a rear-guard action.
A few years after that, I expect Apple to drop Cocoa. Deep below Swift, all the core stuff such as strings will still use the same code, but that will be hidden behind a Swift interface. After all, this is Apple, a company that isn't afraid to drop backwards compatibility. This is what happened with Carbon and Cocoa, too (how many years did that take?)
It won't happen overnight, though. Swift first needs to gain a few features (dynamism, more reflection, a frozen ABI, to mention a few), and the tooling must mature.
I think the first feature breaking interoperability with Objective-C may be a borrow checker, as that is something they have expressed interest in.
The author says "Objective-C and Swift cannot continue to coexist indefinitely." but their only supporting argument is that a multi-lingual platform is bad because nobody will know what language to choose.
This is the same charge that has been leveled against Microsoft since they don't use .NET to produce every single piece of Microsoft software. Has that somehow stopped .NET from continuing to grow? No, it has not.
Off-topic: Learned a new word reading this. Lacuna ~ an unfilled space or interval; a gap. Thanks!
This is the same charge that has been leveled against Microsoft since they don't use .NET to produce every single piece of Microsoft software. Has that somehow stopped .NET from continuing to grow? No, it has not.
Off-topic: Learned a new word reading this. Lacuna ~ an unfilled space or interval; a gap. Thanks!
Or JVM...
Java, Groovy, Scala, Closure
Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.
Java, Groovy, Scala, Closure
Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.
Not exactly the same thing since Oracle isn't maintaining any of those outside Java.
Quick spelling correction I think you mean Clojure. You got me searching for a new programming language that has a namespace conflict with a programming concept :) .
it's also a way to minify js https://developers.google.com/closure/compiler/
Autocorrect....
And "Apache Groovy" since it joined the ASF 2 years ago.
Perl and Python. Ruby and Rust.
It's almost as if people have more tools than they know what to do with!
It's almost as if people have more tools than they know what to do with!
It's an even sillier charge because the bulk of Apple's software relies on the Objective C runtime, including everything written in Swift. It's a multi-lingual platform where the new thing is (mostly) a language and one specifically designed to interoperate with the existing frameworks and runtime. The problem the article spends so much thought on feels like not much of a problem.
Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule.
You can't take one company's culture and apply it to a radically different one.
You can't take one company's culture and apply it to a radically different one.
>Apple reliably breaks waves of apps on a yearly schedule.
Not by suddenly stopping support for their previously sole language, so it's a moot point.
At worse, they deprecate some APIs.
Not by suddenly stopping support for their previously sole language, so it's a moot point.
At worse, they deprecate some APIs.
The point is not moot as concerns the comparison I was responding to, and illustrates the attitude at Apple toward software and software developers, which is relevant to the topic at hand.
If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions.
That would be very surprising news to iOS developers at large, I'm sure.
[0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/
If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions.
Except -- and this is really fun, thanks, Apple! -- I believe the current OSX
build will no longer work as a screen saver on MacOS 10.6. It will work on
10.5, and 10.7+, though. That's because 10.6 was the one and only version of
OSX in which ScreenSaverEngine required .saver bundles to use garbage
collection, and the latest release of Xcode has dropped support for emitting
GC-optional code entirely. So I can no longer compile a version that will run
on 10.6.
Also apparently the new app-store submission process requires that you set
the minimum iOS version to 5.1.1 or newer if you want to include a 64-bit
executable at all, despite the fact that the 32-bit executable runs just fine
on iOS 3. Thanks again, Apple!
Enforced obsolescence. Ain't it grand? [0]
That would be very surprising news to iOS developers at large, I'm sure.
[0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/
Be careful - your post mixes two different types of compatibility.
Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS.
So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem.
On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft.
For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC.
On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile.
Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today.
The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.
Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS.
So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem.
On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft.
For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC.
On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile.
Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today.
The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.
Note that I do not agree with the premise of the topic article, but then, even the author positions it as a low-probability thought experiment. I take the standard position that Apple is betting on Swift.
What I do not believe, and what I am arguing against, is that Objective-C will continue to be supported as an equally first-class development language. Apple fundamentally does prefer simplicity, and whenever there are two ways to achieve something one is likely to be pared, and probably not the new and shiny one. Apple can lose interest rapidly, and any API or technology that has fallen out of favor will simply and intentionally be allowed to rot. OpenGL on the Mac is stuck at a version from 2010 while Apple instead pushes its in-house Metal. Dashboard is a vestigial growth that hasn't even garnered enough attention to be cut off.
My examples were meant to illustrate that Apple will not put resources into supporting much more than the minimum if it can help it, and that extends to development. As you have noted, iOS is on an accelerated schedule when it comes to switching to new tech, and this is possible due to Apple's much greater control of the platform and its developers. Given the sheer amount of app breakage in the Store from release to release, my impression is that Apple cares less about old software compatibility on iOS than it does on the Mac; and of course, they also care much less about the Mac than iOS. The Objective-C runtime will continue to limp along behind Swift on the Mac, but I think that the day that Apple decrees that all new iOS applications must be written in Swift is coming sooner than some expect.
> But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001.
To my recollection, this was not quite so clear-cut at the time, at least to the public. Apple continued to maintain and add to Carbon in the years up to the 64-bit transition, releasing new Carbon sample code even as Cocoa got most of their attention. It was relatively common to mistakenly believe that the two APIs were simply different abstraction levels for the same functionality [0], and there were no serious signs of the imminent deprecation until around the five year mark. There is probably a historical lesson here.
[0]: http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_car...
What I do not believe, and what I am arguing against, is that Objective-C will continue to be supported as an equally first-class development language. Apple fundamentally does prefer simplicity, and whenever there are two ways to achieve something one is likely to be pared, and probably not the new and shiny one. Apple can lose interest rapidly, and any API or technology that has fallen out of favor will simply and intentionally be allowed to rot. OpenGL on the Mac is stuck at a version from 2010 while Apple instead pushes its in-house Metal. Dashboard is a vestigial growth that hasn't even garnered enough attention to be cut off.
My examples were meant to illustrate that Apple will not put resources into supporting much more than the minimum if it can help it, and that extends to development. As you have noted, iOS is on an accelerated schedule when it comes to switching to new tech, and this is possible due to Apple's much greater control of the platform and its developers. Given the sheer amount of app breakage in the Store from release to release, my impression is that Apple cares less about old software compatibility on iOS than it does on the Mac; and of course, they also care much less about the Mac than iOS. The Objective-C runtime will continue to limp along behind Swift on the Mac, but I think that the day that Apple decrees that all new iOS applications must be written in Swift is coming sooner than some expect.
> But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001.
To my recollection, this was not quite so clear-cut at the time, at least to the public. Apple continued to maintain and add to Carbon in the years up to the 64-bit transition, releasing new Carbon sample code even as Cocoa got most of their attention. It was relatively common to mistakenly believe that the two APIs were simply different abstraction levels for the same functionality [0], and there were no serious signs of the imminent deprecation until around the five year mark. There is probably a historical lesson here.
[0]: http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_car...
It was quite clear cut, even though you've found one person who was either confused or trying to be colorfully contrarian.
But the analogy to Carbon (or some other old tech/new tech switch) is really poor because Swift is just a language. There are no new Swift-based frameworks yet. After a few years of development, Swift itself is not a (let a lone the) true 'first class' language on Apple devices - that's still Objective C. It's going to take quite a while for Swift to assume that role, even if you think Apple is in a big hurry to accomplish that. There isn't much evidence of that to begin with.
But the analogy to Carbon (or some other old tech/new tech switch) is really poor because Swift is just a language. There are no new Swift-based frameworks yet. After a few years of development, Swift itself is not a (let a lone the) true 'first class' language on Apple devices - that's still Objective C. It's going to take quite a while for Swift to assume that role, even if you think Apple is in a big hurry to accomplish that. There isn't much evidence of that to begin with.
And when they do deprecate APIs, you've gotten a warning for at least the last 3 versions of Xcode that the API is going to be deprecated.
It was also the name of the mind-erasing company in Eternal Sunshine of the Spotless mind. That is a much better way to learn that particular word than this content-free meth-binge of an essay.
"meth-binge"?
I feel like it's possible you have not known very many people on actual meth.
I feel like it's possible you have not known very many people on actual meth.
Yes, I have known more alcoholics, heroin addicts, coke freaks, and all-around pill-poppers. I wonder if you think, my perhaps inapt essay-as-a-meth-binge-objectified metaphor aside, whether the essay was worth the length, because I am of the opinion that it was full of baseless speculation in a mode approaching paranoia.
Eh, I'm not really the target audience, being neither a (this decade) user of Apple's platforms nor a developer for same. Still, I thought it was interesting enough to justify the read. I'm interested in how problems like this play out in the broader sense, and (some) modes approaching paranoia have shown themselves to have predictive utility in recent decades.
Go take a look at the stims subreddit if you want to read an actual meth binge.
Chris Lattner talked about some of these issues on the Accidental Tech Podcast a few weeks ago: http://atp.fm/205-chris-lattner-interview-transcript/
It was a great episode and is worth the listen for those interested.
On Swift adoption at Apple:
"The Swift team itself has specific goals they need to achieve before there can be truly, across-the-board adoption at Apple. ABI stability is the number-one thing [35:30] that prevents framework developers, for example, from adopting Swift. That's a really important thing. That's one of the reasons it's always a really high priority. Swift has been adopted by application developers and other things. The Dock is public. Swift Playgrounds app is public. The Music app in iOS is publicly known. So there are definitely some big adopters.
More broadly though, the big problem is that I think, I won't speak for everybody but many, many people doing [36:00] Objective-C development at Apple are chomping at the bit. They want to be using Swift. It's really just a matter of getting the technology problems solved and checking off the things that are holding people back. It's not about people dragging their feet and not wanting to use it."
On whether to adopt Swift now:
"I don't [1:14:30] think Objective-C is going to go away anytime soon. Apple still supports C and C++ and there's no obvious benefit of dropping Objective-C, and obviously they have a ton of Objective-C code themselves."
He also described Apple's approach to some of the strategic questions that arose early on, such as whether to just invest in making Objective-C better instead of introducing Swift, and the various trade-offs involved.
It was a great episode and is worth the listen for those interested.
On Swift adoption at Apple:
"The Swift team itself has specific goals they need to achieve before there can be truly, across-the-board adoption at Apple. ABI stability is the number-one thing [35:30] that prevents framework developers, for example, from adopting Swift. That's a really important thing. That's one of the reasons it's always a really high priority. Swift has been adopted by application developers and other things. The Dock is public. Swift Playgrounds app is public. The Music app in iOS is publicly known. So there are definitely some big adopters.
More broadly though, the big problem is that I think, I won't speak for everybody but many, many people doing [36:00] Objective-C development at Apple are chomping at the bit. They want to be using Swift. It's really just a matter of getting the technology problems solved and checking off the things that are holding people back. It's not about people dragging their feet and not wanting to use it."
On whether to adopt Swift now:
"I don't [1:14:30] think Objective-C is going to go away anytime soon. Apple still supports C and C++ and there's no obvious benefit of dropping Objective-C, and obviously they have a ton of Objective-C code themselves."
He also described Apple's approach to some of the strategic questions that arose early on, such as whether to just invest in making Objective-C better instead of introducing Swift, and the various trade-offs involved.
> Apple could convert its entire Objective-C code base to Swift if they wanted. They certainly have the resources. The amount of liquid assets they own is staggering, of a size unprecedented in history. Nevertheless, their current corporate culture suggests they cannot or will not perform this conversion.
But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to. Bloomberg still has 25m lines of FORTRAN [0] — there's no need to rewrite code when it works fine already.
[0] https://etrading.wordpress.com/2006/06/01/25-million-lines-o...
But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to. Bloomberg still has 25m lines of FORTRAN [0] — there's no need to rewrite code when it works fine already.
[0] https://etrading.wordpress.com/2006/06/01/25-million-lines-o...
> But why? This would be an incredible waste of time and resources, to rewrite perfectly functional and working code. Rewrite it when you need to.
The functional mDNSResponder was rewritten and replaced with discoveryd, causing networking issues for millions of users. The popular Final Cut Pro was rewritten with FCPX, shedding many of its features and most of its userbase. The powerful and flexible QuickTime application and framework were rewritten and replaced with QTX, losing almost all of their functionality in the process. syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.
Throwing away working code and rewriting it, of late most often for the worse, is something of a habit at Apple.
The functional mDNSResponder was rewritten and replaced with discoveryd, causing networking issues for millions of users. The popular Final Cut Pro was rewritten with FCPX, shedding many of its features and most of its userbase. The powerful and flexible QuickTime application and framework were rewritten and replaced with QTX, losing almost all of their functionality in the process. syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.
Throwing away working code and rewriting it, of late most often for the worse, is something of a habit at Apple.
> syslog(1) was deprecated and replaced with log(1), a more verbose and difficult to use tool, for no discernible reason.
The new log store contains (or tries to) every old file in /var/log and every log-level flag in the system, so you can search them all in one timeline. It also improves privacy because all the %@ formats can be censored after a short time.
The new log store contains (or tries to) every old file in /var/log and every log-level flag in the system, so you can search them all in one timeline. It also improves privacy because all the %@ formats can be censored after a short time.
The perfectly reliable, predictable & functional headphone jack was replaced with a less-reliable, less-predictable & hence less-functional wireless headphone connexion too. C.f. https://discussions.apple.com/thread/7795564?start=0&tstart=...
His whole argument is that if Apple had to pick one language today, it would be Objective C because internally they have largely stuck with Objective C up to now.
Well, Apple isn't going to pick one language today. They might deprecate Objective C in 5 or 10 years, but in the near term nothing should change. They're infamous for dropping "legacy" so I wouldn't rule out Objective C having a finite lifespan.
The author is right that the developer community has really embraced Swift. It is a much nicer language, with a lot less visual noise, for example.
As a quick aside, I've been working on a Cookbook for the Swift:
http://www.h4labs.com/dev/ios/swift_cookbook.html
And I've been adding to a Github repo with lots of little examples:
https://github.com/melling/ios_topics/blob/master/README.org
Finally, the Stanford CS193 course has start for Swift and iOS 10:
https://itunes.apple.com/us/course/developing-ios-10-apps-sw...
Well, Apple isn't going to pick one language today. They might deprecate Objective C in 5 or 10 years, but in the near term nothing should change. They're infamous for dropping "legacy" so I wouldn't rule out Objective C having a finite lifespan.
The author is right that the developer community has really embraced Swift. It is a much nicer language, with a lot less visual noise, for example.
As a quick aside, I've been working on a Cookbook for the Swift:
http://www.h4labs.com/dev/ios/swift_cookbook.html
And I've been adding to a Github repo with lots of little examples:
https://github.com/melling/ios_topics/blob/master/README.org
Finally, the Stanford CS193 course has start for Swift and iOS 10:
https://itunes.apple.com/us/course/developing-ios-10-apps-sw...
Apple uses many languages internally. And swift & objective-c are very close in programming models in many ways. It's pretty natural for an ObjC dev to learn swift and vice versa I would imagine. If apple is having a hard time find new objective-c dev, but has swift devs, it will just train them.
A lot of code is in C++ at apple, like most of their graphics, UX & networking. Drivers in C. A lot of apps are non-ARC objective-C still and so on.
Also swift is not a solid enough language yet. Debuggers, compiling & indexing are too slow & unstable and there are things like ABI stability that are not delivered yet. I would give swift ~4+ years before it would be something to consider replacing Objective-C completely.
A lot of code is in C++ at apple, like most of their graphics, UX & networking. Drivers in C. A lot of apps are non-ARC objective-C still and so on.
Also swift is not a solid enough language yet. Debuggers, compiling & indexing are too slow & unstable and there are things like ABI stability that are not delivered yet. I would give swift ~4+ years before it would be something to consider replacing Objective-C completely.
Microsoft has managed to keep VB and C# alive and well supported even though its major codebases are in C++.
I don't think it's as big of a problem as the author seem to think it is.
I don't think it's as big of a problem as the author seem to think it is.
Actually even though C++ has first class support on UWP, I have noticed that the language focus at Microsoft developer presentations is showing it more for lower layers of the OS and games, with C# and VB being targeted for apps development, with F# getting the data science part.
F# isn't really aimed at data science, thats a common misconception ( I believe MS has ceased describing it that way). It's basically just a general purpose, functionally oriented language.
When they finally support it the same way as VB and C#, including the GUI tools, UWP, and some of the MSDN documentation about .NET, and above all when the F# community stops doing presentations about type providers as the single killer feature, then it will be a general purpose, functionally oriented language.
Currently I cannot use F# on UWP until .NET Core 2.0 gets released, cannot use the same workflows with Blend and Visual Studio as I do for C#, and while type providers are cool, I have zero uses for them.
Currently I cannot use F# on UWP until .NET Core 2.0 gets released, cannot use the same workflows with Blend and Visual Studio as I do for C#, and while type providers are cool, I have zero uses for them.
Yeah, I have no arguments here. If you're goal is a friction-less integration with Microsoft tooling and projects, F# is not the way to go (definitely C#). F# practitioners would do better to position themselves as just a language in it's own right, not necessarily an 'alternative to C#'.
Sort of like Elixir compared to Erlang.
Sort of like Elixir compared to Erlang.
[deleted]
That's exactly the point. All the talk from Microsoft about dev platforms has been about C# and .NET for over a decade now, but their flagship apps are actually still developed in C++.
There is a lot of C# in Visual Studio, SQL Server Management Studio, SQL Server Managed Stored Procedures, IIS Handlers, Office AddIns, Share Point, Dynamics, ...
Also don't forget that before the restructuring done by Satya, the Windows Dev unit was responsible for C++ and DevTools unit for .NET, and they didn't always get along, specially in the Longhorn days.
Also the Office team used to have their own internal fork of Visual C++, not sure how it looks like nowadays.
So don't get trapped seeing technology decisions for what was sometimes actually related to internal politics.
Also don't forget that before the restructuring done by Satya, the Windows Dev unit was responsible for C++ and DevTools unit for .NET, and they didn't always get along, specially in the Longhorn days.
Also the Office team used to have their own internal fork of Visual C++, not sure how it looks like nowadays.
So don't get trapped seeing technology decisions for what was sometimes actually related to internal politics.
[deleted]
[deleted]
[deleted]
I think the plan has always been that Swift is the future, but Objective C will be around for a long time. Think a 30-year horizon.
I would agree with this. I'm imagining Obj-C to eventually be Apple's COBOL. Even presently, a lot more job postings regarding iOS development are expecting Swift experience than even a year ago.
The piece is really well written and makes some good points (especially about Apples code base, the costs of rewrites, etc.)
I'm still perplexed by the argument that there are boxes like "Objective-C programmer" or "C++ programmer" and that this categorization is a good abstraction for thinking about these problems. In earnest, nobody working as a developer can expect to use the same tools in 5-10 years that they are using today, especially in fields like mobile.
It's not that hard to learn a new programming language if the paradigms are known from another language. Swift is not that different from other imperative languages that there would be a particularly bad learning curve.
I'm still perplexed by the argument that there are boxes like "Objective-C programmer" or "C++ programmer" and that this categorization is a good abstraction for thinking about these problems. In earnest, nobody working as a developer can expect to use the same tools in 5-10 years that they are using today, especially in fields like mobile.
It's not that hard to learn a new programming language if the paradigms are known from another language. Swift is not that different from other imperative languages that there would be a particularly bad learning curve.
This is nothing but inconclusive speculation. It mostly focuses on whether and when Obj-C will be retired, so the title should really be "whither Objective-C?"
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.
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.
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.
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.
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.
> 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.
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.
First off, I was always a huge obj-c fan, but I can tell you from first hand development of what is most certainly the largest and most complex pure Swift source tree that Swift has many serious advantages over obj-c. I am convinced we could not have such a stable product so quickly without it. It has immensely improved productivity. It has some shortcomings still and sometimes you do miss obj-c's dynamic dispatch, but on the whole Swift is far more than an evolution. I think Apple is definitely on the right track and you will see obj-c getting deprecated within the next 5 years or so. As others have mentioned, ABI stability is the number one issue preventing Apple from rewriting frameworks in Swift.
How can our apps be stable when compiler is not stable.
As far as I know all of Apple's framework code is in Objective-C, and there are two big problems standing in the way of converting it to Swift: AppKit and the like still has to support 32-bit apps (and it's apparently challenging to back-port that support to Swift) and Swift doesn't yet have ABI stability. (source: the SWIFT ADOPTION AT APPLE section here: http://atp.fm/205-chris-lattner-interview-transcript/)
There are a lot more challenges than just ABI and 32 bit. Swift is not dynamic, lacks many of the features the ObjC runtime provides - so most of Apple's frameworks cannot actually be implemented in the same way with Swift. Basic stuff like KVC, KVO, responder chain, etc. go out of the window. And many of Apple engineers are not convinced throwing these technologies out of the window for some imaginary benefit from Swift is the right direction.
This author has also forgotten about the annotations that Apple has provided to make interoperability between Swift and Objective-C quite a bit easier. See "Swift API Design Guidelines" from WWDC 2016.
Moving on ... "If Apple had to deprecate one of the two languages today, which would they deprecate?" Why is that even a question? I don't understand the motivation here. What if Apple had to decide between mobile hardware and desktop hardware? I guess they'd drop everything that wasn't the biggest revenue generator...
Moving on ... "If Apple had to deprecate one of the two languages today, which would they deprecate?" Why is that even a question? I don't understand the motivation here. What if Apple had to decide between mobile hardware and desktop hardware? I guess they'd drop everything that wasn't the biggest revenue generator...
Well exactly. Apple is opening a lot of stores in China with employees all speaking Chinese. Were all told 'China is the future'. Suppose Apple decided to standardise on one language for all their store. What would it be, English or Chinese? Equally daft.
If we take this perfectly sensible option, for which there is no obstacle to Apple pursuing it and which is Apple's stated intent off the table, which of these remaining bone headed options do you think Apple will choose? Er, who cares?
If we take this perfectly sensible option, for which there is no obstacle to Apple pursuing it and which is Apple's stated intent off the table, which of these remaining bone headed options do you think Apple will choose? Er, who cares?
>*
If 2 was the plan, I really wish Apple had been more forthcoming about it. The message from Lattner would have been misleading at best. If Swift is the future, why not be absolutely clear with developers about that, and let us plan accordingly*
Because it's nowhere near a short or even mid term thing? It will take a decade or more to be able to move to Swift 100%, and even then, it will came with ample warnings years ahead to port your Obj-C code over.
Because it's nowhere near a short or even mid term thing? It will take a decade or more to be able to move to Swift 100%, and even then, it will came with ample warnings years ahead to port your Obj-C code over.
> And of course Lattner has now left Apple, so he won't be there to take the criticism if his claim turns out to be false.
IIRC he said that he's going to still be on the core team of the language. I don't remember the email (and I can't find it right now) but I had the impression that for me, as a user, very little actually changed.
IIRC he said that he's going to still be on the core team of the language. I don't remember the email (and I can't find it right now) but I had the impression that for me, as a user, very little actually changed.
"This decision wasn't made lightly, and I want you all to know that I’m still completely committed to Swift. I plan to remain an active member of the Swift Core Team, as well as a contributor to the swift-evolution mailing list."
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
It's in Apple's best interest to continue supporting both. Why? Let's just remove the POV of app developers and simply look inside Apple.
The article mentioned a very important point. Apple itself has not adopted Swift as fast as the developer community. This is because (I don't know this for a fact, but am quite sure), a large portion of hw/sw engineers know how to write C, C++, and Obj-C. They don't just know how to write it, I bet a lot of them are damn good at it and if not, top in the industry. Why convert? As many mentioned in the comments, it would be a huge overhaul and what about Apple's internal engineers? Would they put themselves out of a job?...Not likely.
Maybe in 20 years (if there still is an Apple...), there will mostly be Swift engineers. I just don't see them shooting themselves in the foot by removing obj-c in the near future (as in 5-10 yrs).
The article mentioned a very important point. Apple itself has not adopted Swift as fast as the developer community. This is because (I don't know this for a fact, but am quite sure), a large portion of hw/sw engineers know how to write C, C++, and Obj-C. They don't just know how to write it, I bet a lot of them are damn good at it and if not, top in the industry. Why convert? As many mentioned in the comments, it would be a huge overhaul and what about Apple's internal engineers? Would they put themselves out of a job?...Not likely.
Maybe in 20 years (if there still is an Apple...), there will mostly be Swift engineers. I just don't see them shooting themselves in the foot by removing obj-c in the near future (as in 5-10 yrs).
This is a bad argument. Just because there’s a lot of chatter about Swift, doesn’t mean there’s more Swift code than ObjC out there. Of the 31 apps I have installed on my jailbroken phone, 9 contain libswift libraries. Of course, that doesn’t even mean the entire apps are written in Swift; most of the uses I see are for app extensions probably because they’re a more recent addition. Worse on my Mac – 7 out of 94 non-Apple apps installed.
You don’t throw away good code just because “eh, I like Swift better”. Couldn’t imagine having to justify rewriting good code to my employer. If it works, you keep shipping it till it breaks, then when it does break you spend a while fixing it and continue shipping it. Only when that becomes unviable do you consider rewriting it, and depending on the developer/project situation that may very well be in Swift.
Microsoft fell into the trap of rewriting good code with the failed Windows Longhorn project – for what was meant to be a minor release, they burned a heap of time rewriting large portions of Explorer (taskbar, start menu, folder windows) in C#. Explorer in all beta releases since the rewrite began were very unstable. They scrapped it and kept the existing C++ codebase. Fast forward now, Explorer still runs great in Windows 10 with the same C++ code, right? See also the Joel on Software article everyone usually links when this topic comes up: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Music, Calculator, and a minor part of the new Messages app were rewritten in Swift in iOS 10. Dock was supposedly rewritten in Swift in macOS Sierra, ditto Notification Center. Plenty of Touch Bar code is Swift. I think the fact that they’ve started to use Swift with new non-framework code is pretty important. But I’m certain there will still be ObjC in service for way longer than Apple removes its last line of it from the codebase. It can’t just be phased out like Rosetta or Carbon, especially when 3rd party apps are what keep iPhone sales up.
You don’t throw away good code just because “eh, I like Swift better”. Couldn’t imagine having to justify rewriting good code to my employer. If it works, you keep shipping it till it breaks, then when it does break you spend a while fixing it and continue shipping it. Only when that becomes unviable do you consider rewriting it, and depending on the developer/project situation that may very well be in Swift.
Microsoft fell into the trap of rewriting good code with the failed Windows Longhorn project – for what was meant to be a minor release, they burned a heap of time rewriting large portions of Explorer (taskbar, start menu, folder windows) in C#. Explorer in all beta releases since the rewrite began were very unstable. They scrapped it and kept the existing C++ codebase. Fast forward now, Explorer still runs great in Windows 10 with the same C++ code, right? See also the Joel on Software article everyone usually links when this topic comes up: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Music, Calculator, and a minor part of the new Messages app were rewritten in Swift in iOS 10. Dock was supposedly rewritten in Swift in macOS Sierra, ditto Notification Center. Plenty of Touch Bar code is Swift. I think the fact that they’ve started to use Swift with new non-framework code is pretty important. But I’m certain there will still be ObjC in service for way longer than Apple removes its last line of it from the codebase. It can’t just be phased out like Rosetta or Carbon, especially when 3rd party apps are what keep iPhone sales up.
Eventually most of the open source libraries will be Swift based, therein lies the answer, for the developers and for Apple. Apple doesn't need to drop Objective-C, the community will. I work with both, and like them both, although Swift is far better language.
First off, this is very well written. Secondly, I'd like to state that I think that Objective-C and Cocoa were really good. I disagree with most of the design paradigms today, but I think the Objective-C/Cocoa ecosystem represented something approaching a local maxima in the mutable programming space. Maybe not even a maxima, as I was actually really happy with the direction it was going pre-Swift (KVO was starting to get good in NSTreeNode, the language additions were welcome, etc.)
All this to say: I think the Swift transition was really misguided, and I was incredibly surprised that that wasn't the general take at the time. Everything about it seemed not well-planned out: the fact that no one at Apple had heard of it (you have the world's best ObjC programmers in-house and don't bother to get internal buy-in first!), the fact that it was really a response to C++ not Objective-C (this is so clear when listening to Lattner, who incidentally, did most his programming in C++ it seems), the fact that they sold it as good for everything from scripting to systems programming (huge red flag), and on and on.
But the real concern here was the opportunity cost. What was the problem they were trying to solve with Swift? That square brackets were off-putting? That a group that until that point were totally bought into dynamic dispatch should switch gears completely to a strict typed language? If you ask me, the only goal that should have mattered was making development easier and expanding the scope of people that could approach the platform. And, for the record, I am sure they believe they attacked this problem, I clearly disagree however.
I think the real areas ripe for improvement were the tools. Look no further than Facebook, with React Native and the no-recompile workflows where you change the UI and see it instantly on your device. This would have been game changers in making development easier, not adding Maybes (and this is coming from someone who does immutable development now). Objective-C could have been evolved into the language they wanted. It would have probably taken just as long as however long this "transition" is going to take, and it would have given everyone immediate actionable benefits instead of being a binary switch that comes along with the pain of having to ship the runtime.
Instead, we have discussions about whether Foundation is going to be rewritten in Swift. This seems like such an incredible misprioritization. Essentially creating a situation for yourself where you have to burn everything down and start from scratch, all while in the meanwhile have the head-scratching platform where the base libraries are written in a dynamic language and user land code is a strict systems language.
The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Rust guy, and he WILL tell you the reason to use Rust. Talk to a Haskell person and they'll do the same. The sole reason for Swift seems to be "to take over the world". It is decidedly not a very opinionated language in that regard. In the ATP interview, Lattner even said that dynamic dispatch may be added later to Swift so no one should worry about it, it seems like such a kitchen sink. (I loved the bit where he said that if they add in multiline string literals they can probably "win" the scripting space). Not a lot of passion there.
All this to say: I think the Swift transition was really misguided, and I was incredibly surprised that that wasn't the general take at the time. Everything about it seemed not well-planned out: the fact that no one at Apple had heard of it (you have the world's best ObjC programmers in-house and don't bother to get internal buy-in first!), the fact that it was really a response to C++ not Objective-C (this is so clear when listening to Lattner, who incidentally, did most his programming in C++ it seems), the fact that they sold it as good for everything from scripting to systems programming (huge red flag), and on and on.
But the real concern here was the opportunity cost. What was the problem they were trying to solve with Swift? That square brackets were off-putting? That a group that until that point were totally bought into dynamic dispatch should switch gears completely to a strict typed language? If you ask me, the only goal that should have mattered was making development easier and expanding the scope of people that could approach the platform. And, for the record, I am sure they believe they attacked this problem, I clearly disagree however.
I think the real areas ripe for improvement were the tools. Look no further than Facebook, with React Native and the no-recompile workflows where you change the UI and see it instantly on your device. This would have been game changers in making development easier, not adding Maybes (and this is coming from someone who does immutable development now). Objective-C could have been evolved into the language they wanted. It would have probably taken just as long as however long this "transition" is going to take, and it would have given everyone immediate actionable benefits instead of being a binary switch that comes along with the pain of having to ship the runtime.
Instead, we have discussions about whether Foundation is going to be rewritten in Swift. This seems like such an incredible misprioritization. Essentially creating a situation for yourself where you have to burn everything down and start from scratch, all while in the meanwhile have the head-scratching platform where the base libraries are written in a dynamic language and user land code is a strict systems language.
The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Rust guy, and he WILL tell you the reason to use Rust. Talk to a Haskell person and they'll do the same. The sole reason for Swift seems to be "to take over the world". It is decidedly not a very opinionated language in that regard. In the ATP interview, Lattner even said that dynamic dispatch may be added later to Swift so no one should worry about it, it seems like such a kitchen sink. (I loved the bit where he said that if they add in multiline string literals they can probably "win" the scripting space). Not a lot of passion there.
> The last thing I'll mention is the worrying lack of "purpose" for Swift. Talk to a Haskell person and they'll do the same.
Really? Real type safety and no null pointer exceptions unless you really want it are not a purpose? A compact syntax that is still as descriptive as Objective-C's syntax?
My programs are much more stable in a lot of regards since I started using Swift.
Really? Real type safety and no null pointer exceptions unless you really want it are not a purpose? A compact syntax that is still as descriptive as Objective-C's syntax?
My programs are much more stable in a lot of regards since I started using Swift.
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".
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".
> 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.
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.
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.
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.
> What was the problem they were trying to solve with Swift? That square brackets were off-putting?
If you think this is the difference between programming in Objective-C and Swift, you either haven't used swift much or are very misguided.
If you think this is the difference between programming in Objective-C and Swift, you either haven't used swift much or are very misguided.
Although responding to this one cherry-picked snarky statement I made is probably a mistake as its almost certainly clear from, for example, another difference I list in the immediately following sentence, I will bite and state that you probably underestimate the "Objective-C is weird" complex it suffered throughout its entire lifetime, and that that almost certainly contributed to considering writing/approving an entirely new language. Additionally, the reason to call out the square brackets is that many of the other Swift differences could have been integrated into an evolved Objective-C.
That sounds backwards to me. Syntax is fairly trivial, and adding a new syntax for message sends in Objective-C would have been easy. They already did this a bit by adding dot-syntax for accessing properties. Adding other major Swift features to ObjC, like pervasive type inference, generics, and capable value types would be much harder without effectively turning it into a new language.
(And yes, I know ObjC got generics recently, but it's not remotely the same as what Swift has.)
(And yes, I know ObjC got generics recently, but it's not remotely the same as what Swift has.)
> Syntax is fairly trivial
Logically, yes. Well, only sort of, but that's a different topic.
However, emotionally it seems to be of the upmost importance, and developers are just as human as the rest of the world, we just manage to rationalize our prejudices better than most.
I've talked to many, many developers as to why they like/enjoy/prefer Swift. A lot of the reasons that are given turn out to be, well, let's just say "less than substantive". And after a bit of digging it pretty much boils down to the "familiar" syntax.
YMMV
Logically, yes. Well, only sort of, but that's a different topic.
However, emotionally it seems to be of the upmost importance, and developers are just as human as the rest of the world, we just manage to rationalize our prejudices better than most.
I've talked to many, many developers as to why they like/enjoy/prefer Swift. A lot of the reasons that are given turn out to be, well, let's just say "less than substantive". And after a bit of digging it pretty much boils down to the "familiar" syntax.
YMMV
That always baffled me. I feel like an experienced developer should be like Cypher in The Matrix. "I don't even see the code. All I see is blonde, brunette, redhead." But I do realize that it's how some people work, even if I don't get it.
In any case, I was talking about the difficulty of making changes to a compiler, not how programmers react to it.
In any case, I was talking about the difficulty of making changes to a compiler, not how programmers react to it.
> a mistake as its almost certainly clear from, for example, another difference I list in the immediately following sentence...
I didn't reply to that sentence because I didn't want to have to point out your understanding of Objective-C was incorrect, it is not weakly typed, only some Foundation objects are weakly typed.
As the other comment here mentions, syntax is trivial (although being informed by 20 years of language design is not so trivial to me day to day), the key differences in overall safety, expressiveness and features in the language is far bigger than trivial method syntax.
I didn't reply to that sentence because I didn't want to have to point out your understanding of Objective-C was incorrect, it is not weakly typed, only some Foundation objects are weakly typed.
As the other comment here mentions, syntax is trivial (although being informed by 20 years of language design is not so trivial to me day to day), the key differences in overall safety, expressiveness and features in the language is far bigger than trivial method syntax.
Uh oh, about to get into an argument over terms that have no precise definition, but I believe that in the context of Objective-C vs. Swift, Objective-C is perfectly fair to be considered weakly typed. In fact I think that in the context of Objective-C vs. most other typed languages it is perfectly fair to consider Objective-C weakly typed, especially when the dominant culture involved using id everywhere and since generics were only added very late in the language so your base collection classes were all weakly typed for 99% of the life of the language. I'd find it really eyebrow-raising for someone to not consider Objective-C "more weakly typed" than Swift, or do you think that Swift did not introduce a culture of stronger typing?
But I digress: regardless of whether syntax is trivial or not, my point is that I believe wanting to have a clear break from a syntactic perspective with a language that was plagued as being "different looking" for its entire life was probably a goal in the creation of a new language. Do you really not remember pre-Swift where "Objective-C is weird looking" was an actual argument people would make? Objective-C could have been made more safe, it could not however have its syntax drastically altered without considering it a new language.
But I digress: regardless of whether syntax is trivial or not, my point is that I believe wanting to have a clear break from a syntactic perspective with a language that was plagued as being "different looking" for its entire life was probably a goal in the creation of a new language. Do you really not remember pre-Swift where "Objective-C is weird looking" was an actual argument people would make? Objective-C could have been made more safe, it could not however have its syntax drastically altered without considering it a new language.
Also, for the record, before Apple got serious about protocols, AppKit and WebKit were full of respondsToSelector: mumbo-jumbo, so you're just wrong about Objective-C not being weakly typed. If I can type it weakly, then it is weakly typed. And by can I mean can effectively, that is to say, thanks to Objective-C's reflection you can both use id and still interact with it, vs creating an AnyObject type class in a stricter strongly typed language where the compiler will not let you then just call whatever method you want on it. In fact, remnants of this clearly remain in WebKit where you have protocols where every method is optional, and thus everything is respondsToSelector: protected, making a "strongly typed" description highly suspect.
> your understanding of Objective-C was incorrect, it is not weakly typed,
That's an, er, interesting statement.
Objective-C is probably about as weakly typed as it is possible to get and still have the ability to write type annotations. From a static typing perspective, it combines the strongly dynamically typed world of Smalltalk with the weakly statically typed world of C, and with the strong possibility of C-style consequences (kaboom) if you get it wrong.
First of all, the ability to statically type Objective-C objects was added to the language after-the-fact (NeXTStep 2.x or 3.x?), and those types have been and continue to be largely cosmetic (with one crucial exception). So if I have "NSNumber *a" and the actual object is an NSString, the runtime will select the NSString methods, not the NSNumber methods.
Subverting the "type checking" is about as easy as can be: (a) assign from/to "id" (b) pipe through a collection (now we have pseudo-generics) (c) cast (d) declare methods on a protocol that you never implement anywhere (or that has been implemented somewhere else).
The crucial exception is that if you have, roughly speaking, C types (particularly ones that aren't equivalent to an 'id' in machine-representation) in your message signature, you will crash if you signatures are incompatible because you got the wrong one.
Which is why I advocate for the safe "id subset"[1].
Marcel
[1] http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid...
That's an, er, interesting statement.
Objective-C is probably about as weakly typed as it is possible to get and still have the ability to write type annotations. From a static typing perspective, it combines the strongly dynamically typed world of Smalltalk with the weakly statically typed world of C, and with the strong possibility of C-style consequences (kaboom) if you get it wrong.
First of all, the ability to statically type Objective-C objects was added to the language after-the-fact (NeXTStep 2.x or 3.x?), and those types have been and continue to be largely cosmetic (with one crucial exception). So if I have "NSNumber *a" and the actual object is an NSString, the runtime will select the NSString methods, not the NSNumber methods.
Subverting the "type checking" is about as easy as can be: (a) assign from/to "id" (b) pipe through a collection (now we have pseudo-generics) (c) cast (d) declare methods on a protocol that you never implement anywhere (or that has been implemented somewhere else).
The crucial exception is that if you have, roughly speaking, C types (particularly ones that aren't equivalent to an 'id' in machine-representation) in your message signature, you will crash if you signatures are incompatible because you got the wrong one.
Which is why I advocate for the safe "id subset"[1].
Marcel
[1] http://blog.metaobject.com/2014/05/the-spidy-subset-or-avoid...
> Objective-C could have been evolved into the language they wanted.
Swift is memory safe -- I'm not sure how one could evolve Objective-C into that, without breaking compatibility with the C subset.
Swift is memory safe -- I'm not sure how one could evolve Objective-C into that, without breaking compatibility with the C subset.
I think that would be the eventual goal, Objective-C minus C. Objective-C in a lot of ways was a vehicle for AppKit/UIKit, and that experience does not necessitate the C compatibility in my opinion. Don't get me wrong, the C compatibility is nice and allows some cool features when you need them, but I think it was more useful back in the day when performance was more of a concern, and a good FFI layer would be sufficient now.
> I think that would be the eventual goal, Objective-C minus C.
I still think that if your goal was this gradually typed language on top of a dynamic runtime, it would make more sense to start anew and model your language after, say, StrongTalk or (the good parts of) JavaScript/TypeScript, rather than trying to evolve the existing Objective-C language and Clang implementation.
I guess I mostly take issue with your characterization of Swift as C++ derived, or consisting of a collection of random features. The designers avoided a lot of the brokenness of C++, such as header files, copy constructors, compile-time instantiation of (what are essentially untyped) templates, etc, and when compared with Objective-C together with the C parts, the language seems mostly well-thought out and orthogonal, even if my personal preference would have been to start with less syntax sugar.
I think a better assessment is that Swift is sort of an Ocaml with more C-like syntax, together with some design decisions meant to ease interoperability with Objective-C, such as the choice to go with ARC over GC.
So this brings me to what I really wanted to say, which is that I feel like a gross simplification of your overall argument is that "I wanted Strongtalk, and they gave us Ocaml". I understand and respect that point of view, and don't really have a concise rebuttal to offer; it mostly comes down to personal preference. Perhaps if things had turned out the other way, we would instead be hearing a lot of feedback along the lines of, "Why is Apple ignoring the last 20 years of type system research", etc.
Another thing that's mostly lost in these discussions is that people lump a ton of mostly independent features under the banner of "dynamic dispatch". In a formal sense Swift has dynamic dispatch, in that you can write a function that call methods on a protocol, passing in different concrete types at runtime. That certainly qualifies in my opinion. I think what is really meant here is the following three capabilities:
1) Write reflection. Right now, Swift actually emits more metadata than Objective-C, in the sense that all values can be reflectively inspected, whereas the Objective-C runtime only knows about classes, and not anything else. For example you can print() any value in Swift and get a sort-of homoiconic representation back, showing the enum case and associated value, or the fields of a struct or tuple, etc. This is implemented with a 'Mirror' type in the standard library which reads this metadata produced by the compiler and presents it as a keyed collection that can be subscripted, iterated over, etc. What's missing here is presenting it as a mutable dictionary, and this can be added without introducing much complexity in the language.
2) Forming dynamic calls and introspecting the methods of a class, or the functions in a module. This is a bit more difficult to design and implement, but I think it can be introduced in a clean way that's sane to use. It's really quite a shame that Java has set the bar so low for such capabilities in a statically-typed language; while all the actual features are there (and you can even synthesize bytecode at runtime), it's incredibly awkward to use, which means developers constantly re-invent frameworks on top of these mechanisms over and over again, but they seem to only obscure the basic ideas further with a soup of FactoryFactories and XML files.
3) Proxy objects dynamically conforming to protocols. Again, this can be statically-typed; starting with a set of closures that implement the requirements of a protocol, the runtime could cook up the right structures to make it appear like an "ad-hoc" instance of the protocol that's not backed by a named concrete type. With the right API this could be quite pleasant and concise.
I believe all of these could be added in a clean way that's easy to use, mostly as library features without introducing new syntax or semantics. Their current absence should not be seen as an inherent limitation.
Finally, I agree with your point that interactive development is important and should be more of a focus in general. I think it's a shame that since the early 90s or so, programming language research has centered on designing (mostly statically-typed) languages with batch compilers, and not complete "environments" like Smalltalk-80, Self, Lisp machines, etc. It would be good to see more projects explore the latter, and the basic ideas should apply to both static and dynamically typed languages.
I like what you're doing with RunKit, by the way -- best of luck there.
I still think that if your goal was this gradually typed language on top of a dynamic runtime, it would make more sense to start anew and model your language after, say, StrongTalk or (the good parts of) JavaScript/TypeScript, rather than trying to evolve the existing Objective-C language and Clang implementation.
I guess I mostly take issue with your characterization of Swift as C++ derived, or consisting of a collection of random features. The designers avoided a lot of the brokenness of C++, such as header files, copy constructors, compile-time instantiation of (what are essentially untyped) templates, etc, and when compared with Objective-C together with the C parts, the language seems mostly well-thought out and orthogonal, even if my personal preference would have been to start with less syntax sugar.
I think a better assessment is that Swift is sort of an Ocaml with more C-like syntax, together with some design decisions meant to ease interoperability with Objective-C, such as the choice to go with ARC over GC.
So this brings me to what I really wanted to say, which is that I feel like a gross simplification of your overall argument is that "I wanted Strongtalk, and they gave us Ocaml". I understand and respect that point of view, and don't really have a concise rebuttal to offer; it mostly comes down to personal preference. Perhaps if things had turned out the other way, we would instead be hearing a lot of feedback along the lines of, "Why is Apple ignoring the last 20 years of type system research", etc.
Another thing that's mostly lost in these discussions is that people lump a ton of mostly independent features under the banner of "dynamic dispatch". In a formal sense Swift has dynamic dispatch, in that you can write a function that call methods on a protocol, passing in different concrete types at runtime. That certainly qualifies in my opinion. I think what is really meant here is the following three capabilities:
1) Write reflection. Right now, Swift actually emits more metadata than Objective-C, in the sense that all values can be reflectively inspected, whereas the Objective-C runtime only knows about classes, and not anything else. For example you can print() any value in Swift and get a sort-of homoiconic representation back, showing the enum case and associated value, or the fields of a struct or tuple, etc. This is implemented with a 'Mirror' type in the standard library which reads this metadata produced by the compiler and presents it as a keyed collection that can be subscripted, iterated over, etc. What's missing here is presenting it as a mutable dictionary, and this can be added without introducing much complexity in the language.
2) Forming dynamic calls and introspecting the methods of a class, or the functions in a module. This is a bit more difficult to design and implement, but I think it can be introduced in a clean way that's sane to use. It's really quite a shame that Java has set the bar so low for such capabilities in a statically-typed language; while all the actual features are there (and you can even synthesize bytecode at runtime), it's incredibly awkward to use, which means developers constantly re-invent frameworks on top of these mechanisms over and over again, but they seem to only obscure the basic ideas further with a soup of FactoryFactories and XML files.
3) Proxy objects dynamically conforming to protocols. Again, this can be statically-typed; starting with a set of closures that implement the requirements of a protocol, the runtime could cook up the right structures to make it appear like an "ad-hoc" instance of the protocol that's not backed by a named concrete type. With the right API this could be quite pleasant and concise.
I believe all of these could be added in a clean way that's easy to use, mostly as library features without introducing new syntax or semantics. Their current absence should not be seen as an inherent limitation.
Finally, I agree with your point that interactive development is important and should be more of a focus in general. I think it's a shame that since the early 90s or so, programming language research has centered on designing (mostly statically-typed) languages with batch compilers, and not complete "environments" like Smalltalk-80, Self, Lisp machines, etc. It would be good to see more projects explore the latter, and the basic ideas should apply to both static and dynamically typed languages.
I like what you're doing with RunKit, by the way -- best of luck there.
Good points. A couple of comments:
> I wanted Strongtalk, and they gave us Ocaml
Pithy, and there's some truth to that, but I would point out that (a) StrongTalk is now well over 20 years old (b) it has a sophisticated type-system that could certainly have been developed further and (c) it requires a JIT for performance.
But "Objective-C without the C" does point very strongly in the direction of Smalltalk, and a Smalltalk language that can be AOT compiled roughly as efficiently as Objective-C and is at least as compatible with C/Objective-C seems like not too much of a challenge.
After all, Objective-C now has tagged pointer objects, so a lot of the need for primitive objects has gone away. So let all literals/variables be objects by default and the syntactic overhead due to duplication goes away ( 1, @1, "string, @"nsstring" ).
What if we want "C" level primitives? Just type them:
So the point is not 'Objective-C forever', but rather: let's actually learn from what was good and bad about Objective-C and base our language design on that, rather than coming completely from left field and then only putting in compatibility kludges.
Then you wouldn't have the situation that we have now where people are clamoring for "pure Swift" versions of...well pretty much everything, and those things are, if "pure Swift" going to incompatible with what is there now. And more importantly, not build on the knowledge/learnings of what is arguably the best UI framework ever built.
> I wanted Strongtalk, and they gave us Ocaml
Pithy, and there's some truth to that, but I would point out that (a) StrongTalk is now well over 20 years old (b) it has a sophisticated type-system that could certainly have been developed further and (c) it requires a JIT for performance.
But "Objective-C without the C" does point very strongly in the direction of Smalltalk, and a Smalltalk language that can be AOT compiled roughly as efficiently as Objective-C and is at least as compatible with C/Objective-C seems like not too much of a challenge.
After all, Objective-C now has tagged pointer objects, so a lot of the need for primitive objects has gone away. So let all literals/variables be objects by default and the syntactic overhead due to duplication goes away ( 1, @1, "string, @"nsstring" ).
What if we want "C" level primitives? Just type them:
| aNumber |
| <NSNumber> aNumber |
| <int> aCInteger |
So the point is not 'Objective-C forever', but rather: let's actually learn from what was good and bad about Objective-C and base our language design on that, rather than coming completely from left field and then only putting in compatibility kludges.
Then you wouldn't have the situation that we have now where people are clamoring for "pure Swift" versions of...well pretty much everything, and those things are, if "pure Swift" going to incompatible with what is there now. And more importantly, not build on the knowledge/learnings of what is arguably the best UI framework ever built.
[deleted]
"change the UI and see it instantly" - I instantly thought of HyperCard. I wonder if a HyperCard like language/ui will ever make a comeback...
Yeah. Nothing has really come close to offering the same experience as HyperCard in my opinion. The key feature that no subsequent environment has really been able to copy is that there's no distinction between "running" and "editing" your program; while the UI is modal, this is mostly a convenience to avoid clutter, and fundamentally, your stack is always "running", whether you're authoring, editing data or just browsing.
Objective-C(++) are not going anywhere. I would start a new project in one of both languages without hesitation. It works, it's stable, there's tons of software out there and last but not least it's compatible with Swift.
I don't see any reason that Obj-C can't stick around for a long, long time, even if Swift is the "preferred" language.
Also, rumors of first-class support for Swift as a .NET family language are very interesting and would make the language much more realistic for cross-platform work. That could even lead to Unity support which would make me sooo happy. But I'm not the typical use case for sure.
Also, rumors of first-class support for Swift as a .NET family language are very interesting and would make the language much more realistic for cross-platform work. That could even lead to Unity support which would make me sooo happy. But I'm not the typical use case for sure.
> The application development environment for C was not Cocoa but rather Carbon, and Carbon has been largely deprecated.
This might be the template for the transition from Objective-C to Swift. I would be interested in the author's thoughts on that -- how is it similar or different? One could see a situation where Objective-C is still there, like C, just not of interest to most app developers.
This might be the template for the transition from Objective-C to Swift. I would be interested in the author's thoughts on that -- how is it similar or different? One could see a situation where Objective-C is still there, like C, just not of interest to most app developers.
Conversion to Swift is not something that must be done 100% at once (due to reuse of the Objective-C back-end), nor is it wise to change quickly (due to source and binary incompatibilities that have been very clearly documented for the first few Swift versions). Slow-moving engineering teams, even within Apple, are just being wise; they can still be firmly behind the move to Swift.
Does Swift support Windows and Linux?
If not, Swift will be doomed to be an Apple-specific language.
If not, Swift will be doomed to be an Apple-specific language.
Swift officially supports Linux, and there is unofficial Windows support (and I remember them saying they planned to support Windows officially, though I don't know if that's still a goal).
The Swift support on Linux is the bare minimum required to say "Swift supports Linux". I seriously doubt that Swift will ever be any more "portable" than Objective-C. That is, Swift, like Objective-C, is portable in theory, but nobody uses it for anything except to write programs for Apple's iOS/macOS platform.
Ibm has extensive support for swift on linux, and seem to be pushing it as a first class solutikn for thier linux based develooment.
https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura...
https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura...
Seems to me like the Server APIs group (https://swift.org/server-apis/) is pretty much about running Swift on non-iOS/macOS platforms.
[deleted]
The author likes Objective C and doesn't like Swift. That's fine. But he's let that emotional state override his rationality to the point that it totally colors and distorts his thinking.
None of his arguments hold together. They're all speculation based on supposition based on guesswork, and all under-laid by an almost desperate desire that this fantasy will come true, and that Apple will drop Swift. It's like listening to a broken-hearted man explain how his ex-lover will soon return to him. How this is a test that only make their love stronger in the end, etc.
Apple aren't going to drop Swift. It is the future of iOS and macOS development, and the sooner the author accepts that and moves on with his life, the better.