I think the correct time to make a new programming language is when there has been some major advancement in theory. For example when OO was invented, the correct thing to do was go from C to Objective-C. And if, in a few years, Quantum-Oriented programming (made up name) is invented, Apple should go to Quantum-C.
In between these major advancements, the last major language should be advanced as smaller theoretical advances are made. e.g. Objective-C 1.1 gets exceptions, 2.0 gets ARC, 2.1 gets closures, 2.2 gets ... etc, etc. (made up version numbers)
Since there hasn't been any major theoretical advance in the last few years, it was not appropriate to release a whole new language. That seems self-evidently true to me. They should instead be focussing on keeping up with the latest research papers as they came out, and doing incremental releases of ObjC when a paper strikes them as worthy.
The point is that several paradigm shifts in programming have occurred very early on.
Functional programming (pattern matching), logical Programming, formal verification meta algorithm (genetic programming) and search all qualify in the same manner as Object Oriented programming.
So removing exception processing makes it easier to handle the exception in a reasonable way?
Yes, doing exception handling properly in a language is very difficult. Apple's engineers punted on this. That is the crux of it.
No, just like communism exception handling seems a good idea, but in practice it is not and should be avoided because of the confusion it adds.
It is just as important what is left out as what is added when creating a new language (it's all a matter of taste as a wise man once said).
This following immediate-mode expression generates a typical set of Pick 6 lottery numbers: six pseudo-random integers ranging from 1 to 40, guaranteed non-repeating, and displays them sorted in ascending order:
[I]x[?x?6?40] [/I]
The following expression finds all prime numbers from 1 to R. In both time and space, the calculation complexity is O(R^2)\,\! (in Big O notation).
[I](~R?R?.×R)/R?1??R [/I]
The following expression sorts a word list stored in matrix X according to word length:
[I]X[?X+.?' ';] [/I]
The following function "life", written in Dyalog APL, takes a boolean matrix and calculates the new generation according to Conway's Game of Life. It demonstrates the power of APL to implement a complex algorithm in very little code, but it is also very hard to follow unless one has an advanced knowledge of APL.
I'm currently working with a Fortune 500 and have the luxury of coding a project in Swift. From what I've heard, pretty much no one is using it at Apple. Was a mistake for Apple to introduce it as a replacement for Obj C - should have been added as an alternative.
Why would a company like Apple be expected to switch a significant amount of important projects over in a short timeframe? They are hiring engineers for Swift:
Swift Performance Software Engineer
"This open position is for engineers who want to work as part of the Swift team on optimizing the performance of the Swift compiler. This job involves working on the swift optimizer as well as working on improving LLVM, which is a central technology in the Swift language."
Swift Compiler Language Engineer
"This position is for an engineer to work on evolving and implementing the core Swift language."
Swift itself is a project and parts of it are written in Swift. It is both an alternative (short-term) and a replacement (long-term) for Objective-C. They didn't say to stop coding in Objective-C.
"Swift is ready for your next iOS and OS X project — or for addition into your current app — because Swift code works side-by-side with Objective-C.
You can begin using Swift code immediately to implement new features in your app, or enhance existing ones. New Swift code co-exists along side your existing Objective-C files in the same project, making it easy to adopt."
Version 1.2 is in a new beta with performance and stability improvements:
In an effort to troll DED Apple has responded to the complaints whch were clearly obvious to those of us who code this stuff for a living by updating the language to such an extent that it's not source compatible with the one released a mere few months ago. Objective c has never done that.
They have also signalled fixes for the very implementation details I mentioned here. Sourcekit crashes and compiler slowdowns. As they should. Good on them for listening. Luckily DED isn't head of developer marketing.
My first disclaimer is that I seem to the the only person on earth who actually likes Objective-C, which is fine I accept it has a steep learning curve (I remember struggling for a month trying to get my head around it).
For most on my programming work, I'm using C++ (which I love), and almost all on my apps are built around a C++ core with obj-c used to write the supporting parts of the program (usually platform specific). This makes between 60% to 70% of my app easily portable. If I'm writing for Mac and Linux, I'm generally going to use GNUStep so 95% of the code is shared between platforms, and the amount of obj-c will be higher. My one criticism of obj-c is that it can't match the speed of c++ for critical sections, this isn't an issue for me as mixing c++ and obj-c not only feels natural, It's also very easy, as both languages share a high degree of C compatibility and are generally mutually intelligible.
FWIW, here's a speed test comparison program I found
// the main program
import Foundation
let num_elements : NSInteger = 1000000
Performance_ObjCtoCPlusPlus.sortArrayCPlusPlus(num_elements)
Performance_ObjectiveC.sortArrayObjC(num_elements)
//---------------------------------------
//The Swift Program
// Put the code you want to measure the time of here.
let start : NSDate = NSDate()
var int_array = [Int](count: num_elements, repeatedValue: 0)
for i in 0..<(num_elements) {
int_array[i] = random()
}
let sorted_array = sorted(int_array, <)
let end : NSDate = NSDate()
let executionTime : NSTimeInterval = end.timeIntervalSinceDate(start)
println("swift executionTime: \(executionTime) seconds for \(num_elements) elements. \n");
//---------------------------------------
//The C++ Program
//
// FileCPlusPlus.cpp
// Performance_Console
//
// Created by Gian Luigi Romita on 11/06/14.
// Copyright (c) 2014 Gian Luigi Romita. All rights reserved.
//
#include <iostream>
#include <vector>
#include <stdlib.h> /* srand, rand */
#include <time.h> /* time */
#include <algorithm> // std::sort
#include <chrono>
#include "CPlusPlus.h"
void Performance_CPlusPlus::sortArray(unsigned int num_elements)
{
std::vector<int> int_vec(num_elements);
/* initialize random seed: */
srand ((unsigned)time(NULL));
for(int& x : int_vec)
{
x = rand() % num_elements;
};
std::chrono::high_resolution_clock::time_point begin = std::chrono::high_resolution_clock::now();
std::sort(int_vec.begin(), int_vec.end());
std::chrono::high_resolution_clock::time_point end = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> time_span = std::chrono::duration_cast<std::chrono::duration<double>>(end - begin);
std::cout << "C++ executionTime: " << time_span.count() << " seconds for " << num_elements << " elements." << std::endl;
}
//---------------------------------------
//The Objective C Program
#import "ObjC.h"
@implementation Performance_ObjectiveC
+ (void) sortArrayObjC: (NSInteger) array_size
{
NSMutableArray* array = [NSMutableArray array];
for(int i = 0; i < array_size; i++)
{
[array addObject: [NSNumber numberWithInt: arc4random()%array_size]];
}
NSDate *methodStart = [NSDate date];
// ... Do whatever you need to do ...
NSSortDescriptor* lowToHigh = [[NSSortDescriptor alloc ] initWithKey:@"self" ascending: YES];
[array sortUsingDescriptors:[NSArray arrayWithObject:lowToHigh]];
NSDate *methodFinish = [NSDate date];
NSTimeInterval executionTime = [methodFinish timeIntervalSinceDate:methodStart];
NSLog(@"ObjC executionTime: %f seconds for %ld elements. \n", executionTime, (long)array_size);
}
@end
Here are the results:
C++ executionTime: 0.051315 seconds for 1000000 elements.
ObjC executionTime: 1.149305 seconds for 1000000 elements.
swift executionTime: 0.168655 seconds for 1000000 elements.
Currently, C++ is fastest; Swift takes 3+ x as long as C++; Objective C takes 20+ x as long as C++ and 7+ x as long as Swift.
All have maximum safe optimization set for the compiler.
I have, so far, been unimpressed by swift. I can't discuss performance issues as I haven't written anything particularly critical in it, but it is at least as least as fast as a good Java VM (for the record I don't like Java as a language).
[\QUOTE]
As can be seen above, Swift, currently, performs quite well.
I suspect that it is better than Java!
For me the big test of a language is what I call the "is that my code?" test. Where if I come back to come code I haven't maintained for perhaps a year or so, how long does it take for me to pick up what I was trying to do. This is where C++ falls rather short when compared with obj-c which is the gold standard for long term maintability in my opinion.
It will take some time for swift to undergo such a test for me, but the syntax doesn't lend itself well, it seems it could fall as low as JavaScript.
TL;DR 1. I'm not keen on swift's syntax, though I accept that is partly due to my comfort with C++ and obj-c.
2. I'm not keen on how limiting it is (it hides a little too much for me), though I agree beginners will be making less mistakes.
3. If I can't easilly mix it will C++, I simply won't have a use for it.
There are several Obj-C/C++ wrapper examples ... Does this help the situation?
Not really, since the "solution" presented there is to write an objective-c wrapper around the c++ code and then use that with swift... Why bother with swift, I'll just stick with objective-c and c++ (technically I use objective-c++) as they are IMHO "better" languages.
I quoted some code and timings above, comparing C++, Objective C and Swift.
They performed about as expected.
However, since Apple has control of Swift, the Language, the compiler and the runtime -- I expect they will optimize * these components for each other (they were designed with each other in mind).
Though Apple also owns it, apparently, the structure/implementation of Objective C prevents this optimization -- and Apple has no control of C++.
* Apple already does optimize to some extent -- the Swift compiler includes generation of SIL (Swift Intermediate Language) which passes optimizations specific to Swift, through the compiler to the runtime. I suspect that this will only increase as the Language and the compiler/runtime stack matures.
What I suspect will happen, is that Apple will place it's major efforts into the development of Swift and the underlying stack, to support Swift -- leaving Objective C pretty much alone.
I suspect that will happen rapidly, say, 12-18 months.
At that time, you could be faced with some interesting choices regarding iOS, OS X and cross-platform development.
What will you do if Swift offers some compelling advantages over your other options:
features available in Swift only
performance available in Swift only
productivity, safety and efficiency available in Swift only **
** I'm thinking of things UI Bindings to replace code, KVO, Foundation components and higher level abstractions that avoid or minimize writing code (and all the issues goes with it).
I've been using and watching Apple for almost 37 years -- and that's how Apple rolls!
FWIW, here's a speed test comparison program I found
// the main program
import Foundation
let num_elements : NSInteger = 1000000
Performance_ObjCtoCPlusPlus.sortArrayCPlusPlus(num_elements)
Performance_ObjectiveC.sortArrayObjC(num_elements)
//---------------------------------------
//The Swift Program
// Put the code you want to measure the time of here.
let start : NSDate = NSDate()
var int_array = [Int](count: num_elements, repeatedValue: 0)
for i in 0..<(num_elements) {
int_array[i] = random()
}
let sorted_array = sorted(int_array, <)
let end : NSDate = NSDate()
let executionTime : NSTimeInterval = end.timeIntervalSinceDate(start)
println("swift executionTime: \(executionTime) seconds for \(num_elements) elements. \n");
//---------------------------------------
//The C++ Program
//
// FileCPlusPlus.cpp
// Performance_Console
//
// Created by Gian Luigi Romita on 11/06/14.
// Copyright (c) 2014 Gian Luigi Romita. All rights reserved.
//
#include <iostream>
#include <vector>
#include <stdlib.h> /* srand, rand */
#include <time.h> /* time */
#include <algorithm> // std::sort
#include <chrono>
#include "CPlusPlus.h"
void Performance_CPlusPlus::sortArray(unsigned int num_elements)
{
std::vector<int> int_vec(num_elements);
/* initialize random seed: */
srand ((unsigned)time(NULL));
for(int& x : int_vec)
{
x = rand() % num_elements;
};
std::chrono::high_resolution_clock::time_point begin = std::chrono::high_resolution_clock::now();
std::sort(int_vec.begin(), int_vec.end());
std::chrono::high_resolution_clock::time_point end = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> time_span = std::chrono::duration_cast<std::chrono::duration<double>>(end - begin);
std::cout << "C++ executionTime: " << time_span.count() << " seconds for " << num_elements << " elements." << std::endl;
}
//---------------------------------------
//The Objective C Program
#import "ObjC.h"
@implementation Performance_ObjectiveC
+ (void) sortArrayObjC: (NSInteger) array_size
{
NSMutableArray* array = [NSMutableArray array];
for(int i = 0; i < array_size; i++)
{
[array addObject: [NSNumber numberWithInt: arc4random()%array_size]];
}
NSDate *methodStart = [NSDate date];
// ... Do whatever you need to do ...
NSSortDescriptor* lowToHigh = [[NSSortDescriptor alloc ] initWithKey:@"self" ascending: YES];
[array sortUsingDescriptors:[NSArray arrayWithObject:lowToHigh]];
NSDate *methodFinish = [NSDate date];
NSTimeInterval executionTime = [methodFinish timeIntervalSinceDate:methodStart];
NSLog(@"ObjC executionTime: %f seconds for %ld elements. \n", executionTime, (long)array_size);
}
@end
Here are the results:
C++ executionTime: 0.051315 seconds for 1000000 elements.
ObjC executionTime: 1.149305 seconds for 1000000 elements.
swift executionTime: 0.168655 seconds for 1000000 elements.
Currently, C++ is fastest; Swift takes 3+ x as long as C++; Objective C takes 20+ x as long as C++ and 7+ x as long as Swift.
All have maximum safe optimization set for the compiler.
I quoted some code and timings above, comparing C++, Objective C and Swift.
They performed about as expected.
However, since Apple has control of Swift, the Language, the compiler and the runtime -- I expect they will optimize * these components for each other (they were designed with each other in mind).
Though Apple also owns it, apparently, the structure/implementation of Objective C prevents this optimization -- and Apple has no control of C++.
* Apple already does optimize to some extent -- the Swift compiler includes generation of SIL (Swift Intermediate Language) which passes optimizations specific to Swift, through the compiler to the runtime. I suspect that this will only increase as the Language and the compiler/runtime stack matures.
What I suspect will happen, is that Apple will place it's major efforts into the development of Swift and the underlying stack, to support Swift -- leaving Objective C pretty much alone.
I suspect that will happen rapidly, say, 12-18 months.
At that time, you could be faced with some interesting choices regarding iOS, OS X and cross-platform development.
What will you do if Swift offers some compelling advantages over your other options:
features available in Swift only
performance available in Swift only
productivity, safety and efficiency available in Swift only **
** I'm thinking of things UI Bindings to code, KVO, Foundation components and higher level abstractions that avoid or minimize writing code (and all the issues goes with it).
I've been using and watching Apple for almost 36 years -- and that's how Apple rolls!
That's a very well crafted example, obj-c will be slow in this use case because each message has to be dispatched via the runtime, in C++ it is little more than a function call (and a jump table in swift). Hence why I use objective-c++, so I can use c++ when I know I'm going to need a tight loop, but since you can mix obj-c and c++ in the same code it doesn't matter.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
I honestly don't mind if Apple want to throw their billions of dollars at making swift shinier, as long as they leave obj-c there for me to get some real, bill paying, work done. But I totaly fear what you have suggested, what if they freeze the API for obj-c, and only release the new frameworks for swift... That's when I will have to make some big decisions.
That's a very well crafted example, obj-c will be slow in this use case because each message has to be dispatched via the runtime, in C++ it is little more than a function call (and a jump table in swift). Hence why I use objective-c++, so I can use c++ when I know I'm going to need a tight loop, but since you can mix obj-c and c++ in the same code it doesn't matter.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
I honestly don't mind if Apple want to throw their billions of dollars at making swift shinier, as long as they leave obj-c there for me to get some real, bill paying, work done. But I totaly fear what you have suggested, what if they freeze the API for obj-c, and only release the new frameworks for swift... That's when I will have to make some big decisions.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
But you do ... My fault, in order to save space. I intermingled the code. They are not separate programs -- rather they are all included within 1 App. The Swift portion is the main file that calls the others:
I got the app from the web. If you have Xcode 6 you can try it ...
That's a very well crafted example, obj-c will be slow in this use case because each message has to be dispatched via the runtime, in C++ it is little more than a function call (and a jump table in swift). Hence why I use objective-c++, so I can use c++ when I know I'm going to need a tight loop, but since you can mix obj-c and c++ in the same code it doesn't matter.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
I honestly don't mind if Apple want to throw their billions of dollars at making swift shinier, as long as they leave obj-c there for me to get some real, bill paying, work done. But I totaly fear what you have suggested, what if they freeze the API for obj-c, and only release the new frameworks for swift... That's when I will have to make some big decisions.
The problem with the example is that NSNumber is not the most primitive way of representing an int in objective c - that would be int. so all this boxing and unboxing into NSNumbers or NSArrays is moot because you can use c arrays and c primitives if performance mattered in these things in real life . ( in most cases performance is affected by slow disk, network or UI rendering not sorting).
In an effort to troll DED Apple has responded to the complaints whch were clearly obvious to those of us who code this stuff for a living by updating the language to such an extent that it's not source compatible with the one released a mere few months ago. Objective c has never done that.
Objective-C never changed during its first 5 years all the way back in the 80s before the internet? As to source incompatibility, they have an updater and it's better they do any major changes quickly after release.
They have also signalled fixes for the very implementation details I mentioned here. Sourcekit crashes and compiler slowdowns. As they should. Good on them for listening. Luckily DED isn't head of developer marketing.
They get crash reports sent to them all the time, it's not a case of listening or not listening to general complaints about crashing.
This article is just talking about major companies that have started using Swift. It sounds like you'd rather there was an article that just made random complaints about Swift and the tools but I don't know what that would achieve. If the tools and language aren't up to a good standard within 1-2 years then that would be time to write a complaint article. It's way too early in the release schedule.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
I honestly don't mind if Apple want to throw their billions of dollars at making swift shinier, as long as they leave obj-c there for me to get some real, bill paying, work done.
You can call Objective-C from Swift and C++ from Objective-C so you can make wrapper functions to mingle C++ with Swift. Maybe they can find a way to add optimal wrapper classes on the fly so you don't have to do it manually. You can certainly use large codebases of existing C++ code and the only extra code would be for the new Swift code you add. There's another way besides using Objective-C intermediates here but it looks messy and needs the C++ rewritten:
[VIDEO]
It really should be as simple as something like @cpp_functionname() being called from Swift and the compiler does everything in between for you.
@marvin. I merely called the report a puff piece and got technically illiterate abuse. The fixes Apple put in here are necessary for any sizeable project. People were complaining of incredibly slow compile times and continuous xcode and sourcekit crashes on moderate sized projects.
And changing the syntax to break existant code( rather than adding new syntax) is rare to non-existant in computer languages in the field.
The language is good and I am looking forward to firing up a side project I am writing if these bugs are fixed.
@marvin. I merely called the report a puff piece and got technically illiterate abuse. The fixes Apple put in here are necessary for any sizeable project. People were complaining of incredibly slow compile times and continuous xcode and sourcekit crashes on moderate sized projects.
The complaints were just anecdotal evidence that nobody could verify as to how many were affected, how frequent the crashes were, how much any slowdown was. The article doesn't make any claims about stable software not being a requirement for large projects, it's just establishing that people are interested in using Swift on their projects. The apps mentioned in the article are probably very lightweight, not much more than websites. Leaving out details about unverifiable problems people have had on their own projects doesn't mean the article is trying to cover up the truth about the situation. Your reactions sounded more like someone who prefers Objective-C trying to find as much fault with Swift as you could and blowing it out of proportion, which is common when new technology comes around. There's no rush for Swift to be an immediate industry-proven replacement for Objective-C. It will develop into that as it's put through production tests.
It's too much to expect no changes like this from such an early release. It's good that they are prepared to make radical changes to get it right instead of adding in ugly patches.
Swift is being compared to languages from 20-30 years ago but it's fairer to compare to these. C# is probably the most popular out of these and still had a good decade head-start.
I am not a professional programmer -- but have some web development experience (JavaScript, Perl, PHP, ColdFusion) and have some Java, Obj-C and now Swift programming under my belt.
From my perspective, it seems you might be better off using Swift and Java as opposed to Obj-C and Java. It won't give you a cross-platform code base, but it could make you more productive. because:
Swift Syntax is more like Java Syntax than Obj-C syntax
This is true. If you are the programmer equivalent of a grandma who needs specific step-by-step instructions for everything, and anything being even the slightest big different throws you into a tailspin, then Objective-C with its square brackets will freak you right the heck out.
[*] Swift Syntax is more concise (less cruft) and less fiddly than Obj-C
More concise, yes. However, it is far more fiddly than Objective-C on its worst day, due to 1) lack of readability due to all the "conciseness" and various shortcuts that reduce typing at the expense of readability, 2) the complete lack of helpful error messages, most of which either offer no useful information at all, or worse, point at the problem being somewhere other than where it actually is, and 3) the just plain bugginess of the compiler, which often flags completely syntactically valid code as being incorrect.
[*] Swft code is faster to write and debug than Obj-C
It's not even close to being faster (or even the same) to write, due to the issues above. And don't get me started on debugging. Objective-C is far, far, far faster to debug, because 1) it has a debugger that actually works, so you don't have to resort to sprinkling logs everywhere to debug anything, and 2) if you *do* decide to use logs to debug something, you don't die of old age waiting for it to compile.
[*] Swft code is more readable & maintainable than Obj-C
Swift code is nowhere near as readable as Objective-C code. It's not even close. Objective-C may have weaknesses, but readability is not one of them. The verbosity of Objective-C code may be a PITA to type, but it often makes method names so clear that even a non-programmer can get a general gist of what they do.
[*] If the Swift code compiles, It will run with fewer crashes than Obj-C
Only if the Objective-C code is poorly written.
[*] You can leverage existing Obj-C Code by adding Swift Code in the same project (Mix and Match)
Yes, and the boundary between the two is often awkward to work with.
[*] Swift runtime outperforms Obj-C runtime (and likely C runtime, before long)
Swift will never outperform the C runtime. The C runtime barely even exists; C is about as close to the metal as you can get without writing in assembler. Meanwhile, Swift has to deal with things like ARC and vtable dispatch which can never be as fast as C function calls.
As for Objective-C, it's easy to make contrived examples using NSNumber in which the Objective-C code performs badly, but most Objective-C code isn't written that way. It's true that Swift's vtable dispatch is faster than Objective-C's message passing for method calls (at the expense of a rich wealth of dynamic functionality), but that only matters when you're calling a method. Any time you're not calling a method in Objective-C, you're basically just writing straight C, which is incredibly fast. An Objective-C programmer can easily write the parts where performance is a concern in straight C, and using techniques like IMP caching, even method calls can be made to perform similarly to C.
The irony of the situation is that in the real world, actual Swift code tends to perform far worse than Objective-C code, because all the frameworks are written in Objective-C and the bridging tends to have performance implications.
Swift code is nowhere near as readable as Objective-C code. It's not even close. Objective-C may have weaknesses, but readability is not one of them. The verbosity of Objective-C code may be a PITA to type, but it often makes method names so clear that even a non-programmer can get a general gist of what they do.
I find Swift considerably more succinct and straightforward to read than Obj-C.
I am not a professional programmer -- but have some web development experience (JavaScript, Perl, PHP, ColdFusion) and have some Java, Obj-C and now Swift programming under my belt.
From my perspective, it seems you might be better off using Swift and Java as opposed to Obj-C and Java. It won't give you a cross-platform code base, but it could make you more productive. because:
Swift Syntax is more like Java Syntax than Obj-C syntax
This is true. If you are the programmer equivalent of a grandma who needs specific step-by-step instructions for everything, and anything being even the slightest big different throws you into a tailspin, then Objective-C with its square brackets will freak you right the heck out.
I guess you could call me a grandpa -- I'm 75 and have 3 grandkids ... But I resent the stereotype! Actually, I prefer concise code and abstraction as opposed to specific step-by-step instructions. I like leveraging, trusting, building upon supplied standard solutions (frameworks, Storyboards, etc.) as opposed to re-inventing the wheel -- then proliferating my nonstandard solution across many projects.
It is amazing (to me) now many respected, excellent programmers will, for instance, implement the UI entirely in code -- ignoring the capabilities of IB NIB/XIBs and Storyboards. I often feel like asking: Why do you accept the underlying abstraction of using frameworks -- yet ignore the UI abstraction.
In the late 1950s I met a programmer who did not trust the abstraction of Assemblers -- he coded everything in Octal Absolute ... True story.
[*] Swift Syntax is more concise (less cruft) and less fiddly than Obj-C
More concise, yes. However, it is far more fiddly than Objective-C on its worst day, due to 1) lack of readability due to all the "conciseness" and various shortcuts that reduce typing at the expense of readability, 2) the complete lack of helpful error messages, most of which either offer no useful information at all, or worse, point at the problem being somewhere other than where it actually is, and 3) the just plain bugginess of the compiler, which often flags completely syntactically valid code as being incorrect.
[*] Swft code is faster to write and debug than Obj-C
It's not even close to being faster (or even the same) to write, due to the issues above. And don't get me started on debugging. Objective-C is far, far, far faster to debug, because 1) it has a debugger that actually works, so you don't have to resort to sprinkling logs everywhere to debug anything, and 2) if you *do* decide to use logs to debug something, you don't die of old age waiting for it to compile.
Most of the above are compiler/debugger/runtime implementation issues -- and to a great extent have been addressed in Swift 1.2.
[*] Swft code is more readable & maintainable than Obj-C
Swift code is nowhere near as readable as Objective-C code. It's not even close. Objective-C may have weaknesses, but readability is not one of them. The verbosity of Objective-C code may be a PITA to type, but it often makes method names so clear that even a non-programmer can get a general gist of what they do.
It's a matter of taste! You can have long, self-documenting class, function and variable names, etc. in Swift, just as in Objective-C. Xcode code-completion makes them very easy to type in either language.
[*] If the Swift code compiles, It will run with fewer crashes than Obj-C
Only if the Objective-C code is poorly written.
[*] You can leverage existing Obj-C Code by adding Swift Code in the same project (Mix and Match)
Yes, and the boundary between the two is often awkward to work with.
It'a awkward, as is anything new or different. Once understood, it becomes second nature.
[*] Swift runtime outperforms Obj-C runtime (and likely C runtime, before long)
Swift will never outperform the C runtime. The C runtime barely even exists; C is about as close to the metal as you can get without writing in assembler. Meanwhile, Swift has to deal with things like ARC and vtable dispatch which can never be as fast as C function calls.
As for Objective-C, it's easy to make contrived examples using NSNumber in which the Objective-C code performs badly, but most Objective-C code isn't written that way. It's true that Swift's vtable dispatch is faster than Objective-C's message passing for method calls (at the expense of a rich wealth of dynamic functionality), but that only matters when you're calling a method. Any time you're not calling a method in Objective-C, you're basically just writing straight C, which is incredibly fast. An Objective-C programmer can easily write the parts where performance is a concern in straight C, and using techniques like IMP caching, even method calls can be made to perform similarly to C.
The irony of the situation is that in the real world, actual Swift code tends to perform far worse than Objective-C code, because all the frameworks are written in Objective-C and the bridging tends to have performance implications.
The frameworks are being rewritten and refined as we speak -- because of the tight integration of Swift, the compiler and the runtime -- the advantage will go to Swift.
Being a 75-year-old grandpa who requires specific step-by-step instructions -- I am pretty set in my ways ... I am not as flexible as you, so, likely I'll never be able to exploit the advantages of Swift ... Or anything else new!
Comments
The point is that several paradigm shifts in programming have occurred very early on.
Functional programming (pattern matching), logical Programming, formal verification meta algorithm (genetic programming) and search all qualify in the same manner as Object Oriented programming.
I sure hope not. I would have expected a lot of segfaults if it was.
No, just like communism exception handling seems a good idea, but in practice it is not and should be avoided because of the confusion it adds.
It is just as important what is left out as what is added when creating a new language (it's all a matter of taste as a wise man once said).
This displays "Hello, world":
'Hello, world'
This following immediate-mode expression generates a typical set of Pick 6 lottery numbers: six pseudo-random integers ranging from 1 to 40, guaranteed non-repeating, and displays them sorted in ascending order:
[I]x[?x?6?40]
[/I]
The following expression finds all prime numbers from 1 to R. In both time and space, the calculation complexity is O(R^2)\,\! (in Big O notation).
[I](~R?R?.×R)/R?1??R
[/I]
The following expression sorts a word list stored in matrix X according to word length:
[I]X[?X+.?' ';]
[/I]
The following function "life", written in Dyalog APL, takes a boolean matrix and calculates the new generation according to Conway's Game of Life. It demonstrates the power of APL to implement a complex algorithm in very little code, but it is also very hard to follow unless one has an advanced knowledge of APL.
[I]life?{?1 ??.?3 4=+/,¯1 0 1?.?¯1 0 1?.???}[/I]
Iverson is raveling in his grave :D
Why would a company like Apple be expected to switch a significant amount of important projects over in a short timeframe? They are hiring engineers for Swift:
https://jobs.apple.com/us/search?#&ss=swift&lo=0*USA&pN=0
Swift Performance Software Engineer
"This open position is for engineers who want to work as part of the Swift team on optimizing the performance of the Swift compiler. This job involves working on the swift optimizer as well as working on improving LLVM, which is a central technology in the Swift language."
Swift Compiler Language Engineer
"This position is for an engineer to work on evolving and implementing the core Swift language."
Swift itself is a project and parts of it are written in Swift. It is both an alternative (short-term) and a replacement (long-term) for Objective-C. They didn't say to stop coding in Objective-C.
"Swift is ready for your next iOS and OS X project — or for addition into your current app — because Swift code works side-by-side with Objective-C.
You can begin using Swift code immediately to implement new features in your app, or enhance existing ones. New Swift code co-exists along side your existing Objective-C files in the same project, making it easy to adopt."
Version 1.2 is in a new beta with performance and stability improvements:
https://developer.apple.com/swift/blog/?id=22
They have also signalled fixes for the very implementation details I mentioned here. Sourcekit crashes and compiler slowdowns. As they should. Good on them for listening. Luckily DED isn't head of developer marketing.
FWIW, here's a speed test comparison program I found
// the main program import Foundation let num_elements : NSInteger = 1000000 Performance_ObjCtoCPlusPlus.sortArrayCPlusPlus(num_elements) Performance_ObjectiveC.sortArrayObjC(num_elements) //--------------------------------------- //The Swift Program // Put the code you want to measure the time of here. let start : NSDate = NSDate() var int_array = [Int](count: num_elements, repeatedValue: 0) for i in 0..<(num_elements) { int_array[i] = random() } let sorted_array = sorted(int_array, <) let end : NSDate = NSDate() let executionTime : NSTimeInterval = end.timeIntervalSinceDate(start) println("swift executionTime: \(executionTime) seconds for \(num_elements) elements. \n"); //--------------------------------------- //The C++ Program // // FileCPlusPlus.cpp // Performance_Console // // Created by Gian Luigi Romita on 11/06/14. // Copyright (c) 2014 Gian Luigi Romita. All rights reserved. // #include <iostream> #include <vector> #include <stdlib.h> /* srand, rand */ #include <time.h> /* time */ #include <algorithm> // std::sort #include <chrono> #include "CPlusPlus.h" void Performance_CPlusPlus::sortArray(unsigned int num_elements) { std::vector<int> int_vec(num_elements); /* initialize random seed: */ srand ((unsigned)time(NULL)); for(int& x : int_vec) { x = rand() % num_elements; }; std::chrono::high_resolution_clock::time_point begin = std::chrono::high_resolution_clock::now(); std::sort(int_vec.begin(), int_vec.end()); std::chrono::high_resolution_clock::time_point end = std::chrono::high_resolution_clock::now(); std::chrono::duration<double> time_span = std::chrono::duration_cast<std::chrono::duration<double>>(end - begin); std::cout << "C++ executionTime: " << time_span.count() << " seconds for " << num_elements << " elements." << std::endl; } //--------------------------------------- //The Objective C Program #import "ObjC.h" @implementation Performance_ObjectiveC + (void) sortArrayObjC: (NSInteger) array_size { NSMutableArray* array = [NSMutableArray array]; for(int i = 0; i < array_size; i++) { [array addObject: [NSNumber numberWithInt: arc4random()%array_size]]; } NSDate *methodStart = [NSDate date]; // ... Do whatever you need to do ... NSSortDescriptor* lowToHigh = [[NSSortDescriptor alloc ] initWithKey:@"self" ascending: YES]; [array sortUsingDescriptors:[NSArray arrayWithObject:lowToHigh]]; NSDate *methodFinish = [NSDate date]; NSTimeInterval executionTime = [methodFinish timeIntervalSinceDate:methodStart]; NSLog(@"ObjC executionTime: %f seconds for %ld elements. \n", executionTime, (long)array_size); } @endHere are the results:
Currently, C++ is fastest; Swift takes 3+ x as long as C++; Objective C takes 20+ x as long as C++ and 7+ x as long as Swift.
All have maximum safe optimization set for the compiler.
I quoted some code and timings above, comparing C++, Objective C and Swift.
They performed about as expected.
However, since Apple has control of Swift, the Language, the compiler and the runtime -- I expect they will optimize * these components for each other (they were designed with each other in mind).
Though Apple also owns it, apparently, the structure/implementation of Objective C prevents this optimization -- and Apple has no control of C++.
* Apple already does optimize to some extent -- the Swift compiler includes generation of SIL (Swift Intermediate Language) which passes optimizations specific to Swift, through the compiler to the runtime. I suspect that this will only increase as the Language and the compiler/runtime stack matures.
What I suspect will happen, is that Apple will place it's major efforts into the development of Swift and the underlying stack, to support Swift -- leaving Objective C pretty much alone.
I suspect that will happen rapidly, say, 12-18 months.
At that time, you could be faced with some interesting choices regarding iOS, OS X and cross-platform development.
What will you do if Swift offers some compelling advantages over your other options:
** I'm thinking of things UI Bindings to replace code, KVO, Foundation components and higher level abstractions that avoid or minimize writing code (and all the issues goes with it).
I've been using and watching Apple for almost 37 years -- and that's how Apple rolls!
That's a very well crafted example, obj-c will be slow in this use case because each message has to be dispatched via the runtime, in C++ it is little more than a function call (and a jump table in swift). Hence why I use objective-c++, so I can use c++ when I know I'm going to need a tight loop, but since you can mix obj-c and c++ in the same code it doesn't matter.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
I honestly don't mind if Apple want to throw their billions of dollars at making swift shinier, as long as they leave obj-c there for me to get some real, bill paying, work done. But I totaly fear what you have suggested, what if they freeze the API for obj-c, and only release the new frameworks for swift... That's when I will have to make some big decisions.
If I use swift I don't have the C++ option anymore and I'm stuck with whatever dispatch mechanism I compiled it with.
But you do ... My fault, in order to save space. I intermingled the code. They are not separate programs -- rather they are all included within 1 App. The Swift portion is the main file that calls the others:
I got the app from the web. If you have Xcode 6 you can try it ...
lost the link, bit will post it when I find it!
Edit: Here's the link:
https://github.com/romitagl/shared
Sorry for the delay -- I'm ODing on a really spicy ceviche and horchata -- brings tears to my eyes ...
The problem with the example is that NSNumber is not the most primitive way of representing an int in objective c - that would be int. so all this boxing and unboxing into NSNumbers or NSArrays is moot because you can use c arrays and c primitives if performance mattered in these things in real life . ( in most cases performance is affected by slow disk, network or UI rendering not sorting).
You don't need C++ either. Objective C is C.
Objective-C never changed during its first 5 years all the way back in the 80s before the internet? As to source incompatibility, they have an updater and it's better they do any major changes quickly after release.
They get crash reports sent to them all the time, it's not a case of listening or not listening to general complaints about crashing.
This article is just talking about major companies that have started using Swift. It sounds like you'd rather there was an article that just made random complaints about Swift and the tools but I don't know what that would achieve. If the tools and language aren't up to a good standard within 1-2 years then that would be time to write a complaint article. It's way too early in the release schedule.
You can call Objective-C from Swift and C++ from Objective-C so you can make wrapper functions to mingle C++ with Swift. Maybe they can find a way to add optimal wrapper classes on the fly so you don't have to do it manually. You can certainly use large codebases of existing C++ code and the only extra code would be for the new Swift code you add. There's another way besides using Objective-C intermediates here but it looks messy and needs the C++ rewritten:
[VIDEO]
It really should be as simple as something like @cpp_functionname() being called from Swift and the compiler does everything in between for you.
And changing the syntax to break existant code( rather than adding new syntax) is rare to non-existant in computer languages in the field.
The language is good and I am looking forward to firing up a side project I am writing if these bugs are fixed.
Ok, I see your point. From what I read just now it's not the type itself your defining, but a member (name) and its associated type.
But this is what you need in most cases I guess and almost the same as you would like to see (only a bit less abstract).
But I might not see the whole picture, so maybe someone else with more knowledge about this can comment?
Edit: so in Swift you have to write:
enum StringOrInteger {
case StringType(String)
case IntType(Int)
}
to define your optional type and write:
switch optional value {
case .StringType(let s): println(s)
case .IntType(let i): println(\(i)
}
to select it.
One good thing about Swift is because it's such a new language there's a good chance they'll adopt this feature soon.The complaints were just anecdotal evidence that nobody could verify as to how many were affected, how frequent the crashes were, how much any slowdown was. The article doesn't make any claims about stable software not being a requirement for large projects, it's just establishing that people are interested in using Swift on their projects. The apps mentioned in the article are probably very lightweight, not much more than websites. Leaving out details about unverifiable problems people have had on their own projects doesn't mean the article is trying to cover up the truth about the situation. Your reactions sounded more like someone who prefers Objective-C trying to find as much fault with Swift as you could and blowing it out of proportion, which is common when new technology comes around. There's no rush for Swift to be an immediate industry-proven replacement for Objective-C. It will develop into that as it's put through production tests.
New languages don't come around very often. C# had some breaking changes between versions:
http://stackoverflow.com/questions/2843318/is-c-sharp-4-0-backward-compatible-to-c-sharp-2-0
It's too much to expect no changes like this from such an early release. It's good that they are prepared to make radical changes to get it right instead of adding in ugly patches.
There's a history of languages here:
http://en.wikipedia.org/wiki/History_of_programming_languages
2000 - ActionScript
2001 - C#
2001 - Visual Basic .NET
2002 - F#
2003 - Groovy
2003 - Scala
2007 - Clojure
2009 - Go
2011 - Dart
2012 - Rust
2014 - Swift
Swift is being compared to languages from 20-30 years ago but it's fairer to compare to these. C# is probably the most popular out of these and still had a good decade head-start.
More concise, yes. However, it is far more fiddly than Objective-C on its worst day, due to 1) lack of readability due to all the "conciseness" and various shortcuts that reduce typing at the expense of readability, 2) the complete lack of helpful error messages, most of which either offer no useful information at all, or worse, point at the problem being somewhere other than where it actually is, and 3) the just plain bugginess of the compiler, which often flags completely syntactically valid code as being incorrect.
It's not even close to being faster (or even the same) to write, due to the issues above. And don't get me started on debugging. Objective-C is far, far, far faster to debug, because 1) it has a debugger that actually works, so you don't have to resort to sprinkling logs everywhere to debug anything, and 2) if you *do* decide to use logs to debug something, you don't die of old age waiting for it to compile.
Swift code is nowhere near as readable as Objective-C code. It's not even close. Objective-C may have weaknesses, but readability is not one of them. The verbosity of Objective-C code may be a PITA to type, but it often makes method names so clear that even a non-programmer can get a general gist of what they do.
Only if the Objective-C code is poorly written.
Yes, and the boundary between the two is often awkward to work with.
Swift will never outperform the C runtime. The C runtime barely even exists; C is about as close to the metal as you can get without writing in assembler. Meanwhile, Swift has to deal with things like ARC and vtable dispatch which can never be as fast as C function calls.
As for Objective-C, it's easy to make contrived examples using NSNumber in which the Objective-C code performs badly, but most Objective-C code isn't written that way. It's true that Swift's vtable dispatch is faster than Objective-C's message passing for method calls (at the expense of a rich wealth of dynamic functionality), but that only matters when you're calling a method. Any time you're not calling a method in Objective-C, you're basically just writing straight C, which is incredibly fast. An Objective-C programmer can easily write the parts where performance is a concern in straight C, and using techniques like IMP caching, even method calls can be made to perform similarly to C.
The irony of the situation is that in the real world, actual Swift code tends to perform far worse than Objective-C code, because all the frameworks are written in Objective-C and the bridging tends to have performance implications.
I find Swift considerably more succinct and straightforward to read than Obj-C.
Swift vs. Objective-C is like textspeak vs. complete sentences.
ObjectiveCIsCompleteSentencesIsAHorribleExperienceToSayTheLeast;
I guess you could call me a grandpa -- I'm 75 and have 3 grandkids ... But I resent the stereotype! Actually, I prefer concise code and abstraction as opposed to specific step-by-step instructions. I like leveraging, trusting, building upon supplied standard solutions (frameworks, Storyboards, etc.) as opposed to re-inventing the wheel -- then proliferating my nonstandard solution across many projects.
It is amazing (to me) now many respected, excellent programmers will, for instance, implement the UI entirely in code -- ignoring the capabilities of IB NIB/XIBs and Storyboards. I often feel like asking: Why do you accept the underlying abstraction of using frameworks -- yet ignore the UI abstraction.
In the late 1950s I met a programmer who did not trust the abstraction of Assemblers -- he coded everything in Octal Absolute ... True story.
Most of the above are compiler/debugger/runtime implementation issues -- and to a great extent have been addressed in Swift 1.2.
It's a matter of taste! You can have long, self-documenting class, function and variable names, etc. in Swift, just as in Objective-C. Xcode code-completion makes them very easy to type in either language.
It'a awkward, as is anything new or different. Once understood, it becomes second nature.
The frameworks are being rewritten and refined as we speak -- because of the tight integration of Swift, the compiler and the runtime -- the advantage will go to Swift.
Being a 75-year-old grandpa who requires specific step-by-step instructions -- I am pretty set in my ways ... I am not as flexible as you, so, likely I'll never be able to exploit the advantages of Swift ... Or anything else new!