If one coded an algorithm in Xcode using C, Objective-C, or Swift the compiled code would be identical. Ergo, Swift has the performance of C, period.
Nonsense! Speed depends on optimizations that exist in the compiler (and even linker, etc) and the ability of the language to expose code and data to optimization. The more guarantees you have about what your variables are, the more chances you have to optimize with them. The better the language exposes code interdependencies, the more chances the compiler has to optimize them.
See the discussion in the Swift manual (iBooks) on Arrays and Dictionaries and how you can optimize copies away most of the time for constant data. In C, you may have a float array and a separate pointer that points to its 19th element but treats it as char * rather than float[]. It's pretty hard for a compiler to come up with as many safe optimizations in that environment as in Swift. On the other hand, C allows the programmer to do flexible things like treat his array as both types at once, which may lead to better speed than Swift can hope for, but at potentially great risk to reliability and safety.
And Assembly code can be hand-tuned to go faster than C if you know the machine language in detail and are willing to spend hours sweating the details. I've done it. It ain't fun, and is seldom productive unless used in the very, very inmost loops.
What Swift seems to promise is a nice balance of development speed and ease vs execution speed and reliability.
For a very concrete example: C doesn't check that data fits inside the memory allocated for variables; this lack of checking makes it faster when dealing with arrays than other, safer languages. But it also leads to the infamous buffer overflows and vulnerabilities like Heartbleed (though some really bad design helped Heartbeat achieve fame).
Swift does guarantee that data can't overflow its variables. This takes a bit longer, but is vastly safer. Programmers will probably still be able to create buffer overflows, but they'll have to work really hard to do so.
Anyway, it's impossible in most cases to look at a language description and say whether in practice programs written to normal expectations of productivity will necessarily run faster or slower than in other languages when written to similar standards. You have to use the language to find out, and use it on the kind of application you want to write. If Apple's numbers say it's very fast, but not as fast as C form most things, I'll tend to believe them.
They appropriated WebKit pretty quickly. Yes, that was freely available, but good ol’ Microsoft was able to reverse engineer before, and if they can do it, Google can!
They appropriated WebKit pretty quickly. Yes, that was freely available, but good ol’ Microsoft was able to reverse engineer before, and if they can do it, Google can!
But WebKit is open source and uses HTML, CSS, and JS standards. Swift is specifically to make Apple's developer spend less time and money to develop apps that will strengthen its platform.
If Google really wanted to copy Apple they wouldn't be using Java and they wouldn't have such a shitty IDE and documentation.
They appropriated WebKit pretty quickly. Yes, that was freely available, but good ol’ Microsoft was able to reverse engineer before, and if they can do it, Google can!
Didn't WebKit turn into a consortium effort after its initial inception by Apple?
Just what Apple needs, another odd-ball language. Next they should come up with a replacement for English, so that people that want to use Siri can communicate more effectively, in an intuitive, interactive and fun way.
I'm a little surprised no one has mentioned the legal advantages this code switch is going to give Apple. Now, no company will be able to claim code theft or infringement in their software. Swift will enable the creation of code that may perform nearly identical functions, but the underlying code could be significantly different.
I actually don't quite understand this one. As far as I am aware there are two issues that might be claimed with one being copyright infringement in the case of code theft and the other being patent infringement if a company runs afoul of a patented feature regardless of whether the code itself is original. Code theft could be either a case of downloading company property to personal devices or hacking it via a disassembler, which granted can be useful for trying to figure out the encoding of pesky digital camera raw formats. In the case of disassembly, which isn't exact, it could still be regarded as code theft even though the rewritten version would not necessarily match the original. Beyond that Objective-C was different in a lot of ways from either C++ or C, even though it's a strict superset of C. The typical methods and common data types are different. I'm curious how something could be code theft there yet not here.
I read whole article. Very well explained. Thanks to Chris Lattner who developed new programming LLVM(low level virtual machine) language which is based on objective C language. We are excited about your offer “course on developing swift “. Thanks for article.
I read whole article. Very well explained. Thanks to Chris Lattner who developed new programming LLVM(low level virtual machine) language which is based on objective C language. We are excited about your offer “course on developing swift “. Thanks for article.
Comments
Nonsense! Speed depends on optimizations that exist in the compiler (and even linker, etc) and the ability of the language to expose code and data to optimization. The more guarantees you have about what your variables are, the more chances you have to optimize with them. The better the language exposes code interdependencies, the more chances the compiler has to optimize them.
See the discussion in the Swift manual (iBooks) on Arrays and Dictionaries and how you can optimize copies away most of the time for constant data. In C, you may have a float array and a separate pointer that points to its 19th element but treats it as char * rather than float[]. It's pretty hard for a compiler to come up with as many safe optimizations in that environment as in Swift. On the other hand, C allows the programmer to do flexible things like treat his array as both types at once, which may lead to better speed than Swift can hope for, but at potentially great risk to reliability and safety.
And Assembly code can be hand-tuned to go faster than C if you know the machine language in detail and are willing to spend hours sweating the details. I've done it. It ain't fun, and is seldom productive unless used in the very, very inmost loops.
What Swift seems to promise is a nice balance of development speed and ease vs execution speed and reliability.
For a very concrete example: C doesn't check that data fits inside the memory allocated for variables; this lack of checking makes it faster when dealing with arrays than other, safer languages. But it also leads to the infamous buffer overflows and vulnerabilities like Heartbleed (though some really bad design helped Heartbeat achieve fame).
Swift does guarantee that data can't overflow its variables. This takes a bit longer, but is vastly safer. Programmers will probably still be able to create buffer overflows, but they'll have to work really hard to do so.
Anyway, it's impossible in most cases to look at a language description and say whether in practice programs written to normal expectations of productivity will necessarily run faster or slower than in other languages when written to similar standards. You have to use the language to find out, and use it on the kind of application you want to write. If Apple's numbers say it's very fast, but not as fast as C form most things, I'll tend to believe them.
Is that possible? Seems like it took years to get to this point and Apple had full control of mature tools.
They appropriated WebKit pretty quickly. Yes, that was freely available, but good ol’ Microsoft was able to reverse engineer before, and if they can do it, Google can!
But WebKit is open source and uses HTML, CSS, and JS standards. Swift is specifically to make Apple's developer spend less time and money to develop apps that will strengthen its platform.
If Google really wanted to copy Apple they wouldn't be using Java and they wouldn't have such a shitty IDE and documentation.
Didn't WebKit turn into a consortium effort after its initial inception by Apple?
Xcode 4:
NSArray *names = [[NSArray alloc] initWithObjects: @"Tom", @"Dick", @"Harry", nil];
Xcode 5:
NSArray *names = @[@"Tom", @"Dick", @"Harry"];
Swift:
let names = ["Tom", "Dick", "Harry"]
Does that mean the end of BLOATWARE?
From what I understand all that code will get compiled the same.
I'm a little surprised no one has mentioned the legal advantages this code switch is going to give Apple. Now, no company will be able to claim code theft or infringement in their software. Swift will enable the creation of code that may perform nearly identical functions, but the underlying code could be significantly different.
I actually don't quite understand this one. As far as I am aware there are two issues that might be claimed with one being copyright infringement in the case of code theft and the other being patent infringement if a company runs afoul of a patented feature regardless of whether the code itself is original. Code theft could be either a case of downloading company property to personal devices or hacking it via a disassembler, which granted can be useful for trying to figure out the encoding of pesky digital camera raw formats
. In the case of disassembly, which isn't exact, it could still be regarded as code theft even though the rewritten version would not necessarily match the original. Beyond that Objective-C was different in a lot of ways from either C++ or C, even though it's a strict superset of C. The typical methods and common data types are different. I'm curious how something could be code theft there yet not here.
I read whole article. Very well explained. Thanks to Chris Lattner who developed new programming LLVM(low level virtual machine) language which is based on objective C language. We are excited about your offer “course on developing swift “. Thanks for article.