Slashdot Mirror
Apple Releases Swift 3.0, 'Not Source-Compatibile With Swift 2.3' (infoworld.com)
An anonymous Slashdot reader quotes InfoWorld:
"Move fast and break things," the saying goes. Apple does both with the 3.0 version of its Swift programming language...its first full point revision since it became an open source project... In a blog post detailing the full body of changes for Swift 3.0, Apple singled out the two biggest breaking changes. The first is better translation of Objective-C APIs into Swift, meaning that code imported from Objective-C and translated into Swift will be more readable and Swift-like. The bad news is any code previously imported from Objective-C into Swift will not work in Swift 3; it will need to be re-imported.
The other major change... Most every item referenced in the standard library has been renamed to be less wordy. But again, this brings bad news for anyone with an existing Swift codebase: Apple says "the proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code."
Apple will provide migration tools in version 8.0 of their XCode IDE, "but such tools go only so far," notes the article, questioning what will happen to the Linux and Windows ports of Swift.
The other major change... Most every item referenced in the standard library has been renamed to be less wordy. But again, this brings bad news for anyone with an existing Swift codebase: Apple says "the proposed changes are massively source-breaking for Swift code, and will require a migrator to translate Swift 2 code into Swift 3 code."
Apple will provide migration tools in version 8.0 of their XCode IDE, "but such tools go only so far," notes the article, questioning what will happen to the Linux and Windows ports of Swift.
than later when there's a huge code base.
Some drink at the fountain of knowledge. Others just gargle.
I have a pretty decent amount of Swift and the change between this version and previous versions is a lot more to absorb than it has been in the past... the migrator tool does help though it seems like it doesn't do as much as it could (that may have changed from earlier betas though).
However, whatever brief pain this brings upon us, is more than made up by the improvements Swift3 brings to the Cocoa API...
Have you ever worked on an Api for a long time, and thought "if I could do this again I'd rename all this stuff, and structure this one thing differently..."
Well that's one thing Swift3 did for Cocoa - there's basically a whole new name mapping overlay for Cocoa that makes lots and lots of calls much clearer, and also extensions that offer more Swift friendly API calls in some cases.
And the nice thing is some of the mappings are algorithmic, so your own ObjectiveC code you call from Swift benefits from name tidying or simplification, which works out well because of naming conventions Cocoa has long had and almost all Cocoa programmers follow.
There are also specially tweaked mappings to some parts where special cases made the automatic mapping not make sense, so it's like the whole API has had an overview and some re-thought applied.
It is sad that Swift3 could not yet bring ABI stabilization (so you could ship binaries of libraries to other developers and have them work in future Swift updates). But hey, the upside there is that people that want to ship Swift libraries have to give you source - who doesn't want that!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The courage to move on, to do something new that betters all of us.
The Swift 2.0 language is more than 12 months old. It has its last big innovation about 6 months ago. You know what that was? They deprecated prefix and postfix operations, they made it smaller. It hasn't been touched since then. It's a dinosaur. It's time to move on.
where we have 5 versions, 3 syntax distinctions, and flipping through them like a rolodex while muttering "what in the name of god does this code need to run" is a time honoured tradition.
Good people go to bed earlier.
And thank goodness they do that.
Otherwise we'd be on OS 9x on PowerPC.
It's turtles all the way down.
Nobody gets raises for being a cunt. Come up with a plan to fix this in a cost-effective manner, and maybe next time they'll pay attention.
lucm, indeed.
The language just turned two years old, and they've been saying for a while that the language wouldn't be 'stable' until version 3.0.
Nothing is perfect on day one, after all, and Swift borrowed a lot of terribly ugly library methods from Obj-C to make the transition easier. Cleaning all that up for 3.0 will cause some short-term headaches but make future code a lot less cumbersome.
Hopefully from here on the changes will be relatively minor.
How can I believe you when you tell me what I don't want to hear?
Lol I have seen many projects waste so much time because of swift's BS incompatible updates to do critical things like making the ++ operator a compile error.
Nobody gets raises for being a cunt.
Then how do the higher ups get their jobs?
Wanna buy a shirt?
https://www.redbubble.com/people/stealthfinger/shop?asc=u
Nothing is perfect on day one, after all
I was.
-- Make America hate again!
And it all went downhill from there
Since Swift is open source, it's already been ported to many platforms. It's on Linux (which Apple officially supported) and Windows and even Android now...
So is DOSBox. Doesn't mean much. The reason it hasn't been forked is because there simply isn't enough interest in it from people with the technical ability to fork it.
If you are ignoring Swift because of your irrational hatred of Apple, you are only hurting yourself and your future employability.
I dunno hey - I soundly ignored iOS, Obj-C and all Apple development and it hasn't done anything to my employability at all. I expect similar by soundly ignoring Swift.
But I do thank you for making it even easier for me to find work.
Personally I'm not in competition with you - I do (and have done) s/ware development on more than a single manufacturers products. I'm flexible. The amount of non-Apple development work out there dwarfs the Apple-only development work. Hell, the Apple-only work being offered is so tiny I doubt it even makes a margin-of-error difference? Maybe four orders of magnitude difference? Less?
I'm a minority race. Save your vitriol for white people.
Yes. It's not like people weren't warned about this. The Swift 3 announcement at WWDC back in June made this very very explicit indeed, as indeed did swift.org from even earlier.
It's not you: I'm just this horrifically socially awkward with everybody.
I have no doubt that you could still get a job writing in COBOL if you wanted to.
I ignore COBOL for the same reason I ignored iOS-dev: there is no lack of opportunity without them. Lacking iOS (or COBOL) doesn't change my employability enough for me to even notice.
I'm a minority race. Save your vitriol for white people.
... my Stevens unix systems programming book (which applies t to OS/X too) from the mid 90s is still mostly relevant today.
Ah yes because
DoSomething(i);
i = i + 1;
is so much better.
ProTip: This is sarcasm.
Using whitespace to express indentation is completely retarded in any case. Editors should be smart enough to display code using whatever indentation style you prefer, and should save files with minimal whitespace inserted. Thus people get to look at their code however they prefer, and no-one ever has to worry about merging whitespace-only changes, because there would be no such thing. Quite how we've got this far, without anyone ever bothering to do this, is quite beyond me.
Everybody whining here clearly hasn't written any Swift code and is only interested in bashing Apple. Maybe you should be asking what actual people using Swift think of this.
Well, I'll tell you as one.
- The Swift syntax changes are annoying to spend time on, but minor.
- Apple's migration tool is helpful and makes fixing go fast.
- It was no surprise or secret that the syntax was going to change. They said all this upfront and we all knew this was coming.
- Swift on Linux and other platforms only started working less than a year ago. There is not as much code to transition.
Nobody gets raises for being a cunt.
Then how do the higher ups get their jobs?
They ingratiate themselves to the cunts by being dildos.
Using tabs enables the viewer to view the code indentation with as much spacing as they see fit. That means on my X character wide ultra high res terminal, i can ensure that there is a noticable level of identation. People who don't get that tabs can be redefined to make formatting more legible for the person reading your code are assholes.
Or you could say that in projects with a lot of people, it pays to force an indentation standard based on a universal number of spaces, a constant retained from revision to revision. Then when you, the generic you, do a diff in any tool, it will look exactly the same regardless of a user's editor setup.
I'm sure there are people who will disagree and will put valid counter-arguments. I can only say that after doing this for a while and having to deal with disparate formatting of the same file in the same bloody branch (making diffs almost impossible to discern without some serious massage), then a standard spacing becomes a lifesaver.
See, programmers are very talented, but also extremely opinionated. Sorry, most cannot do shit without having someone forcing some rules upon them. The amount of ego is just staggering, and almost everyone, when left to her devices reformats and shuffle shit on a file to fit her own needs without ever thinking "gee, I wonder if the next person who has to maintain this piece of code will be able to effectively discern logical/structural changes from formatting ones without involving file-massaging heroics.".
Yes, there's plenty of choices of languages for which there is lots of employment opportunities. So it comes down to what you enjoy doing.
For me, I've done C & C++ and I certainly don't miss having seperate header files to maintain and include.
Java? Who wants all that verbosity, and endlessly nesting braces.
Swift is a breath of fresh air. It's rather like a statically typed Python, without the strange idioms and indent based blocks. And everything designed with the objective of limiting the likelyhood of creating bugs.
It makes programming a pleasure again.
What TFS doesn't do a good job of explaining is that with Swift 3, Apple has essentially forked the project into two parts. Besides the newer version 3, Apple is also continuing to develop/support Swift 2.x. The already-released Swift 2.3 is Swift 3's counterpart for developers who would like to stick with Swift 2.x code.
I don't imagine Apple will support Swift 2.x forever. But for the time being, Swift 3 is only as source-breaking as you want it to be. Developers who need Swift 2 compatibility can roll on with 2.3.
var a = 3
let b = a++ * 3
Now, I expect this type of code is the justification Apple is using to remove the operator; although there is no ambiguity, the line which sets b also sets a.
I argue that prefix and postfix ++ and -- should have remained in Swift. Not only are they well defined, but they are a standard operator in almost all new languages and therefore convey their meaning to the application developer significantly better than += 1 or -= 1 ever could.
For example, when reading code, ++i requires significantly less reading and parsing by the developer than i += 1 to convey the same idea.
That's just one example, the entire tech press has lost its shit over the jack being gone. Yes it takes a lot of courage to do something that the press hates En Masse (which they knew would happen) and in turn may drive away some customers - which brings us back around to Slashdot where a number of people said they wouldn't consider a device without a headphone jack.
Making a change you think is better in he long run that may cost you customers today does take courage, you will never admit that but you know it is true which is why you are so fiercely denying it.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm working on a small mixed Objective-C/Swift project. The API was provided, and is in Objective-C so no changes there. The UI code (i.e. all view controllers) are all in Swift, and consist of about ~30 classes. Moving from Swift 2.3 to 3 was quite easy with the migration tool, and took me about two hours.
8 of 13 people found this answer helpful. Did you?