Chris Lattner ATP Interview
Accidental Tech Podcast did a great interview with Chris Lattner (tweet). The whole episode is worth listening to, but here are some of my thoughts:
He seems to agree that the “Objective-C without the C” branding for Swift was more about making developers feel comfortable with the language than it was a description of what the language actually is and aspires to be.
With so many other responsibilities at Apple, Swift was always kind of a side project for him. So his leaving Apple is less of a change for Swift than one might think.
It sounds like Tesla is primarily interested in his engineering and management skills. They might at some point use Swift for something, but it does not sound like he was hired to adapt it for their purposes, as some have speculated.
He thinks the criticisms of Swift not being dynamic enough are overblown because many dynamic features, such as introspection, can and likely will be added to Swift in the future. I agree with the latter and am not worried that patterns like the responder chain will be impossible. My main concern has been that message passing is opt-in rather than the default. This closes the door on unanticipated swizzling and other techniques. Once the dispatches have been baked in (or, I guess, out) they cannot be changed. This is not an area where Swift can satisfy both camps, and it has been obvious from day one which way it leans. So I think it would have been rather pointless to try to argue this point on Swift Evolution.
Objective-C literals are described as an easy sugar feature that Apple added while much of the team was busy with Swift. I have never understood why it took so long for this feature to arrive. It could have been added to Objective-C 1.x but instead came about 6 years after Objective-C 2.0. Or, to put a positive spin on this, the rate of progress with Swift is incredible compared with what we saw with Objective-C.
Swift doesn’t support 32-bit Intel for Mac or the old Objective-C runtime. I had assumed this would mean that Apple would drop support for the 32-bit frameworks as it starts using Swift internally, but he seems to think that Swift will add 32-bit support so that it can be used in AppKit.
There is a great overview of ARC vs. garbage collection. I think ARC was absolutely the right choice.
He makes a strong argument that ABI compatibility should be postponed again.
The planned Rust-like ownership model sounds like it will give us an escape hatch for ARC problems: manual memory management, but only when you need it, and with lots of compiler support to prevent mistakes.
See also: Lattner’s Slashdot interview, Daniel Jalkut.
Previously: Chris Lattner Is Leaving Apple, Swift Plans, “It’s a Coup”, Objective-C Drops vtable Optimization, Copland 2010 Revisited, Regarding Objective-C & Copland 2010.
Update (2017-01-23): ATP now has a full transcript of the interview (tweet).
Update (2017-01-26): See also: Analog(ue).
16 Comments RSS · Twitter
@Jean-Daniel Yes, although consider that they finished addding blocks, a much more difficult feature, to both GCC and Clang in 2009.
"the rate of progress with Swift is incredible compared with what we saw with Objective-C"
This is not a valid comparison. When it acquired Objective-C with NeXT, Apple Computer, Inc. was almost dead. Of course, Apple, Inc. is going to enjoy much more progress with Swift now. I think Apple has more registered developers now than it had total customers then.
Lattner reiterated the goal of Swift eventually being a systems programming language. He even went as far as suggesting an opt-in annotation driven manual memory ownership system which sounds something like what Rust is doing. I suspect the desire for performance and the possibility for systems level stuff is probably why dynamic dispatch of methods is opt-in rather than the default. I prefer late binding languages, but if he really is gunning for a slice of the C/C++ market, then I guess i can see where they're coming from.
@Fred Yep, I definitely see where they’re coming from, and the “Swift world domination” plan actually seems plausible in his telling, but it entails some compromises.
@michael I think it remains to be seen if Swift displacing C/C++ is a attainable goal. Even the mention of making Swift bigger than Java is very ambitious. I would be thrilled if dropping down to Swift was as low level as I ever had to go, but if Swift remains primarily a took for making macOS and iOS applications, I will very much regret it being static dispatch by default.
@Fred That’s the big question because, even putting displacement aside, it’s not been shown that a single language can do all of these things well. If not, they may have prematurely optimized for the wrong case. I think dynamic by default could have totally worked. In cases where you want everything to be static, there could have been compiler support for making sure that nothing was accidentally dynamic.
I confess I was much more intrigued by Swift as scripting. The problems there are the very different needs. You want something like Script Editor rather than playgrounds and have better/clearer ties to the system and to Apple Events.
@Michael So far this plan for "world domination" seems as promising as the ones from Pinky and the Brain. We're in 2017 and, apparently, they are not in a hurry to complete the stuff that would enable the SDK teams to use Swift.
@someone They want to focus first on compilation speed, reliability and scalability, and second on ABI stability. They might get to the ABI stability, but they are realistic about the unreliable nature of goals and deadlines in software development... It seems like the right priority: swift first needs to scale better for larger projects, and most SDKs at Apple fall in that category.
@charles The problem is that Swift could turn into a fad if the platform SDKs are not updated to support it natively (syntax and patterns) in the short to mid term.
@someone OK, but that's a different question. Interestingly, a big focus of swift 3 was in fact to really improve the syntax to access to platform SDKs. The SDK teams can already expose a lot of the ObjC and C stuff to swift in a swift-y way. They don't need to use swift themselves in the implementation. I agree the patterns used in the SDKs don't all quite fit swift, but that's going to take a much longer time, and will mean dropping support for ObjC, which is still a long way.
Also, swift is way past the fad stage IMO ;-)
[…] Chris Lattner ATP Interview, ABI Stability Deferred Until After Swift […]
[…] Chris Lattner ATP Interview, Swift 4 String Manifesto, ABI Stability Deferred Until After Swift 3.0, Looking Back on Swift 3 […]
[…] Chris Lattner ATP Interview, Swift […]
[…] Chris Lattner ATP Interview […]
"It could have been added to Objective-C 1.x but instead came about 6 years after Objective-C 2.0. Or, to put a positive spin on this, the rate of progress with Swift is incredible compared with what we saw with Objective-C."
On thing that may explain the slow evolution of Obj-C is the compiler Apple used. With GCC, it was very difficult for Apple to add custom features as each feature made there branch diverge a little more from GCC trunk and integration of new GCC feature more complex. Moreover, the GCC code was a mess. It uses a different lever and parser for each language variation (C, C++, Obj-C, Obj-C++), which means each time Apple would add a new feature, it had to do it at least on 2 frontends.
Then, there was the transition to clang. Rewriting a compiler from scratch is a very tedious task, and take a lot of time. During that period, the Obj-C language stopped its evolution. We had to wait that clang be mature enough to support adding new syntax and features.