Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Apple Announces New Programming Language Called Swift

Unknown Lamer posted about 6 months ago | from the everyone's-got-one dept.

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

Sorry! There are no comments related to the filter you selected.

and it needs an new OS the mess up other apps (-1, Troll)

Joe_Dragon (2206452) | about 6 months ago | (#47151001)

and it needs an new OS the mess up other apps and makes people not want to get the new OS.

Re:and it needs an new OS the mess up other apps (5, Funny)

Anonymous Coward | about 6 months ago | (#47151085)

and the comment grammar no sense slashdot article read.

captcha: verbally. Seriously?

Re:and it needs an new OS the mess up other apps (1)

DeathElk (883654) | about 6 months ago | (#47151131)

It took you 3 minutes to type THAT badly?

Re:and it needs an new OS the mess up other apps (4, Funny)

Anonymous Coward | about 6 months ago | (#47151181)

*that poorly.

Re:and it needs an new OS the mess up other apps (0)

Anonymous Coward | about 6 months ago | (#47151359)

Score: -1, FUD

It uses objective-c's runtime, Apple's implementation is compatible with iOS 7 and 8, and OS X Mavericks and Yosemite. I'm sure plenty of 3rd party implementations will appear too, much like they have done for obj-c.

First Rhyme (4, Funny)

Art3x (973401) | about 6 months ago | (#47151017)

AAPL's YAPL

Good bye source compatibility (4, Interesting)

ugen (93902) | about 6 months ago | (#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.

Re:Good bye source compatibility (0)

nobdoor (1496229) | about 6 months ago | (#47151075)

My team has already stopped supporting Mavericks because it apparently does not support GDB. Creating GUI's in OSX is currently problematic because of font issues. With Chrome/Android OS's becoming more popular, I wonder whether this kind of move could a boon for Linux.

Re:Good bye source compatibility (4, Informative)

Anonymous Coward | about 6 months ago | (#47151241)

What possible application could ever require GDB as a dependency?

LLDB is a far superior debugger anyways.

Re:Good bye source compatibility (5, Funny)

Anonymous Coward | about 6 months ago | (#47151365)

Creating GUI's in OSX is currently problematic because of font issues.

Obviously this must be the case as no-one else is creating GUIs in OS X either. That, and the fact that OS X is hated the world over by designers for it's awful handling of fonts.

Re:Good bye source compatibility (4, Funny)

Anonymous Coward | about 6 months ago | (#47151493)

Could you tell me who your team is? I have a tumblr for really shitty software and I'd love to feature them!

Re:Good bye source compatibility (5, Insightful)

angel'o'sphere (80593) | about 6 months ago | (#47151083)

Since when does Qt not work X-platform anymore?

Re:Good bye source compatibility (4, Interesting)

ugen (93902) | about 6 months ago | (#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).

Re:Good bye source compatibility (3, Insightful)

Frosty Piss (770223) | about 6 months ago | (#47151505)

Qt does not (and cannot) support Windows "Metro"

"Windows Metro" is dead, irrelevant to this discussion. QT will continue to be available for Apple's little garden. Your comment constitues "fear mongering".

Re:Good bye source compatibility (0, Flamebait)

Anonymous Coward | about 6 months ago | (#47151509)

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.

If we applied that standard to everything, we'd be stuck with Qt's obsolete and cumbersome programming model and UI in perpetuity. I, for one, am happy to jettison it once and for all.

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.

And people should care about this... why? Writing a UI in C/C++ is itself a questionable proposition. And if you really want a C++ toolkit, you can still provide it even if the UI tools are implemented in a completely different language and runtime (just have a look at HTML+JavaScript).

Since when does Qt "work" with OS X? (-1, Troll)

TrollstonButterbeans (2914995) | about 6 months ago | (#47151383)

No this is NOT a troll, please read.

A claim of cross-platform is one thing. But in practice I know of no significant apps using Qt that exist in the wild that work on OS X.

Please provide a link to any mainstream working application for Mac OS X that uses Qt. I don't know of a single one because Qt's support for XCode is incredibly poor.

(And if I wrong, I will free accept it and eat my post, but I have yet to see one and I have actively looked. Qt's support for OS X is pretty, really bad but admitted I haven't tried it the last 18 months to see if anything changed).

Re: Since when does Qt "work" with OS X? (0)

Anonymous Coward | about 6 months ago | (#47151457)

Maya , modo .. Google these apps

Re:Since when does Qt "work" with OS X? (4, Informative)

Guy Harris (3803) | about 6 months ago | (#47151483)

No this is NOT a troll, please read.

A claim of cross-platform is one thing. But in practice I know of no significant apps using Qt that exist in the wild that work on OS X.

Please provide a link to any mainstream working application for Mac OS X that uses Qt.

$ otool -L /Applications/Google\ Earth.app//Contents//MacOS//Google\ Earth
/Applications/Google Earth.app//Contents//MacOS//Google Earth:
@rpath/libgoogleearth_free.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 155.0.0)
@rpath/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.4)
@rpath/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.4)
@rpath/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.7.0, current version 4.7.4)
@rpath/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.4)

...

I don't know of a single one because Qt's support for XCode is incredibly poor.

Do you have to use Xcode, the IDE, to develop OS X apps? Or by "Xcode" do you mean "Xcode the IDE, plus the command-line tools"?

Good bye source compatibility (1)

Anonymous Coward | about 6 months ago | (#47151151)

It's supplementing the existing Obj-C and C API's, not replacing them.

I would imagine already existing code will continue to function just fine.

Re:Good bye source compatibility (1)

danomatika (1977210) | about 6 months ago | (#47151167)

A C/C++ backend and platform-specific front ends aren't an option?

Re:Good bye source compatibility (0)

angel'o'sphere (80593) | about 6 months ago | (#47151197)

A good UI is much more complex than the backend.
Assuming backpend and frontend would require the same work (which is not the case, usually it is more an 1/3 to 2/3 relation) then rewriting the frontend for 3 platforms means it costs like writing it two times for one.
A crossplatform GUI framework is much much cheaper. Hence the success of Java (regardless weather you use Swing or SWT)

Re:Good bye source compatibility (4, Insightful)

Lunix Nutcase (1092239) | about 6 months ago | (#47151179)

Why is this dumb post modded insightful? You can still use all the same languages you did before.

Re:Good bye source compatibility (-1, Troll)

mark-t (151149) | about 6 months ago | (#47151263)

.... For now.

Re:Good bye source compatibility (0)

Anonymous Coward | about 6 months ago | (#47151345)

The future:
ASM => C => C++ => VB.net => rust

Re:Good bye source compatibility (1)

roc97007 (608802) | about 6 months ago | (#47151425)

Obviously you should pick Windows.

.....

....

*snerk* Sorry, I just couldn't say that with a straight face.

Re:Good bye source compatibility (4, Insightful)

ddtstudio (61065) | about 6 months ago | (#47151429)

Hey, I'm not a developer/coder/programmer, so I honor and respect the work you've put in to things in the past. But if you've been tying yourself to a "unified GUI look" across platforms, you've long been dooming your products and yourself.

As a UX person, I can throw data at you all day long that shows device/OS specificity and familiarity are key elements in making something work for the user. I'm sure you don't literally mean you chose either a menu bar in all app windows on every platform or a top-of-the-screen menu bar on every platform, but the obvious reason why that would be wrong also holds for controls, colors, placement, text sizes, and so on to the last turtle at the bottom.

Re:Good bye source compatibility (1)

nine-times (778537) | about 6 months ago | (#47151475)

It doesn't sound like they're dropping support for existing languages. Couldn't you keep using whatever you're using?

Re:Good bye source compatibility (0)

jbolden (176878) | about 6 months ago | (#47151485)

Apple has always been hostile to unified look on their platform. They want their applications written by developers in the Apple culture. That being said, nothing has actually changed. They are just releasing a new language.

Whoa 1.3x (4, Funny)

the eric conspiracy (20178) | about 6 months ago | (#47151033)

That's what about 1/10,000th of what hiring a good programmer would get you, at the price of not being to find any programmers.

Re:Whoa 1.3x (0)

Anonymous Coward | about 6 months ago | (#47151101)

that's the whole point, it's much faster to write the code while actually gaining some runtime performance

Whoa 1.3x (0)

Anonymous Coward | about 6 months ago | (#47151189)

You know how high level language advocates like to claim that being high level means it can actually be optimized better than a low level language since the compiler knows what you're doing? And you know how it's never actually true? It finally happened.

Re:Whoa 1.3x (1)

Anonymous Coward | about 6 months ago | (#47151449)

10,000x speedup in run time performance from a good programmer? I wanna know where you've been hiring these 'bad programmers' so I can avoid them.

New bells and whistles (2, Interesting)

garote (682822) | about 6 months ago | (#47151039)

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.

Re:New bells and whistles (3, Interesting)

angel'o'sphere (80593) | about 6 months ago | (#47151093)

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.

Re:New bells and whistles (1, Informative)

Anonymous Coward | about 6 months ago | (#47151119)

Closures are already in Objective-C, the call them blocks, they have be really usefully, in dealing with multithreading they have been especially usefully.

Re:New bells and whistles (2)

mark-t (151149) | about 6 months ago | (#47151199)

If closures are making your code harder to understand then you have tried to use them where other techniques would be more appropriate. In the right contexts, closures should greatly enhance readability, not reduce it.

Re:New bells and whistles (0)

Anonymous Coward | about 6 months ago | (#47151391)

Closures have been present in Obj-C for many years, under the name "blocks".

Re:New bells and whistles (0)

Anonymous Coward | about 6 months ago | (#47151397)

15% added flexibility for about -40% readability

You're definitely an idiot.

Re:New bells and whistles (1)

jbolden (176878) | about 6 months ago | (#47151499)

It depends who is using them. People who come from functional language cultures use them all the time and they increase readability tremendously. Essentially you start breaking with imperative concepts, most of the time you don't need to understand order of evaluation / execution.

Have you ever tried LISP or Haskell or languages where closures are an absolutely standard part of programming, the way say for loops are in the Algol family?

It's about time (1)

Anonymous Coward | about 6 months ago | (#47151047)

Just the other day I was wondering when we'd have another programming language.

Re:It's about time (5, Funny)

Anonymous Coward | about 6 months ago | (#47151069)

I can't wait to add this to my résumé.... I already have 2 years of experience with Swift!

Re:It's about time (3, Funny)

Anonymous Coward | about 6 months ago | (#47151469)

Oooh, sorry. We're only looking for candidates with at least 5 years of experience with Swift.

Who designed this, and what drugs were they on? (4, Interesting)

shutdown -p now (807394) | about 6 months ago | (#47151057)

"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:Who designed this, and what drugs were they on? (3, Interesting)

mbkennel (97636) | about 6 months ago | (#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.

Re:Who designed this, and what drugs were they on? (3, Informative)

shutdown -p now (807394) | about 6 months ago | (#47151203)

And which things have the 'potential to modify' the length of an array? Implementation defined?

It's defined by the operations on the array. Basically, appending, inserting or removing an element would do that, but subscript-assigning to an element or a range will not.

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.

Funnily enough, they do actually have in/out/inout parameters in the language.

Note however that the story for arrays here does not apply only to parameters. It's also the behavior if you alias the array by e.g. assigning it to a different variable. So it's not fully covered by parameter passing qualifiers.

Re:Who designed this, and what drugs were they on? (0)

Anonymous Coward | about 6 months ago | (#47151223)

Relevant: http://developers.slashdot.org... [slashdot.org]

Who designed this, and what drugs were they on? (0)

Anonymous Coward | about 6 months ago | (#47151329)

Strange, because immutable arrays are possible and (asymptocically) efficient. Standard ML, the predecesor of OCaml and F#, has it it http://webcache.googleusercontent.com/search?q=cache:7nopWhLOQjwJ:www.standardml.org/Basis/vector.html+&cd=1&hl=en&ct=clnk&gl=nl&client=safari (Google cache as they seem to be moving servers).

Re:Who designed this, and what drugs were they on? (0)

Anonymous Coward | about 6 months ago | (#47151477)

That's irrelevant to real-world programming. Even a factor of 2 overhead over mutable arrays is totally unacceptable in numerical computing.

Who designed this, and what drugs were they on? (1, Funny)

phantomfive (622387) | about 6 months ago | (#47151401)

My favorite part of immutability is 'let.'
If you write:

let i = 5;
You have just declared 'i' to be immutable. Intuitive, isn't it?

Re:Who designed this, and what drugs were they on? (0)

Anonymous Coward | about 6 months ago | (#47151517)

My favorite syntactic sugar has to be how they manage to take Obj-C's method calls and make them uglier -- e.g., let's say you're hard-code passing the numbers 1, 2, 3 to a method with 3 arguments:

object.method(1, argumentName2: 2, argumentName3: 3)

You wrap the call in parens, put the variable names inside the parens -- except for the first variable, because leaving its name out is completely intuitive and not a bizarre remnant of Obj-C -- and yet they kept function simple as in C.
 
Just behind that is having types come after the rest of variable/constant/function/method declarations. It's one of those things that I suspect comes from the scripting world, where distinguishing the type of code to follow is important so script-kids can keep their files hideously disorganized.

Re:Who designed this, and what drugs were they on? (2)

The Snowman (116231) | about 6 months ago | (#47151435)

I don't agree with the decisions either. However, it is consistent with Java. Like it or don't like it, Java is popular and its semantics are well-known.

Re:Who designed this, and what drugs were they on? (0)

Anonymous Coward | about 6 months ago | (#47151511)

Swift, a language that is naturally designed to let you shoot your foot in the most elegant way possible, courtesy of Apple.

My favourite part was the bit near the end of the developer documentation where they describe how to arbitrarily define your own custom operators, giving an example of how you can define a postfix triple-plus +++ operator to double the length of a Vector2D through a reference.

Yeah.

Yet another C variant? (2, Insightful)

mikein08 (1722754) | about 6 months ago | (#47151059)

Just what we need! Better compilers is what we really need, but that apparently is too difficult.

Re:Yet another C variant? (1)

Anonymous Coward | about 6 months ago | (#47151111)

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

Just what we don't need, an easier way to write buggy code.

Re:Yet another C variant? (2)

camperdave (969942) | about 6 months ago | (#47151299)

Just what we don't need, an easier way to write buggy code.

Exactly! Who, besides the Amish, need buugy code? What we need is self driving automobile code.

Re:Yet another C variant? (3, Informative)

Shag (3737) | about 6 months ago | (#47151113)

They've already got LLVM and Clang, no? Or did you mean better than those?

Swift Programmers Wanted (4, Funny)

the eric conspiracy (20178) | about 6 months ago | (#47151081)

Must have 5 years experience.

Re:Swift Programmers Wanted (1)

AnontheDestroyer (3500983) | about 6 months ago | (#47151117)

And XML, how many years do you have with that?

Swift Programmers Wanted (0)

Anonymous Coward | about 6 months ago | (#47151141)

10 years professional development experience preferable.

Re:Swift Programmers Wanted (3, Funny)

HornWumpus (783565) | about 6 months ago | (#47151211)

Good news; I've got over 20 years experience. (bullshitting my way into positions with languages I don't know. Then learning fast.)

Guaranteed results...'I can guarantee anything you want.' Bender

Re:Swift Programmers Wanted (2)

bunratty (545641) | about 6 months ago | (#47151433)

Good news, everyone!

I remember seeing job listings for Java... (0)

Anonymous Coward | about 6 months ago | (#47151305)

...5 years experience, and you pretty much would have had to have written the language to have that much...

Re:Swift Programmers Wanted (0)

Anonymous Coward | about 6 months ago | (#47151319)

too bad,
Time to catch up!!

POLUS 4, tROLL) (-1)

Anonymous Coward | about 6 months ago | (#47151095)

that should be to foster a gay and new faces and many God, le7'5 fucking nearly two years

Re:POLUS 4, tROLL) (0)

Anonymous Coward | about 6 months ago | (#47151163)

Yeah, I agree. What he said.

SWIFT programmers (4, Interesting)

msobkow (48369) | about 6 months ago | (#47151105)

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.

You think that is the problem? (4, Informative)

Ecuador (740021) | about 6 months ago | (#47151195)

I mean, there is already a swift programming language [swift-lang.org] . Yes, it is not popular, but when you decide on a name for your language don't you at least google it first? Is "swift" so unbelievably cool that a name collision (even with a "small" entity) does not matter? But, yeah, it is Apple we are talking about, they probably invented the word "swift" which people and companies like SUZUKI have been copying for other uses here and there...

Re:You think that is the problem? (2)

msobkow (48369) | about 6 months ago | (#47151341)

I just look forward to the organization behind the SWIFT protocols suing Apple into the ground for trying to appropriate a name that already has a well-established meaning in computing. They've certainly got the budget to do it... :)

Re:You think that is the problem? (0)

Anonymous Coward | about 6 months ago | (#47151355)

Swift is small, but look at the backers.

iPhone announcement (2)

TrollstonButterbeans (2914995) | about 6 months ago | (#47151403)

When Steve Jobs announced the iPhone, Cisco owned the trademark to iPhone as I recall. And he didn't care.

Apple has enough $$$ to payoff for virtually any name they set their mind to, just like what they did with the iPhone.

http://www.idownloadblog.com/2012/01/27/apple-cisco-iphone-trademark/

Designed for safety & performance (3, Interesting)

bradrum (1639141) | about 6 months ago | (#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, "

Designed for safety & performance (2, Informative)

Anonymous Coward | about 6 months ago | (#47151411)

There's not really a trade-off. It's just newer. Variable types can be inferred statically using unification (which is fast and actually more expressive than manually typed languages). Standard ML has done it for many years.

Same with forcibly initialized values. Means you don't need to check pointers ever. Basically the same as references in C++.

Bounds checking is rarely needed. Again, I point to Standard ML; here, instead pattern matching and higher order functions are used. This is basically what Swift does with closures and the map operation. If you look at the fold operations of all Standard ML types (that's basically the inspiration for the map-reduce paradigm), it is obvious that no bounds-checking is necessary, and iterating over an entire structure is almost always what you do with a data-structure (aside from initialization), and the only operation where you access the structure many times and would have an overhead for bounds-checking.

Memory seems to be managed using ref-counting, which is similar to auto_ptr in C++. Barely any overhead (a zero-check on deallocation, which can even be biased towards branch-predicting that no deallocation needs to take place).

None of the baggage of C? (1, Interesting)

elwinc (663074) | about 6 months ago | (#47151149)

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:None of the baggage of C? (3, Informative)

Anonymous Coward | about 6 months ago | (#47151207)

Yes, Swift itself does not have the baggage of C just like Python does not have the baggage of C. The fact that both languages can interoperate with C does not change that.

Re:None of the baggage of C? (2)

Lunix Nutcase (1092239) | about 6 months ago | (#47151219)

The statement is talking about if you only write pure Swift. What you describe is really no different than using C code with Java through JNI. But that does not mean Java itself has any C baggage.

Re:None of the baggage of C? (2)

maccodemonkey (1438585) | about 6 months ago | (#47151309)

From what I can tell (I just got out of WWDC and am reading through the docs) it can be bridged to, but not directly called. You can directly call Obj-C methods through the bridge, but not C methods. You'd have to bridge to the Obj-C methods which then call C methods.

I don't know what happens when that Obj-C method calls malloc and returns some memory for leak-tastic behavior. I still haven't read if or how Swift handles raw memory buffers.

Re:None of the baggage of C? (2)

linearz69 (3473163) | about 6 months ago | (#47151377)

"instead, the compiler infers the variable type, just as many scripting languages do."

Its safe to say that the baggage will be inferred as well.

Dice job postings... (1)

jddeluxe (965655) | about 6 months ago | (#47151259)

...with "5 years experience Swift programming" coming from the recruiters in 3, 2, 1...

Somebody post a SWIFT example PLEASE! (2)

Proudrooster (580120) | about 6 months ago | (#47151261)

I wanted to write apps and tried to learn Objective-C, but as a coder that started with C and then moved on to C++ and PERL (the swiss army chainsaw), the language syntax hurt my ability to read it. In case you don't know what I am talking about, here are some of my learning notes

        myObject.someMethod(); // old school
        [myObject someMethod]; // send a message or call a method

        result = myObject.someMethod(); // old school
        result = [myObject someMethod]; // method returns a result

        result = myObject.someMethod(arg); // old school
        result = [myObject someMethod:arg]; // pass an argument

You can see the Old School syntax above (which works in Objective-C) and the Objective-C standard syntax below. The square brackets [ ] and colons : just hurt my mental debugger... [ ] and yes I know Objective-C is a Superset of C, so they had to steer clear of the C-Syntax but it just looks wrong. Further, I know that I could write my own style of Objective-C but I wouldn't be able to read the code of others. Apple had to start somewhere and Steve had the NeXT languages ready to go but to me the syntax is ugly and offensive. However, I am ready for a better Apple language.

I can't wait to see a SWIFT code example, if it gets rid of the NeXT Objective-C Superset Syntax, I might be coding for iPad and Mac sooner than I thought. If anyone has a code example, please share it, I would like to see what a function, method, or message call looks like. Hoping for parenthesis and a Standford iTunesU class. Guardedly excited!

Re:Somebody post a SWIFT example PLEASE! (4, Informative)

Proudrooster (580120) | about 6 months ago | (#47151323)

Ok, you guys are too slow, I RTFA and downloaded the iBook. So far, I am very much liking the SYNTAX, especially OBJECTS and FUNCTIONS, they even brought the LET keyword in from BASIC. SWIFT will make programming Apple products much easier for the C loving syntax crowd, from what I can see. Ahhh... what a breath of fresh air. Code snippet below of creating an object and exercising it. I feel bad for those that suffered through Objective-C.


“class Square: NamedShape {
        var sideLength: Double

        init(sideLength: Double, name: String) {
                self.sideLength = sideLength
                super.init(name: name)
                numberOfSides = 4
        }

        func area() -> Double {
                return sideLength * sideLength
        }

        override func simpleDescription() -> String {
                return "A square with sides of length \(sideLength)."
        }
}
let test = Square(sideLength: 5.2, name: "my test square")
test.area()
test.simpleDescription()”

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks. https://itun.es/us/jEUH0.l [itun.es]

Swift (0)

Anonymous Coward | about 6 months ago | (#47151277)

Just kids re-inventing the wheel again.

Just what we need, another C++ clone (2)

funky_vibes (664942) | about 6 months ago | (#47151289)

I'm sure everyone was thinking, we don't have enough languages that are basically a badly implemented subset of C++. We need to make another one.
Let's see if Android will respond by creating an even less compatible C++ clone than Java.

Re:Just what we need, another C++ clone (0)

Anonymous Coward | about 6 months ago | (#47151419)

Thankfully, having had a read through the book, this one seems to be a well implemented subset of C++, with ADTs, and a more consistent type system, so it's basically what C++ should have been in the first place.

Re:Just what we need, another C++ clone (5, Funny)

mark-t (151149) | about 6 months ago | (#47151447)

... a badly implemented subset of C++

You mean like C++?

Re:Just what we need, another C++ clone (1)

funky_vibes (664942) | about 6 months ago | (#47151497)

I think you like recursive solutions.

What took them so long? (1)

istartedi (132515) | about 6 months ago | (#47151297)

Apple is the king of vertical integration and proprietary standards. The only thing that surprises me is that it took them this long. MS beat them with C# by how many years? Google has two of these things (Go and Dart) AFAIK.

Now I just need to finish my universal cross-compiler that never quite takes advantage of all the features in these languages because it's too damn difficult and they are moving targets.

That's it. We need a language called "Target" that's constantly moving.

Re:What took them so long? (2)

Proudrooster (580120) | about 6 months ago | (#47151375)

Really, it is not the fault of MS, Google, or Apple but of academia. In the CS curriculum they still teach the "compiler" class and as long as you keep teaching kids how to write compilers, they will keep writing languages. SWIFT is definitely a variation on a C theme, but much better than the Objective-C (superset of C) syntax, at least at first glance.

Using SWIFT in a contract with the US Navy... (0)

rla3rd (596810) | about 6 months ago | (#47151315)

Do you get Swift Boating? http://en.wikipedia.org/wiki/S... [wikipedia.org]

Colour me skeptical... (3, Insightful)

ChunderDownunder (709234) | about 6 months ago | (#47151343)

Apple had a fine language 20 years ago. It was said to influence the design of Ruby and Python. They butchered it into an Algol-like syntax because 'real programmers' can't grok s-expressions. Then they abandoned Dylan.

Next, they created a language for mobile devices. Its programming model was said influence the design of JavaScript. Then they abandoned NewtonScript.

Re:Colour me skeptical... (0)

Anonymous Coward | about 6 months ago | (#47151443)

Well story with Dylan was Matt sued Apple because of the name.

Lets see if Taylor will do the same.

Will it be the first time slashdot links to tmz.com?

Re:Colour me skeptical... (0)

Anonymous Coward | about 6 months ago | (#47151461)

Oops I meant Bob. Sorry, Matt.

Story with Dylan was Bob sued Apple because of the name.

Lets see if Taylor will do the same this time.

Will it be the first time slashdot links to tmz.com?

Exceptions (1)

phantomfive (622387) | about 6 months ago | (#47151405)

The language doesn't have exceptions.
It has strong emphasis on assertions though, so feel free to use those as a substitute.

Swift (2)

phantomfive (622387) | about 6 months ago | (#47151413)

I knew that Swift was trouble when it walked in, trouble trouble trouble

Swift another scripting lanugage (-1, Flamebait)

Trax3001BBS (2368736) | about 6 months ago | (#47151437)

Aren't they all scripting languages anymore

looks decent (1)

stenvar (2789879) | about 6 months ago | (#47151445)

Apple definitely needed to do something because Objective-C was really getting long in the tooth. As far as new languages go, at first glance, this looks nicer than what the other players have to offer (Java, C#, Go).

However, proprietary languages don't tend to fare particularly well. If this gets an open source implementation and isn't patent encumbered, however, it might also be a good thing for Linux.

Re:looks decent (1)

Proudrooster (580120) | about 6 months ago | (#47151489)

Agreed, It looks decent and both readable and writable. Hope it catches on.

Write once (0)

Anonymous Coward | about 6 months ago | (#47151471)

For Apple, then once for everybody else! Too much time on my hands! Said Tommy Shaw!

the inevitable... (1)

roc97007 (608802) | about 6 months ago | (#47151515)

"I can code faster than ever!" Tom said swiftly.

Too soon?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?