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.
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
What possible application could ever require GDB as a dependency?
LLDB is a far superior debugger anyways.
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
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"?
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.
Apple has always been hostile to unified look on their platform.
You do realize, of course, that you are talking about the company that literally wrote the book on good, consistent UI design, right?
The above, linked pdf copy dates from 1995 (the earliest actual copy I could find in a 2 minute search), but Apple first published their most-excellent HIG manual on or around 1985, before most slashdotters were even born.
Now, get off my lawn!
Are you sure about the "metro"? Name is dead, but 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
You're wrong! You can write Windows Store apps in C++ just fine. This C++ can use win32, posix, STL etc just fine. (however, all apps run in a sandbox, so some win32/posix functions aren't as powerful as normal, e.g. the sandbox doesn't let a Windows Store app enumerate files on the hard disk outside of the files it's allowed to touch).
You can also write Windows Phone apps in the same C++. So a mobile app developer could write their core in posix platform-neutral C++, and have it portable across Android+iOS+Windows. I know a few who do.
Of course posix doesn't have anything to do with windowing systems or touch, and win32 APIs (e.g. gdi32.dll, user32.dll) don't apply to windows store or phone apps since they don't have GDI or the traditional windowing system. So your C++ code will invoke new WinRT APIs to access the new functionalities. WinRT is perfectly compatible with posix/win32 APIs. Indeed, for some functionality (e.g. audio), you're REQUIRED to use win32 APIs because they're not exposed in WinRT.
Here's some example code that shows how you'd mix the new WinRT APIs to get hold of sandbox-specific stuff, and then interop with traditional posix APIs. It also shows how the asynchronous nature of WinRT APIs combine with the synchronous traditional posix APIs:
auto f1 = Windows::ApplicationModel::Package::Current->InstalledLocation;
create_task(f1->GetFolderAsync("Assets")).then([this](StorageFolder ^f2)
{
create_task(f2->GetFileAsync("Logo.scale-100.png")).then([this](StorageFile ^f3)
{
auto path = f3->Path;
FILE *f = _wfopen(path->Data, L"r");
byte buf[100];
fread(buf, 1, 100, f);
fclose(f)
});
});
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.