Slashdot Mirror
Apple Announces New Programming Language Called Swift
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.
AAPL's YAPL
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.
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.
"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.
I can't wait to add this to my résumé.... I already have 2 years of experience with Swift!
Must have 5 years experience.
and the comment grammar no sense slashdot article read.
captcha: verbally. Seriously?
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
I do not fail; I succeed at finding out what does not work.
They've already got LLVM and Clang, no? Or did you mean better than those?
Village idiot in some extremely smart villages.
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, "
*that poorly.
I mean, there is already a swift programming language. 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...
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
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.
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
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.
You mean like C++?
File under 'M' for 'Manic ranting'
Oooh, sorry. We're only looking for candidates with at least 5 years of experience with Swift.
There is VLC
There is CMake
There is my project -- https://sourceforge.net/projec...
There is Sorenson Squeeze -- http://www.sorensonmedia.com/s...
I am sure there are others
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.
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"?
Then compile your code with Eclipse or from the command line.
What has XCode to do with developing Qt?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Wow, I happen to meet that requirement. I've been using SWIFT for quite a few years and have done image processing and molecular docking workflows in it./p.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
It doesn't use Metro's libraries.
Anything that doesn't use the Windows Runtime API (what you call "Metro's libraries") will not be approved for the Windows Store and will not run on Windows RT tablets or Windows Phone 8 smartphones.
I was under impression that all new windows "apps" had to be written in C# against a new SDK that has neither binary nor source compatibility with Win32/posix/C/C++. I'd be glad to be wrong, but that's what I've seen so far.
Only Windows Phone 7 and Xbox Live Indie Games required C#.* C++ works on Windows Phone 8 and Windows RT, though they do require use of the Windows Runtime API. For actual Windows on x86, you can continue developing desktop applications without having to deal with Windows Runtime (the "Metro" crap).
* In theory, they required verifiably type-safe CIL compatible with the .NET Compact Framework. In practice, they required C#, as standard C++ is not verifiably type-safe, and DLR languages require functionality not in .NET CF.
Good bye source compatibility. We hardly knew ye.
I have absolutely no compatibility problems. I strictly use objective-c for only user interface code. The core functional application code is written in c/c++. I have multiple iOS/Android apps whose core code is shared and can even be compiled with a console app under Mac OS X or Linux, I use this for regression testing and fuzzing. A headless Linux box in the closet exercises this core code. Similar story for Mac OS X and Windows.
Swift code can replace objective-c code and it matters little to me. Has zero impact on other platforms I target.
Admittedly I've ported other people's code between Windows, Mac and Linux for years and written my own code for Windows, Mac and Linux for years and as a result I am extremely aggressive about separating UI code from functional code.
For those people using some sort of cross-platform wrapper for their project, if it supports Mac OS X objective-c it will probably support Swift. Even if it takes time for the wrapper developers so what, the use of Swift is entirely optional.
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.
-- I was raised on the command line, bitch
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.
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.
"First they came for the slanderers and i said nothing."
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 and I've seen them aligned right. 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.
Here is a Mac OS X GUI app with a window and a button implemented in objective-c (main.h, AppDelegate.h and AppDelegate.m). The button handler calls C code (Work.h and Work.c) to do some work. Note that if C++ code had been used then AppDelegate.m would have been renamed to .mm so that Xcode would compile it as Objective-C++, necessary to link properly against the C++ code it uses.
// main.m
#import <Cocoa/Cocoa.h>
int main(int argc, const char * argv[]){
return NSApplicationMain(argc, argv);
}
// AppDelegate.h
#import <Cocoa/Cocoa.h>
@interface AppDelegate : NSObject <NSApplicationDelegate>
@property (assign) IBOutlet NSWindow *window;
@end
// AppDelegate.m
#import "AppDelegate.h"
#include "Work.h"
@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
}
- (IBAction)buttonPressed:(id)sender {
some_work();
}
@end
// Work.h
void some_work(void);
// Work.c
#include <stdio.h>
#include "Work.h"
void some_work(void) {
FILE *fp = fopen("/tmp/work.txt", "w");
if (fp != NULL) {
fprintf(fp, "Hello World\n");
fclose(fp);
}
}
Oh, stop trolling. You have obviously never used Qt, it will automatically fix the order of the dialog buttons for you. You can even launch the same application under GNOME and get one order, and under KDE and get another. It is controlled by the widget-style it uses. And it does more than that, it also matches the reading direction of the language you are using so that it reverses for Hebrew, Arabic or other right-to-left languages.
There are things that you need to handle yourself in a crossplatform application, but that is not one of them.
... HR departments began advertising for programmers with 3+ years of Swift programming experience.