Follow Slashdot stories on Twitter


Forgot your password?
Programming Apple

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.
This discussion has been archived. No new comments can be posted.

Apple Announces New Programming Language Called Swift

Comments Filter:
  • by ugen ( 93902 ) on Monday June 02, 2014 @08:10PM (#47151023)

    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.

  • by garote ( 682822 ) on Monday June 02, 2014 @08:14PM (#47151039) Homepage

    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.

  • by shutdown -p now ( 807394 ) on Monday June 02, 2014 @08:16PM (#47151057) Journal

    "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.

  • by angel'o'sphere ( 80593 ) on Monday June 02, 2014 @08:21PM (#47151093) Journal

    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)

    by msobkow ( 48369 ) on Monday June 02, 2014 @08:24PM (#47151105) Homepage Journal

    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.

  • by bradrum ( 1639141 ) on Monday June 02, 2014 @08:27PM (#47151129)

    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, "

  • by elwinc ( 663074 ) on Monday June 02, 2014 @08:29PM (#47151149)

    Many sites are reporting [] Swift as having "none of the baggage of C."

    However, they also report [] 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!

  • by mbkennel ( 97636 ) on Monday June 02, 2014 @08:31PM (#47151157)

    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.
  • by ugen ( 93902 ) on Monday June 02, 2014 @08:59PM (#47151349)

    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)

    by phantomfive ( 622387 ) on Monday June 02, 2014 @11:14PM (#47152125) Journal
    Bjarne Stroustrup once gave some ideas on what requirement should be met before he would consider designing a new programming language. This was his list:

    * 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)

    by WankersRevenge ( 452399 ) on Tuesday June 03, 2014 @12:27AM (#47152377)
    It solves a problem ... not your problem, but Apple's problem. I think Apple created Swift to be a common language throughout all their frameworks. I believe Python was originally filling this role, but Apple doesn't control Python. I believe they intend to use this in the server as well, that way, you have one language used throughout the entire stack - app, server, and even in the debugger.

The party adjourned to a hot tub, yes. Fully clothed, I might add. -- IBM employee, testifying in California State Supreme Court