Apple Announces New Programming Language Called Swift 636
jmcbain (1233044) writes "At WWDC 2014 today, Apple announced Swift, a new programming language. According to a report by Ars Technica: 'Swift seems to get rid of Objective C's reliance on defined pointers; instead, the compiler infers the variable type, just as many scripting languages do. ... The new language will rely on the automatic reference counting that Apple introduced to replace its garbage-collected version of Objective C. It will also be able to leverage the compiler technologies developed in LLVM for current development, such as autovectorization. ... Apple showed off a couple of cases where implementing the same algorithm in Swift provided a speedup of about 1.3X compared to the same code implemented in Objective C.'"
Language basics, and a few worthwhile comments on LtU.
Good bye source compatibility (Score:4, Interesting)
Good bye source compatibility. We hardly knew ye.
First Windows, and now OSX. I am still maintaining applications that are built crossplatform (Windows/Mac/Linux, with unified GUI look) but it's getting harder every year and, by the looks of it, will be impossible soon.
Which means that an individual developer (like myself) or a smaller shop would have to choose one big player/OS vendor and stick with it. That increases risk and makes small players that much less viable (while, of course, helping the big ones consolidate user base and profit).
Funny how the world works.
New bells and whistles (Score:3, Interesting)
I was particularly surprised to see closures appear. So far I've only been using them in Javascript and Perl, but my experience has been that they are about 15% added flexibility for about -40% readability. That is, they make it harder to tell what's going on, more than they reduce development time.
Who designed this, and what drugs were they on? (Score:5, Interesting)
"Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed."
i.e. Swift arrays that are "immutable" actually aren't. Way to rewrite the dictionary. But wait, it gets worse. Here's for some schizophrenia.
"Structures and Enumerations Are Value Types. A value type is a type that is copied when it is assigned to a variable or constant, or when it is passed to a function. Swift’s Array and Dictionary types are implemented as structures."
So far so good. I always liked collections that don't pretend to be any more than an aggregate of values, and copy semantics is a good thing in that context (so long as you still provide a way to share a single instance). But wait, it's all lies:
"If you assign an Array instance to a constant or variable, or pass an Array instance as an argument to a function or method call, the contents of the array are not copied at the point that the assignment or call takes place. Instead, both arrays share the same sequence of element values. When you modify an element value through one array, the result is observable through the other. For arrays, copying only takes place when you perform an action that has the potential to modify the length of the array. This includes appending, inserting, or removing items, or using a ranged subscript to replace a range of items in the array"
Swift, a language that is naturally designed to let you shoot your foot in the most elegant way possible, courtesy of Apple.
Re:New bells and whistles (Score:4, Interesting)
Depends on the language.
In groovy closures are perfectly readable, as they are in Smalltalk.
Problem is that closures are often considered second class citizens, hence they get plugged in later nad then they look wiered.
SWIFT programmers (Score:5, Interesting)
They could have chosen a name other than that of the international banking protocols. Asking for SWIFT programmers is going to get them a bevy of COBOL coders who know the protocol.
Designed for safety & performance (Score:3, Interesting)
I find these two aspects interesting and wonder what the trade off is. Longer compiler times?
"Designed for Safety
Swift eliminates entire classes of unsafe code. Variables are always initialized before use, arrays and integers are checked for overflow, and memory is managed automatically. Syntax is tuned to make it easy to define your intent — for example, simple three-character keywords define a variable (var) or constant (let)."
" Swift code is transformed into optimized native code, "
None of the baggage of C? (Score:2, Interesting)
Many sites are reporting [google.com] Swift as having "none of the baggage of C."
However, they also report [arstechnica.com] that "Swift code can still be mixed with standard C and Objective C code in the same project."
Seems to me that if you can call C routines, C can happily malloc() and free() the heap and leave stale pointers into freed heap. Likewise, C can happily point into the stack and leave pointers into stale stack frames, and point past the end of arrays, etc.. I don't think they can get rid of the "baggage of C" withoud building all kinds of performance killiing safety checks into the C code. If I'm wrong about this, please don't hesitate to let me know!
Re:Who designed this, and what drugs were they on? (Score:4, Interesting)
That is bizarre. So if you see a function signature which takes an array as a parameter, you either do know that elements will be changed, or will not be changed---but only depending on potentially hidden implementation of that function?
And which things have the 'potential to modify' the length of an array? Implementation defined?
Fortran 90+ had it right. You just say for each argument whether the intent is data to go 'in' (can't change it), 'out' (set by implementation), or 'inout', values go in, and may be modified.
Re:Good bye source compatibility (Score:5, Interesting)
Qt does not (and cannot) support Windows "Metro" (or whatever the name is for the C#/event driven/non Win32 environment now)
By the same token it won't be able to support this new environment.
Qt, XWidgets and others like them rely on basic C compatibility and certain common UI themes and primitives to be able to build cross-platform libraries and applications. With proprietary, non-portable and non-overlapping languages vendors make sure that any development has to target their platform specifically.
Aside from that, if new development environment does not support linking against "old" binary libraries - developers also don't get the benefit of code reuse (since they won't be able to use existing libraries for things like image handling, graphics, sound, networking, you name it).
Bjarne Stroustrup (Score:5, Interesting)
* What problem would the new language solve?
* Who would it solve problems for?
* What dramatically new could be provided (compared to every existing language)?
* Could the new language be effectively deployed (n a world with many well-supported languages)?
* Would designing a new language simply be a pleasant distraction from the hard work of helping people build better real-world tools and systems?
Apple can definitely deploy the new language effectively, but I'm not sure it solves any problems.
Re:Bjarne Stroustrup (Score:3, Interesting)