Home - Archive - Snipposé - Rename Finder Items

How Will Swift Change Cocoa?

There's been debate recently over whether the strictness of Swift needs to be lessened a little to accommodate some capabilities of Objective-C that Cocoa leveraged.

Cocoa and Objective-C build on their Smalltalk heritage and are designed around message passing, message-able nil, and the general dynamic nature of the language. This is not a value judgement; it's just the way it is. The spirit of the framework is influenced by the language and runtime it's built from.

The debate has become mired down in how the things Cocoa does can be adapted to Swift. Every point is quickly swatted down with, "The ObjC runtime is still there, we can still use it, so no worries." Or, "Look, here's a clever set of generic types, operators, and some cool functions that do more or less the same thing but don't rely on massive switch statements!" Or, "All we need is reflection and some find-by-name functions and we can do everything message passing could do." And, "For all the tedious boilerplate, just generate it with the IDE or tooling."

See? You're all just being luddites; type safety and strictness is where it's at, now, and get with the program old man/old woman.

But cool your jets for minute. I don't think that's the important debate here.

It's absolutely true that the alternatives being proposed can or do work. Some are even simple, elegant solutions. Many of the folks publicly "hand wringing" about Swift have extensive experience with static languages. Myself, I've worked in Java and C# since they were new and cool. I've built web apps, web services, and GUI apps in various static frameworks like swing, JSP, ASP.NET, ASP.NET MVC, even WPF.

Type safety and strict compilers aren't new and frightening things. Swift is our language on the Apple platform; it's time to embrace it and look forward, not back.

But it's worth thinking about what happens to Cocoa as it become a Swift framework and no longer an ObjC framework.

As I said before, Cocoa is what it is largely because of the language and runtime. The framework was shaped in good ways and bad ways by the shape of the language (and that runs both ways).

What's going to change is that the framework will now be shaped by Swift. It will do things in ways that fit Swift. Swift doesn't do message passing, so that will not be something the framework relies on. Swift loves generics and intricately specified ontologies of types and functions. The framework will build from that and you will write application code that extends that vocabulary. You will spend more time reasoning about and writing code that adapts the strict types of your application to the strict types the framework needs and the strict types your external dependencies require. You will need to learn and build patterns that can project types around and apply functions to them meaningfully by deeply understanding their structure. And you will become bound to those structures more and more over time. The more clever and descriptive you get, the more intense that bind will be.

My experience working with type strict frameworks is that they are fussy. It's like if the only way you could chop things when cooking is with an array of specialty chopping tools that have to be assembled from pieces every time you needed them. And you have one for garlic, another for potatoes, and so on.

Every time you start to cook, you'll feel the weight of taking those tools out, assembling the pieces, then taking them back apart, washing them, and putting them away. What you'll find over time is that the recipies themselves will adapt to require fewer chopping tools and will become more plain and more similar over time.

So will the framework change the app. You'll begin to avoid the things the framework makes tedious. Complex type definitions and deep abstractions will become a burden to future change.

Maybe it's all confirmation bias, but I feel like you can tell when an app is written in Java or C#, whether it's a web app, web service, or GUI app. They feel different and not in a good way.

To me, that's the existential worry here.

We've paid a large price to get type safety and a language less scary to people new to it. We're tossing out a Smalltalk heritage for a C++ heritage. Give us all a moment to mourn the loss and adapt.

But also, let's learn a little from existing frameworks built around Java, C#, and C++ not ruin Cocoa along the way.