Whither Swift?
lapcatsoftware.com
lapcatsoftware.com
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.
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...
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.
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.
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.
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."
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.
This is a reddit-style comment, not HN.
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."
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.
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).
Of course Apple could theoretically ditch Swift or Objective-C or replace both something else. But there is zero indication of any such intention.
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.
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!)
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?
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.
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.
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.
It seems like urllib3 uses Python's socket library stuff though? I guess that part of the code isn't the trickiest part.
How come?!?
That is exactly what C++/CLI for .NET, and C++/CX for UWP applications are for.
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.
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.
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?
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.
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.
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!
Java, Groovy, Scala, Closure
Will they exist "indefinitely"? Well, all language have a lifetime, but these will/have coexisted for decades.
It's almost as if people have more tools than they know what to do with!
You can't take one company's culture and apply it to a radically different one.
Not by suddenly stopping support for their previously sole language, so it's a moot point.
At worse, they deprecate some APIs.
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.
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.
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...
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.
I feel like it's possible you have not known very many people on actual meth.
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.
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...
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 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.
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...
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.
I don't think it's as big of a problem as the author seem to think it is.
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.
Sort of like Elixir compared to Erlang.
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.
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.
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.
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.
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.
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...
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?
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.
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.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...
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).
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.
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.
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.
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".
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 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.
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.
(And yes, I know ObjC got generics recently, but it's not remotely the same as what Swift has.)
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
In any case, I was talking about the difficulty of making changes to a compiler, not how programmers react to it.
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.
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.
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...
Swift is memory safe -- I'm not sure how one could evolve Objective-C into that, without breaking compatibility with the C subset.
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 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.
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.
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.
If not, Swift will be doomed to be an Apple-specific language.
https://www.theregister.co.uk/2016/02/23/ibm_releases_kitura...