> It is not source-compatible with Swift 2.2 and 2.3.
This created havoc in Python. Hopefully it won't happen here.
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
Swift 3.x has a large amount of syntax changes. The compiler helps with the refactoring but it's still work.
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.
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.
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.
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.
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.
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.
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]
[1]http://www.nondot.org/sabre/
[2]https://www.quora.com/In-which-10-days-of-May-did-Brendan-Ei...
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.
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.
Yet it would not be what it is today without the public feedback process that contributed to the changes that were made since that release.
> 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