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??
None of their products work well. They're all hopelessly out of date. Why would anyone ever use Swift? Java is far superior.
Best day ever!
Join today at www.gnaa.eu.
And thus, Swift will forever remain nothing more than a toy language for worthless apps.
Make no mistake: this isn't Swift version 3 - it is the language Swift 3. I guess Swift 4 will not be (completely) backwards compatible either. Because the idea of a programming language evolving from a stable, thoroughly tested base specification is old - not fit for the Apple(TM) generation...
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.
> Java is far superior
Ugh. Swift must be pretty bad, then.
Now that we're seeing some real progress with making Swift a cross-platform language, I think it's time for Mozilla to drop their Rust project.
For those who don't know, Rust's home page describes it as "a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." Well that sounds an awful lot like what Swift is!
While Swift has already seen major adoption and use in the real world, we haven't seen that from Rust. There have been a handful of projects using Rust, but that's it. And the ones that have used it, including the Rust implementation itself and Mozilla's Servo browser engine, have not been very impressive so far.
Despite lofty goals and a lot of hype, we haven't seen anything much of substance come out of Rust. Many have complained that it's an awkward language to use, even more than C++ is. Others have pointed out that C++14 and C++17 actually make much of Rust redundant. Yet others point out that Rust's safety guarantees are only as good as its implementation, which suffers from thousands of bugs despite much of it being written in Rust by the creators of Rust!
There was recent discussion about Google adopting Swift for Android. IBM has also taken an interest in Swift. Instead of continued failure with Rust, which is essentially a proprietary language at this point even if it's developed in the open, Mozilla should really consider using Swift, too.
It wouldn't just be better for Mozilla. It would be better for all developers. Swift is quickly becoming a universal language. 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.
Swift is the future. It's where software development is heading. Mozilla can do the sensible thing by getting rid of Rust and moving to Swift early on, or they can continue to waste time and effort on Rust. I sure hope they make the sensible decision! A modern web browser written in Swift would be much more useful than a web browser written in Rust.
https://i.imgur.com/dUk9aen.jpg
No such thing as a trustworthy spy.
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.
But that's not saying much...
Because apparently their engineers lack the ability to think far enough ahead to design something that lasts longer than a single coding cycle.
Seriously, Apple, where's the love?
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...
should the world stop using Python?
And PDP11 ML isn't a programming language, dumbass.
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.
C++ relies on the C preprocessor, which is very limited, on doing macros.
C++ has type-safe and/or scoped alternatives to a lot of things that used to need C macros.
Thanks to this you don't have scoped macros for example.
C++ has namespaced templates.
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!
In modern C++, you can likewise declare a lambda inside a function (example). This could replace the C-inspired use of macros as ghetto inline functions.
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?
No, otherwise, the statement would've been that "Swift > C". No, the superiority of Swift is only in comparison to the things that Objective-C adds to the original C language. And pretty much everyone outside of the RDF agrees that Objective-C is a terrible language, while original C is not.
Have other languages made the syntax incompatible on each version? This is just as stupid as if C++17 would replace "{" and "}" chars with "begin" and "end".
They can't do that, it would screw up my 'begin' and 'end' macros.
Julia is far better language than those 3 new commer.....
The set of things classified as a "revision" is obviously a superset of things classified as "breaking change". If you stay out of the "breaking change" category (e.g. only new syntax that did not previously compile) then it isn't a problem.
Yes, there are plenty of language updates which do not break existing code. When they do, many language design teams strive to limit any breaking changes to concepts that are only used by a very small number of people, or bugs which result in undocumented behaviors that very few or no developers rely on.
Then there's the case at hand, which sounds like nearly all existing code will break in some way. It's completely different.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
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.
The other side of that coin is that C++ is absurdly complicated partially due to attempts to keep it backwards compatible.
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.
It started out as "C with classes" in 1979 and by 1985 there was a book called "The C++ Programming Language".
There were lots of code-breaking changes between 1979 and 1985, it just wasn't a widely used language at the time.
There were C++ implementations going all the way back to the early 1980s. Do you really think it was a programming language on paper only for 20 years?