Hypothetical Objective-C 3.0
Many had expected Swift to be more an Objective-C 3.0 than it turned out to be. But what could we have expected such a hypothetical language to look like?
This list is actually just a sample to get the ideas flowing, and to illustrate how some of the hurdles with ObjC 2.0 can be overcome by a successor that breaks syntax with the past, but still retains full backward compatibility.
I think the biggest disservice we can do to the Cocoa developer community is remove the underpinnings of the ObjC runtime. It is the language’s, and I truly believe, the platforms’ greatest strength.
I believe if we hide the complexities of C from our source code and focus on letting the power of the ObjC runtime shine through in our code, we can create a new language that provides of the great flexibility of the ObjC runtime while still accomplishing many of the goals that Swift is attempting to solve - namely safer code by default.
Consider how much progress could have been made with Objective-C had the resources from the Swift project been applied to it instead. Swift is an immensely complicated language that still needs a long time to mature. Objective-C is a much smaller language with a solid core and seemingly a lot of low-hanging fruit (syntax improvements, increased safety).
For example, a better blocks syntax and support for Python-style comprehensions in Objective-C would do a lot for me today, making my code more concise and readable. Swift’s generics feature was likely more difficult to implement, and it arguably makes the code less readable and for dubious benefits.
Additionally, an improved Objective-C could in many cases compile down to binaries that work smoothly with existing code and older OS versions. It could still use the same runtime. With Swift, Apple is instead dropping some of the benefits of the Objective-C runtime and creating migration issues because some Swift elements don’t interoperate with Objective-C, and others bridge but with performance penalties. We’ve only seen the tip of the interoperability iceberg because so far all of Apple’s APIs are native Objective-C.
Apple seems to be betting that the benefits for making a whole new language will be worth the migration costs and the stagnation of the language that most of us are actually using. I’m not convinced because most of my favorite Swift features seem like they could have fit into an Objective-C 3.0.
4 Comments RSS · Twitter
Most people dreaming of Obj-C 3 forgot that Obj-C MUST have a syntax compatible with C and C++.
As the C++ syntax grows (lambda, rvalue, …) the possibilities to extends Obj-C language without breaking the compatibility decrease.
I think Apple did the right thing by going to Swift instead of a potential Obj-C 3 language, which would have been completely incompatible with actual Obj-C code anyway and fix just a couple of Obj-C gotcha , instead of providing a whole new set of possibility and adopt modern language pattern.
@Jean-Daniel I don’t think it’s a given that Objective-C 3.0 would have to be syntax compatible with C—or especially C++. There would still be the 2.x language for that, just like there is now that they’ve introduced Swift. Maybe the 3.0 name implies the wrong thing. Think instead of the “Objective” language idea that was floated some years ago, i.e. really Objective-C without the C.
While I'm pretty meh on generics, I think many ObjC fans are missing what is clearly one of the aims of Swift. Not just a replacement for ObjC but also a replacement for C++/C. That is I think the aim is on doing system software in it as well as apps. As such the performance gains of a lot of the strong typing is important.
I'm sympathetic to many of the complaints about Swift, but a fair number of them seem to be along the lines of "Swift lets you do C++ like stuff when you don't subclass NSObject." I just don't understand this purist view. Why does generic Swift have to do all this stuff? While it's not perfect, most (but not all) of the complaints can be handled with the proper class hierarchy.
Some of the complaints I'm pretty sympathetic to. (AppleScript and Swift are a frustrating combo) But it's still under development. If it's still limited this time next year *then* I'll start worrying. Right now though I'm rather happy with its potential. In any case though, ObjC 3.0 is never coming. It's right up there with the fabled xMac. Adjust your expectations accordingly.
@Clark Well, I would say that us app folk see that Swift is more designed for system software than apps. We’re finding out that it’s primarily a C++ replacement that also has some Objective-C compatibility, which is not really how Apple sold it or what we would have wanted.
Those of us who like NSObject are worried that code we interact with will improperly choose the other class hierarchy, thus closing off possible fixes and features. And it’s not limited to the hierarchy, since Apple has made the NSObject stuff more static in Swift by default.
Most people aren’t arguing against Swift’s potential. The problem is that there was a huge opportunity cost to get it where it is now, and yet it’s clearly not there yet.
