Slashdot Mirror
Apple Releases First Preview of Swift 3.0 (macrumors.com)
DaGoatSpanka quotes a report from MacRumors: Apple yesterday released the first preview build of Swift 3.0, a major update to Apple's open source Swift programming language. Swift 3.0's official release is expected to come in late 2016 after proposed changes are finalized. The Swift 3.0 preview can be downloaded from the official Swift website. There are versions of Swift 3.0 available for Xcode 7.2, Ubuntu 14.04, and Ubuntu 15.10. [Swift 3.0 is not source compatible with Swift 2.2 as it introduces source-breaking changes, but going forward, the goal is to make Swift 3.0 source compatible with future Swift language updates.] Swift 3.0 will likely be shown at Apple's upcoming Worldwide Developers Conference (WWDC).
Last release broke for loops, what was broken now? If statements??
To be fair, the language just hit two years old today. Most languages were still in flux at that age.
How can I believe you when you tell me what I don't want to hear?
Really? So you are saying my PDP11 ML knowledge isn't obsolete? Thanks for the tip. It isn't trolling: it is a warning to avoid languages controlled by a single corporate entity. They can pull things from under you at their whim. Also, what a laugh: Swift 2.2 was released on MARCH 16, 2016!
Apple developers are probably used to the abuse by this point considering that the Mac itself has undergone three architecture changes as they moved from the Motorola 68000 to IBM PowerPC and then to x86. I wouldn't be surprised if in another five years they've completed abandoned x86 and move to using their own ARM SoC designs for all of their products.
They probably should have kept Swift behind closed doors while tinkering with it to make all of these changes. I realize that you need people using the language to discover ways of making it better, but Apple has loads of their own developers that could used started using the language and helping it evolve before releasing it to the public.
Your argument makes no sense.
First of all, there's no such thing as "obsolete" knowledge when it comes to programming languages. This knowledge is very useful if you ever have to maintain code. And the newer knowledge typically builds upon the older knowledge.
Additionally, programming languages developed by open source communities or working groups suffer from exactly the same problem. Yes, when moving to a new version of a programming language we as programmers need to learn new things! It doesn't matter if you're using Swift or Java or C++ or Perl or Ruby or Erlang or Haskell or Lua or JavaScript or whatever other language you want to consider. It doesn't matter who developed the new version of the language. A new version of anything typically implies some learning will be involved!
It sounds to me like you want stagnation. Well, sorry son, but that doesn't fly when it comes to technology. Technology is always advancing. If you can't keep up, then you should drop out and find something else to do.
Actually C++ is a good example: C++ was released in 1985 and has multiple compilers available and that code still compiles in 2016. Swift 2.2 came out 3 MONTHS AGO. There is no advantage to a corporate controlled anything.
Well that sounds an awful lot like what Swift is!
They both target into the same direction, but rust is a far more "safe" language than Swift is.
While Swift has already seen major adoption and use in the real world, we haven't seen that from Rust.
Quite on the contrary: https://www.rust-lang.org/frie...
And that page only contains the corporate users of rust. There is a really big community of free time rust developers as well.
Others have pointed out that C++14 and C++17 actually make much of Rust redundant.
That might be partially right, but C++ has lots and lots of backwards compatibility to very old concepts. C++ relies on the C preprocessor, which is very limited, on doing macros. Thanks to this you don't have scoped macros for example. In rust the macro system is done much later in the process, so that you can declare a macro inside a function, and after the } closing brace the macro scope ends!
There was recent discussion about Google adopting Swift for Android [slashdot.org]. IBM has also taken an interest in Swift [ibm.com].
Using swift for android would make sense as both android and ios are similar platforms, you likely want to write stuff for them in one unified language.
Swift is quickly becoming a universal language.
Swift may have lots of adoption but it is far away from being an universal language. It is limited by its compatibility kludges towards ObjectiveC which makes it particularly interesting for iOS developers who already know ObjectiveC, but outside of this environment it is of low importance.
The large number of developers proficient with Swift could contribute to Mozilla's code bases, rather than just a small handful of niche developers who know Rust.
The number of developers who know swift may be larger than the number of developers who know rust. But how many only are interested in developing their ios app, and that's it?
A modern web browser written in Swift would be much more useful than a web browser written in Rust.
Swift only has reference counting, nothing more. In fact, only thread safe reference counting. This is a major performance problem, while in Rust you have the choice between all memory models C/C++ have.
But that's not saying much...
C++ is 30+ years old. Swift 2.2 is 4 MONTHS old and is obsolete. I hope you see the difference here.
Swift is a good idea of how to do things wrong. But what about C#. It's made my Microsoft, who everybody loves to hate, yet C# and the .Net framework is probably one of the best development environments out there. They have a pretty good record of not breaking too many things with new releases. They also do pretty well adding new features that programmers want. I prefer it much more to other languages that aren't controlled by corporations such as PHP, Python, or C++..
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Too bad if you put time into learning Swift 2.0. That knowledge is now obsolete. And when Swift 4.0 comes out, your Swift 3.0 knowledge will be obsolete. My advice to young programmers: avoid languages owned by corporations. They have time and money to waste. You don't.
LOL I take it that you have never looked at C++, an ISO standardized language. Code written in C++98 and C++14 almost appear to be written in different languages.
And actually one of the advantages of a corporate controlled language is you totally avoid the "Designed by committee approach" to things.
You know, I sorta /broadly/ agree, but c'mon - you're comparing differences across 18 years for C++ to differences across 4 months for Swift. Why not compare C++11 and C++14?
I'm a minority race. Save your vitriol for white people.
Seriously, Apple, where's the love?
Apple stated when Swift 1.0 was released that it was a work in progress and that there would be a flurry of updates coming and that, while they would maintain binary compatibility, they would not be able to maintain source compatibility as they changed and streamlined the language. Anyone using swift is well aware of this.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
I'm not aware of any good programming language that never required any revision. So you are basically holding Apple to a standard that noone else has ever met before...
But hey, if it makes you feel better about your own miserable life to complain on the internet...
I think the reason you are attracting such replies is that you appear to be completely ignoring the changes in computing since C++ came out. The two are clearly not comparable, as C++ was developed during a time where access to the internet was out of reach of most people. Where languages had to be incredibly stable simply because changes to them could not be disseminated to all affected parties very quickly. Where documentation was in printed books instead of digital. Where transpilers were a lot less effective as they are now. This is just scraping the surface - the differences between then and now are like night and day, yet you made absolutely no reference to them. I think if you accepted that what happened to a relatively low-level language back then might not be particularly relevant to a high-level language now (and maybe calmed down a tad) you might be having more of a discussion and less of an argument.
What corporations control Python?
Apple could discontinue Swift tomorrow and you would by out of luck.
Unless someone else takes up maintainership of a fork of Swift under the Apache License.
Is anybody going to bite on a new proprietary language? Have we not learned anything from what Oracle has done with Java?
Like C? Even C has broken backwards compatibility at times. C started out in the 70's, yet we still have C99. Oh wait, that didn't work, we have C11. 40 years later we're still changing it.
C++ was once a superset of C. It is no longer, and some C code can not be compiled in C++ compilers.
Java has methods that are deprecated.
Swift is a pretty new language. It's also a bit of a new paradigm. You start with an idea of what you want in the language, most works, some doesn't, you try again. Some of this breaks backwards compatibility. Better to do this now, then 40 years later.
Perhaps a nicer way to express it might have been "As of right now, this language is too unstable for me to use in production. I'll let others be the guinea pigs until it matures."
Not everyone is a lazy shit. It takes about 5 minutes to update a moderately-sized code base from 2.2 to 3.0 syntax. Xcode provides a built-in tool to do it for you, and you just have to fix up the few cases it doesn't find on its own. It's really trivial for anyone who isn't a spoon-fed piece of dirt.
Today I learned that SJW means 'civility'.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
So, I'm not able to maintain my Swift 2.2 code anymore just because Swift 3.0 or 4.0 is out?
Strange, I had assumed my old Swift 2.2 compiler just runs as usually.
Well Xcode 7 only came with a Swift 2 compiler, so you could not maintain Swift 1 code with that version. I assume that once Swift 3 is officially out that Xcode will pull a similar trick regarding Swift 2.x
However Apple does supply migration tools that the "person" you are replying too is seeming to totally ignore.
I am Slashdot. Are you Slashdot as well?
So this language is so "open" that it's only usable within Xcode? It sounds like a small world propritary deal.
And 5 seconds on google finds Introduction to Open source Swift on Linux
I am Slashdot. Are you Slashdot as well?
Have other languages made the syntax incompatible on each version?
Compatibility was broken between Python 2 and Python 3 to clean up the language. For example, print "Text" in Python 2 got replaced by print("Text") in Python 3.
I write applications (big ones) for OS X using c and c++. Targeting 10.6.8, my code still works fine under 10.11 today. It ports to Windows easily as well. Re Windows, targeting XP, it all works right up to the current version of Windows. XP broke the OS windowing metrics, otherwise my stuff would still work with Win98. :) Apple hasn't done anything quite that stupid. Well, yet. 10.6.8 is where 64-bit code began to work; and it's the last OS X that supports PPC (my HP calculator emulation, bunch of audio drivers, my old mame (which is actually fairly important to me, because some of those games are my code, and code from close friends in the day, and I want that stuff to work as long as possible), all kinds of stuff in Appleworks, etc., etc. So 10.6.8 is where I planted my flag, so to speak.
Of course if you decide Swift or Objective C is your chosen coding mechanism, that's fine, but there's no externally imposed requirement that it must be your coding mechanism; at the worst, a few boilerplate intermediate layers based on basic OS APIs will do ya.
Sometimes -- for instance, with Apple's OS file dialogs -- the stuff Apple supplies is either broken, feature-poor, or both. After being bitten over and over by that stupid file dialog, I spent an afternoon and wrote my own. Which works a damn sight better, and faster, and with less hangups than Apple's does. My users benefit a great deal from my unwillingness to let Apple screw them with the bug-infested trail of tears they leave behind them as they blunder onwards into their new and shinier future.
Same thing for most (all?) of Apple and Microsoft's "new and shiny." For every new thing you decide you depend on in the OS, you're leaving users behind, and making your code more and more dependent upon Apple's latest whim.
Which, again, you can do, absolutely -- but you don't have to.
Almost every time I see some application that "requires" some fairly late version of an operating system, I think dark thoughts. There are few things, particularly things that are focused upon new features, where it is likely reasonable. But mostly... not. Mostly it's just thoughtless development where the user takes a back seat to... let's face it: "shiny."
I've fallen off your lawn, and I can't get up.
Python 3 is not Python specifically because it will not run Python 2 code. Python 3 isn't just a "little" different. It's a lot different. Which is fine. Although they should have called it something other than Python, frankly, because it confuses a lot of people that Python != Python. Justifiably so.
Swift appears to be undergoing the exact same schism. The new Swift is not the old Swift; if it breaks your compliant code, it's a new language. If it breaks some undocumented crap, that's something else entirely. But when you write to spec, and the New/Shiny won't run it -- that's an entirely new language, regardless of what little, or lot, remains syntax compatible. Swift != Swift.
Python's 2-series remains 100% viable; the source code is out there. Dunno about Swift; I code Python all the time, haven't bothered with Swift (nor am I ever likely to.)
My insignificant little message to all language designers is this: Once you make a spec beyond beta, if you break the spec, you're developing an entirely new language, and you should REALLY change the damned name.
I've fallen off your lawn, and I can't get up.
Some minor tweaks added in '89 (from wikipedia): multiple inheritance, abstract classes, static member functions, const member functions, and protected members.
And even later still were added: templates, exceptions, namespaces, new casts, and a boolean type.
C++ underwent way more fundamental changes in its first 10 years than Swift has undergone in its first 2...so maybe we should all just chill out a little bit.
From what I remember of C++98 (the first C++ ANSI standard; I'm not sure where you got '89 from - perhaps you were thinking of C89 - the first ANSI C standard?), the committee used the standard to merely document the most popular behaviours of the most common compilers, hence by design the C++98 broke no existing code.
And, as far as I can tell, the committee repeats this intention for each new standard - you can be almost guaranteed ("I've not heard of it happening") that a new C++ standard will not break existing code written to the previous standard.
Personally, this feature of the C++ standards committee has always annoyed me - they take such great care to ensure they never break existing code that the end result is a language that is some bastardised unholy mess of its previous incarnations and whatever new fad is going around at the moment. Last I looked, there was what.... 3 different language constructs to iterate across a container?
You can accuse C++ of a lot of things (and I frequently do), but saying that each new C++ standard breaks existing code is 100% inaccurate. They take great care not to do so.
I'm a minority race. Save your vitriol for white people.
Right. And it took, what, 15 years for Python to accumulate enough cruft that they decided to do this kind of major breaking milestone?
Here, we're talking about a language that isn't even 2 years old.