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.
Yet another C variant? (Score:2, Insightful)
Re:Good bye source compatibility (Score:5, Insightful)
Since when does Qt not work X-platform anymore?
Re:Good bye source compatibility (Score:5, Insightful)
Why is this dumb post modded insightful? You can still use all the same languages you did before.
Colour me skeptical... (Score:4, Insightful)
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:Good bye source compatibility (Score:5, Insightful)
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 (Score:3, Insightful)
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:Since when does Qt "work" with OS X? (Score:4, Insightful)
Then compile your code with Eclipse or from the command line.
What has XCode to do with developing Qt?
Re: Good bye source compatibility (Score:2, Insightful)
If your frontend requires more work than your backend, then your app doesn't do anything useful.
Clearly his team needs it. Don't question why. (Score:3, Insightful)
My god, it's like I'm at Stack Overflow, reading the typical stupid and cocky "WHY ARE YOU DOING IT THAT WAY?!?#?!?@?!@?!?" responses that are so prevalent over there.
His team probably has its reasons for using or requiring GDB. And you know what? They're probably pretty damn legitimate reasons, too.
I'm sure they know about LLDB. But it's probably not what they need, and thus they do not use it.
If they need GDB, then that's what they need. It's that simple.
What we don't need is somebody like you questioning the validity of their very real need.
Re:It's about time (Score:4, Insightful)
Wow, I happen to meet that requirement. I've been using SWIFT [swift-lang.org] for quite a few years and have done image processing and molecular docking workflows in it./p.
No they are not (Score:2, Insightful)
I'm sure they know about LLDB. But it's probably not what they need, and thus they do not use it.
Whatever they NEED gdb for, they would be better off using LLDB at this point.
I was a huge fan of GDB in the past. But that time has gone.
Viva Eco (Score:5, Insightful)
Ok, so now you'll be developing software using Apple's frameworks and Apple's language to run on Apple's runtime, after passing Apple's compiler (i.e. LLVM) for download using Apple's store (after finding your product with Apple's iAD) directly onto Apple's products built with Apple's custom processors, after you register as an Apple Developer. If your app needs to do something outside this environment, you can use said APIs now to reach out to Apple's Could and Apple's Database servers. And if your app is really successful as measured by Apple Crash Reporting and Apple Usage statistics or Apple's iTunes Connect, then they'll just straight out fucking copy you.
Something about the new "language" is what makes that summary start sounding ridiculous.
Re:Somebody post a SWIFT example PLEASE! (Score:4, Insightful)
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.
To be honest, while this snippet is a few lines shorter, it's arguably more complicated than the corresponding Obj-C. It drops returning self in the init, and drops a few lines that would have had to go in to the class definition, but you gain a few unsightly keywords like "override", having to add the keyword "func" to every function, and you gain some more syntactical mess like "->".
It's not horrible, but I'm not sure this sample is more readable than Obj-C. As others have noted, Swift has the habit of taking the important parts of a function (like what it's named and what it returns, or what name a class is and what it subclasses) and shoving them off to entirely different sides of the function declaration.
Re:Good bye source compatibility (Score:4, Insightful)
That's not what cross-platform compatibility implies. Placement of specific elements and their view is a subject of "themes" and is readily customizable.
As a developer I care about underlying primitives - things like "windows", "buttons", "menus" or more generically "events", "inputs" etc. Once those underlying things can no longer be shared - you have to write a new product from scratch for every platform.
Think of something like Adobe Photoshop (I assume as a UX person you are using it?). It is possible to have a version for Windows, and one for Mac precisely because you have those common underlying primitives and APIs, even though they don't necessarily look the same in all respects.
If commonality of platforms is gone - even a company like Adobe will have really hard time building products for both platforms. That will eventually affect users too, since they will likely have to select different (and no longer compatible) products for each platform as well. For now that's not the case - but given where things go, it probably will be.
Re:Since when does Qt "work" with OS X? (Score:5, Insightful)
There are plenty of apps that use QT--probably the most mainstream one is Google Earth.
Now, look at me with a straight face and say, "And Google Earth has a great UI!"
To me, this is the problem with cross-platform UI. It starts from a mistaken premise: Windows and Mac or iOS and Android have the same basic UI. There's even a grain of truth to it. But it doesn't really work.
The example I love to use is French and English. They are, basically, the same language, right? They both have words, sentences, and paragraphs. They both have nouns, verbs, and adjectives. So if you just translate the words and move around the adjectives, you've got a French/English translator! It's that simple!
No, not really. If it's 100 degrees outside and you've just come from the outside and remark to a pretty girl "Je suis chaud" (literally, I am hot), she might very well slap your face. Because you've just said that you are hot as in, "Oh, baby, you make me so hot."
And those are the silly mistakes that cross-platform UIs make.
Take a simple one from Mac versus Windows: On the Mac, in a dialog box, the default button is always the right-most button. So you have a dialog box that says, "Are you sure you want to do this?" and the right-most button would say, "OK" and the button to the left of it would say, "Cancel." On Windows, the default "OK" button would be on the left with the "Cancel" button the right of it.
Alignment, again, is a question. I'm not sure there's a standard on Windows--I've seen things centered [spaanjaars.com] and I've seen them aligned right. [samba.org] On Mac OS X, there's a standard. Which means when Windows aligns them on the right like on the Mac, I'm always pressing the Cancel button.
So, yeah, you can use QT to have a cross platform application and it will work fine. And it's great, if you have an application like Google Earth, which has lots of great GIS capabilities so that the result is worth the pain. But, frankly, if Microsoft did an equivalent to Google Earth but made a Mac application that was "correct," I'd use it in a heartbeat. Because, all else being equal, I'd rather have an application that "speaks my language" to one that only sort of does.
Have you ever spoken to a tech support person from another country with a thick accent? That's the equivalent of using Google Earth on a Mac.
Re:Good bye source compatibility (Score:4, Insightful)
It's a good point.
Consider the menu bar. It's a pretty handy place for commands. On the Mac, it sits at the top of the screen. On Windows, it sits along the top of your window. Now if we consider Fitts' Law [wikipedia.org] for a moment and compare Mac and Windows, the menu bar is much easier to access on the Mac than it is on Windows because it's sitting at the top of the screen.
So, putting things that people access somewhat frequently into a menu item on the menu bar isn't a horrible thing on the Mac. But on Windows--because the menu bar is harder to access--it will frustrate your users. You probably want to set up some kind of contextual menu on Windows.
Do it the Mac way, you've annoyed your Windows users. Do it the Windows way and you confuse your Mac users (who are used to searching the menu bar to find things). Or devote the time and effort to doing it both ways.
Re:Somebody post a SWIFT example PLEASE! (Score:3, Insightful)
I haven't checked, but its a great idea to have override as a mandatory descriptor (If it is). Java now has @Override, but code quality suffers from it not being compulsory, leading later to subtle bugs. As for func and let, I imagine it makes it easier to make a scripting language to have less ambiguity about what you are trying to declare up front. I mean, without func, would the line "area()" be the start of a declaration, or a call to a function? Sure, you could wait for a semi-colon to finalise the decision, but then you've got to have semi-colons.
Re:Whoa 1.3x (Score:2, Insightful)
""10 years experience" - keep in mind time at a university counts for work experience."
On what planet? University time counts for work experience about as much as work experience counts for university time.
If you told me you had 4 years Java experience because you were in school studying CS for 4 years I'd laugh in your fucking face and tell you to get the fuck out.