> This created havoc in Python. Hopefully it won't happen here.
There are big differences though:
* Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1)
* Python had a fair amount of semantic-incompatibility
* Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures
> It won't happen because Apple won't give you the option.
What won't happen, havoc in the ecosystem? How is Apple relevant?
> Swift 3.x has a large amount of syntax changes.
Yes?
> The compiler helps with the refactoring but it's still work.
That's not what I'm talking about. A bit of drudge work is fine, the issue of the Python transition is that you get usually hard to debug runtime failures down the line, possibly for a long, long time. With Swift, I assume the compiler just keeps complaining until you've converted everything more or less properly, you may have a few nits but you don't keep finding new breakages.
What won't happen is that Apple won't let people build against old versions of Swift. We'll all be on 3.x soon.
I have no idea how hard the conversion of a large Python 2 to 3 project is. My projects were small and I had no troubles. At any rate 2020 will be here soon and 2.x support will end. All Swift users will be on 6.x by then.
As per the blog [0], you can expect a lot to break.
Swift 3 is a source-breaking release, largely due to the
changes in SE-0005 and SE-0006. These changes not only impact
the names of the Standard Library APIs, but also completely
change how Objective-C APIs (particularly from Cocoa) import
into Swift. Many of the changes are largely mechanical, but
they can be numerous in a typical Swift project.
To help with moving to Swift 3, Xcode 8.0 contains a code
migrator that can automatically handle many of the need source
changes. There is also a migration guide available to guide you
through many of the changes — especially through the ones that
are less mechanical and require more direct scrutiny.
Until now Swift has not promised source compatibility so the developers should be ready to rewrite their code for new versions. I would not be surprised if Swift 2.3 support were dropped in the next version of XCode completely.
The migration tools are quite good though so going from 2.2 to 3.0 directly should not be much of a problem.
I think that in Python the problem was/is that the 2.x was already a massively used and mature language when the 3 came out.
External librairies can also support the migration by providing "fix-its" which helps the compiler display an helpful message whenever a Swift 2-era line has not been updated to Swift 3 (see for example this PR: https://github.com/groue/GRDB.swift/pull/114)
The conversion tools failed pretty badly in my case. I had to do a ton of manual fixes. There are also still a lot of libraries out there that haven't updated yet so unfortunately I'm holding off on updating for now.
For us it worked quite fine for macOS but not for iOS targets. It also changed the function names for a lot @IBAction functions but did not update the connection in the interface builder. So now I have to a lot of testing to make sure all buttons work.
Still I have to admit it shows quite courage (get it?) to change so many things but naming is important and I see it positively. Only if Apple would use version numbers for Swift that would fit to the state, if you have that kind of fast update cycle and that many breaking changes a version number below 1.0 would have been better for Swift 1 and 2.
It has also created havoc in the Swift world. Suddenly all existing Swift code is broken. The migration tool is supposed to take care of most of this for you but my experience has been that it misses a lot of things and upgrading requires many manual fixes. Of course every Swift library in existence also needs to be updated so your changes of a smooth migration right now are slim.
Apple has the resources to push this through and developers don't really have much choice so I don't expect this to become another Python 3 fiasco but this really should be the last time Apple breaks so much code just to clean up the syntax a bit.
It makes a lot of sense, though. Like many new languages Swift was invented hastily and without much care with the main goal of locking in developers and preventing cross-platform development. If Apple made major releases backwards-compatible, this would invariably turn the language into a big mess in the long run.
This way, the language can evolve into a fine language with many features from Algol-68 and the usual semi-popular C-ish syntax, and Apple can continue to ensure that developers have to maintain a separate codebase for their "apps" that is useless anywhere else.
Swift was started in July 2010 by Chris Lattner[1] and it was publicly announced by Apple in June 2014 (and the 1.0 release was September 2014). Spending 4 years on it and including other programming language experts to contribute to it doesn't seem like a reckless and thoughtless release. What it shows is that even if a group spends years on it, they will still get a lot of things wrong. Same for C# that was (formally) started in January 1999 and not publicly released until December 2002. Even though that language also had 4 years of gestation by smart people, they still got generics and a bunch of other things wrong (e.g. terrible name of "destructors" for the concept of finalizers.)
I didn't realize that programmers thought Swift was created in a hurry like Brendan Eich's "10 days" to design Livescript/Javascript for Netscape Navigator[2]
I like Swift but it really was released too early. There were fundamental problems with the tooling for a long long time after the first release and there has been a lot of churn in the syntax even after the tooling started to settle down.
Designing a language like Swift is hard and it's not reasonable to expect them to get everything right on the first try but I do think it would have benefitted from a lot more dogfooding before they started pushing it on developers.
>There were fundamental problems with the tooling for a long long time after the first release
I was speaking of the language syntax and specification separately from the "tooling." Virtually every language has terrible tooling when it's first released. (e.g. Golang doesn't have a real debugger, Rust build chain on Windows is suboptimal, etc). Yes, Apple's Xcode and Playgrounds were extremely buggy with Swift. Given decades of computing history, it's unfortunate that bugs are to be expected of new programming languages.
There are very few languages that emphasize tooling from the very start. Examples that come to mind would be 4GL type languages (SAP ABAP, Powerbuilder) because those proprietary languages often force you to work inside of their GUI editors. Smalltalk might be another example.
This is short-changing the Swift team on a lot of axes, but you're also wrong about the lack of eventual compatibility:
> For Swift 4, the primary goals are to deliver on the promise
> of source stability from 3.0 on, and to provide ABI stability
> for the standard library.
One of the features of Swift is being cross platform. A good 20% of the page that this post links to is talking about their cross platform progress for linux and windows. https://swift.org/about/#swiftorg-and-open-source
There are big differences though:
* Python had 15 years of source-compatibility before the switch, Swift has 1 year and a history of source-incompatibility (Swift 2 was not source-compatible with Swift 1)
* Python had a fair amount of semantic-incompatibility
* Python doesn't have a (heavy) compiler backing it up making source and semantic incompatibilities runtime issues your program bashes its face in rather than cascading compilation failures