Abrahams on the Design of Swift
Dave Abrahams, former lead of the Swift standard library and SwiftUI contributor:
My Rebase 2021 talk, “a retrospective on the design of Swift,” is up at [YouTube]
This is a very interesting talk containing some very strange example Objective-C code. He states several times that he doesn’t use classes, only value types. This may be a good goal, but for app development it seems completely unrealistic for a variety of practical and performance reasons. One is left wondering how well he understood the needs of the developers who would be using the Swift language and library, though he says others on the Swift team had experience writing apps. Overall, I think the standard library is deservedly seen as a success story. I remain deeply skeptical of SwiftUI.
I do wholeheartedly agree with Abrahams that the design of the current Swift documentation does many programmers a disservice by omitting important details about conditional conformances and where methods are defined. It seems to follow the Alan Dye school of design. Making things look simple by hiding things doesn’t actually make them simple.
Previously:
- Swift Community Podcast
- Chris Lattner ATP Interview
- Swift Protocols
- “It’s a Coup”
- The Case for Message Passing in Swift
Update (2021-12-13): Greg Parker:
“Objective-C without the C” was a good keynote line but it’s a bad description of Swift.
We designed a language that was closer to Objective-C without the C. It wasn’t good enough to make up for the costs. Adoption of a new language had to be “go big or go home”.
[…]
The introduction of Objective-C garbage collection and ARC had improved the raw C-ness of the API, but there was still a long way to go. (There was also some false optimism from the old Java Bridge: the OS was just too big now for its techniques to scale easily.)
The GC work had also taught us that getting cooperation from unenthusiastic framework owners was difficult. Swift’s appeal as a language with fundamentally new capabilities helped get engineers and managers on board with the necessary grunt work.
Performance was also likely to become a problem. NSArrays and naïve ARC weren’t going to be good enough. Swift paid the engineer-hours to get new collection and refcounting implementations and new compiler support to optimize and bridge them.
Helge Heß notes that NeXT had already done a basic “Objective-C without the C” called WebScript (PDF).
Update (2021-12-16): See also: Hacker News.
13 Comments RSS · Twitter
What's your take on building a new MacOS application today?
I think AppKit is the most stable, mature, and feature rich option, but it feels like fighting against where Apple is going. The flip side is SwiftUI in my experience hasn't been great. I'm not sure where to jump these days.
@Fred I would do it in AppKit with an eye towards eventually rewriting it piecemeal in SwiftUI if Apple ever delivers on that. Using SwiftUI in its current state seems quite risky, both because of the quality of the end result and the unexpected problems you’ll run into, with limited compensating benefits if you already know AppKit.
@Michael That's sort of been where I'm ending up these days as well but it seems like a crazy notion :D
I’m primarily a .NET WinForms, WPF, Blazor and others developer, and it was fun to toy around with SwiftUI the other day. It’s been about a decade and a half that I’ve done much with AppKit, so I can’t comment on that part too much.
Lots of thoughts, and I’ll mostly spare you. I thought the tutorial website was quite nice. You don’t even really have to open Xcode to get a feel for what building a simple SwiftUI app is like.
I really like some of the paradigms here; for example, the way you can preview your UI with multiple different sets of data simply by creating multiple previews in the PreviewProvider struct feels a lot nicer than XAML-like UI frameworks do it.
I think the syntax is a little eh. I do think HTML and SGML- or XML-like languages hit a sweeter spot in representing a document hierarchy. OTOH, what using a Swift-based DSL(?) gains you is strong IDE support, and a flexible language. In something like WPF/XAML, you’ll often find yourself wishing the XAML editor had much stronger support for refactoring, etc., and you’ll find yourself needing to go back to C# to accomplish basic stuff. Here, you have it all in one file. (Which, personally, I’m not sure if that’s better. Forcing yourself to think of the view and the view’s data source as separate seemed like a feature. Now we’re going back to the RAD days?) I have no idea what the heck some View means.
As nice as the preview stuff is, the little toolbar above it is inscrutable if you don’t already know what the buttons do. I’m also baffled that Xcode apparently won’t let you hover over a variable to see its inferred type? I can apparently open an inspector tab to get that instead, but that seems like a weird omission.
All in all, some nice concepts in here, but it feels very much like a 1.0, even though it’s in its third year. From what I can tell from others, it’s best used (so far) for components in apps, especially if you want some code sharing between your iOS and Mac (and maybe Watch!) apps, but not quite yet for entire apps.
@Sören I'm very leery of frameworks (React is a good example) that mix presentation, data, and control flow into the same file. Always feels like going back in time, and not in a good way.
@Sören Xcode doesn’t show types on hover, but it does with, er, modifier-click (sorry, I’m in my phone here and rely on muscle memory to get the modifier right. Opt?)
@ Fred: yeah. To be fair, the tutorial does emphasize not mixing data. So, this isn't quite as bad as the old "just add a Form_Load event handler and set your controls in there" (what Microsoft used to call the "code-behind"… oof).
But it does feel like a shift away from the stricter MVC (MVP, MVVM, …) trifecta. Which isn't just an Apple thing; as you say, React is another example of that.
@ Juri: ah yes, option-click does open a popover. I do like how holding option and hovering over random places in the code shows you how the scope is interpreted.
Also, I enjoy that Swift's API docs (triple-slash comments) are 1) a non-monospace font and 2) allow Markdown. Nicer than what .NET does (but, to be fair, it has a legacy of two decades; Swift gets to give things a more modern flavor).
@Sören A lot of this Xcode stuff is nice in concept but doesn’t work very well in practice. Often, the popover will be empty and Command-clicking to view the definition of a symbol will show an empty file with an infinite progress spinner. Coloring will half break, so it’s no longer clear what type of symbol you’re looking at. The diamond buttons to run individual unit tests will get linked to different tests in a different file, so it looks like your test is passing but it’s actually running something else. That’s not specific to SwiftUI, though.
> I would do it in AppKit with an eye towards eventually rewriting it piecemeal in SwiftUI if Apple ever delivers on that.
On ATP Marco Arment theorized that SwiftUI will never be good on the Mac, given that SwiftUI is better suited to simple interfaces and that Mac software quality isn’t a priority for Apple.
https://overcast.fm/+R7DUcPeDY/1:43:38
How likely does that seem to you? I don’t know SwiftUI; do you think it could evolve to be suited to more complex interfaces? I don’t see Apple ever dogfooding SwiftUI on multiple complex Mac apps.
Personally I’m also worried about performance on Intel machines, which isn’t great even with AppKit. Also, the lack of backward compatibility, I don’t see Apple ever supporting unsupported macOS versions.
Alas, there is no more up-to-date AppKit documentation online — incredibly (or not) there are no links on how to get started with AppKit on developer.apple.com — so it’s unlikely that using AppKit in a team with people under 35 years old will be feasible by 2030.
@Alexandre Yes, I do think it’s a possibility that SwiftUI never gets good on Mac. First, there may be fundamental performance issues when dealing with large numbers of elements. And second, as you say, they may not care enough to get the Mac details right. For example, Shortcuts has lots focus bugs, controls look funny, and the framework still doesn’t have the concept of a keyboard loop. (It’s also surprisingly crashy, despite Swift being a safer language.)
>I don’t see Apple ever dogfooding SwiftUI on multiple complex Mac apps.
They arguably did do just that with the Shortcuts app, though. (Not multiple and perhaps not "complex", and also, the results are reportedly not great so far. But, it is dogfooding, so…)
@Alexandre: "Personally I’m also worried about performance on Intel machines, which isn’t great even with AppKit. "
What isn't great with AppKit on the performance side on Intel machines?
