If you're not currently programming using Obj-C, this language isn't for you and doesn't affect you. Just as well if you can't differentiate it from C++.
If you do currently program in Obj-C, this language will be very interesting indeed.
Chris Lattner, the guy who developed LLVM and Clang developed this language, starting 4 years ago, and it's since been kicked around by the developer tools team at Apple.
I'm pretty sure those people over 4 years thought it out better than you and the other guy did in a day.
I don't know what the reason for the decision is either, as like everyone else I'm just coming to grips with the language. But for sure there will be a reason. It won't be lack of knowledge or experience of the language designers.
But not only was the death penalty for treason abolished; we're prohibited from restoring the death penalty (for any offence) as long as we're signed up to the European Convention on Human Rights.
Damn those pesky human rights. Maybe we could make like the Americans and set up a torture camp on the Falklands so we don't have to obey our own laws.
No, the death sentence is reserved for politicians and prime ministers who go to war on false pretenses just to get re-elected, resulting in loss of life or threat to the country's national security.
It's safer, faster and more powerful than Obj-C. And yet is completely interoperable with it, including all existing Obj-C APIs. What's not to like.
I made some quick notes whilst I was watching the into video. Copied below. Not saying much if any of this stuff is new, but the combination is, and the ability to mix it with Obj-C. I particularly like optionals, references rather than pointers, the override keyword, typed collections, multiple return values via tuples.
Here's the list:
No header files or need for boilerplate. This is a complete program: println("Hello, world")
Immutabe types need no extra keyword. Which means programmers are more likely to do it.
Identifiers can use unicode. Which is good for foreign programmers, and also means you can use a pi character as the identifier for a pi constant, and similar for other math symbols and other users of specialised symbols.
String interpolation: No need for printf, [NSString stringWithFormat:] or NSLog formatting. let foo = 7 println ("foo is \(foo). foo times 2 is \(foo*2)")
Typed arrays and dictionaries.
Ranges. e.g. for i in 0..5 {} rather than for (int i=0;i5;i++) {}
Extracting both key and value at once when iterating over dictionaries.
Optionals. Every value either explicitly allows a nil value or doesn't. Not just pointers. And nil and zero is not the same thing.
Switch works with any type, not just ints and chars.
No default fallthrough in Switch.
if statements must use braces.
All legal cases must be matched in switches.
Use ranges in cases.
Default parameters for functions.
String concatenation with +.
Tuples.
Closures.
Trailing closures.
No false dichotomy of ivars and properties. Only properties.
Explicit overriding keyword: override.
Enums can be any type, not just ints.
Enums can have associated values.
Extend any type (add data, functions, operators), including types you don't have the code for or built in types.
You just pile more evidence on the conclusion that you are not an app developer and don't know what you're talking about with regard to app development.
You're just adding weight to the conclusion that you are not an app developer. Each platform has it's UI norms and if you don't match them, your app is shit and won't sell.
even a company like Adobe will have really hard time building products for both platforms.
Bad example. Adobe have horrible UIs and are really slow to adapt to changing technology.
As to cross platform work in general, those companies that try to do it with cross platform widget libraries such as Qt and Swing generally have sub-standard UIs, not really fitting in on anything but the primary development OS.
The companies that do cross platform well split out out the non-UI elements into an engine, then implement the UI with the native UI libraries on each OS.
You can program in standard C++ on the iPhone if that's what you want to do. The entry point for an app is the usual C int main(int argc, char * argv[]) {}
You can do what you like from there. Most people start up Cocoa from there and use Obj-C. But you don't have to.
Image processing, simulation and spatialization in particular are domains requiring intensive computing, potentially involving some advanced algorithmics and math, which are much more challenging to engineer than writing glue code for user interaction.
Image processing on iOS and OSX is usually very easy, taking just a few lines, as the built in Core Image framework does most of what you could possibly want. And where it doesn't writing a plugin isn't hard. All those Image processing apps you can get on iOS have certainly spent far more time on UI than engine.
Come to that I wrote a warping app on Symbian OS years ago, where there wasn't any image processing library to help. And I did part of the image processing code in assembler to get the speed I needed. And the UI work was still far greater.
Simulation and spatialization are very specialised domains. Most app work is not like that. And it may well still be the case that UI work is greater than engine work even with those - depending on the specifics.
Designers have the problem that programmers haven't yet come up with a better App for designing custom UIs than Photoshop. And even when using what is supposed to be the same font, Photoshop typography usually isn't per pixel identical to the target OS typography.
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.
Those comments are usually right. The initial question that newbs ask on StackOverflow very often reveals a basic misunderstanding. One often needs to realise what it is they really need to know rather than what they are asking.
No one knows how best to incorporate it into their projects or if doing so with offer them any advantage.
I'm not suggesting many will do that. It's possible to bridge between the two languages, but probably not worth it. What I'm suggesting is that there will be plenty of uptake for new projects.
No one even knows if Apple will continue to support the language if it doesn't gain significant traction over the next few years.
And so enterprise programmers who need to write justifications for upper management will continue to use the old technology till the new tech is mainstream. As usual. However the bulk of influential OSX and iOS developers are not that. They are small businesses and indies, that can adopt new technologies quickly and don't have to justify their actions to managers who don't know much about the issues. They will realise that this is a significant improvement over Obj-C in many ways, and so will be adopted.
Do you want to make a just for fun wager that two years from now, Swift will have widespread adoption amongst iOS and OSX developers? I say it will.
That behavior is desirable for when a fallthrough case is ideal
How many times do I have to repeat that my problem is with fallthrough BY DEFAULT. That is never a good idea. If wanted at all (and there is never a true need for it) then that should be the exceptional case, with extra syntax to do it.
it's hardly a massive deal
It's an example. One that's real and causes bugs every day. And one that is inarguably bad language design.
There are plenty of other things wrong with C.
And if so why aren't you configuring your compiler to pick up on it?
And then when you *DO* want to fall through? There needs to be some kind of compiler specific extension in the code to suppress the warning you turned on. How much proof do you need that the language is flawed, than that you need to turn on warnings against legal syntax and introduce non-standard code constructs to overcome it?
"Why are some people so attached to a language that they can't admit it's deficiencies?" I don't know, if they do exist then ask them instead of projecting your perceptions of such people onto me.
Still waiting for your admission that C's switch statement fall through by default is a deficiency...
Your inclination is by the by. You've been told by several developers here how it works. Your disinclination to believe them makes no odds to the fact that they are right.
I simply gave it as an indefensible example of a bad design choice in C. And yes it's pretty bad in that it's bee a significant cause of bugs in C. Not the worst in C by any means, but one of the least defensible.
But I underestimated Slashdot. The number of people willing to defend the indefensible is surprising. It is NEVER desirable. There is no circumstance in which it is better than a list of values per case, plus a fallthrough statement for those incredibly rare cases where a true fall-through is wanted.
Why are some people so attached to a language that they can't admit it's deficiencies?
Slashdot Mirror
If you're not currently programming using Obj-C, this language isn't for you and doesn't affect you. Just as well if you can't differentiate it from C++.
If you do currently program in Obj-C, this language will be very interesting indeed.
In the mean time, this is a more modern and shorter version of your Obj-C code.
num = @(num.intValue+1);
It's not "the baggage of C" when there is no need to use those UNLESS you are interoperating with C.
Design isn't how it looks, design is how it works.
Chris Lattner, the guy who developed LLVM and Clang developed this language, starting 4 years ago, and it's since been kicked around by the developer tools team at Apple.
I'm pretty sure those people over 4 years thought it out better than you and the other guy did in a day.
I don't know what the reason for the decision is either, as like everyone else I'm just coming to grips with the language. But for sure there will be a reason. It won't be lack of knowledge or experience of the language designers.
But not only was the death penalty for treason abolished; we're prohibited from restoring the death penalty (for any offence) as long as we're signed up to the European Convention on Human Rights.
Damn those pesky human rights. Maybe we could make like the Americans and set up a torture camp on the Falklands so we don't have to obey our own laws.
No, the death sentence is reserved for politicians and prime ministers who go to war on false pretenses just to get re-elected, resulting in loss of life or threat to the country's national security.
So that's Blair and Thatcher then.
It's safer, faster and more powerful than Obj-C. And yet is completely interoperable with it, including all existing Obj-C APIs. What's not to like.
I made some quick notes whilst I was watching the into video. Copied below. Not saying much if any of this stuff is new, but the combination is, and the ability to mix it with Obj-C. I particularly like optionals, references rather than pointers, the override keyword, typed collections, multiple return values via tuples.
Here's the list:
No header files or need for boilerplate. This is a complete program:
println("Hello, world")
Immutabe types need no extra keyword. Which means programmers are more likely to do it.
Identifiers can use unicode. Which is good for foreign programmers, and also means you can use a pi character as the identifier for a pi constant, and similar for other math symbols and other users of specialised symbols.
String interpolation: No need for printf, [NSString stringWithFormat:] or NSLog formatting.
let foo = 7
println ("foo is \(foo). foo times 2 is \(foo*2)")
Typed arrays and dictionaries.
Ranges. e.g. for i in 0..5 {} rather than for (int i=0;i5;i++) {}
Extracting both key and value at once when iterating over dictionaries.
Optionals. Every value either explicitly allows a nil value or doesn't. Not just pointers. And nil and zero is not the same thing.
Switch works with any type, not just ints and chars.
No default fallthrough in Switch.
if statements must use braces.
All legal cases must be matched in switches.
Use ranges in cases.
Default parameters for functions.
String concatenation with +.
Tuples.
Closures.
Trailing closures.
No false dichotomy of ivars and properties. Only properties.
Explicit overriding keyword: override.
Enums can be any type, not just ints.
Enums can have associated values.
Extend any type (add data, functions, operators), including types you don't have the code for or built in types.
Generics.
You just pile more evidence on the conclusion that you are not an app developer and don't know what you're talking about with regard to app development.
"Apple apologists"? I think we've got your number now. Thanks for playing.
You're just adding weight to the conclusion that you are not an app developer. Each platform has it's UI norms and if you don't match them, your app is shit and won't sell.
even a company like Adobe will have really hard time building products for both platforms.
Bad example. Adobe have horrible UIs and are really slow to adapt to changing technology.
As to cross platform work in general, those companies that try to do it with cross platform widget libraries such as Qt and Swing generally have sub-standard UIs, not really fitting in on anything but the primary development OS.
The companies that do cross platform well split out out the non-UI elements into an engine, then implement the UI with the native UI libraries on each OS.
If the applications don't follow the OS norms, they are not fine applications.
You can program in standard C++ on the iPhone if that's what you want to do. The entry point for an app is the usual C int main(int argc, char * argv[]) {}
You can do what you like from there. Most people start up Cocoa from there and use Obj-C. But you don't have to.
Image processing, simulation and spatialization in particular are domains requiring intensive computing, potentially involving some advanced algorithmics and math, which are much more challenging to engineer than writing glue code for user interaction.
Image processing on iOS and OSX is usually very easy, taking just a few lines, as the built in Core Image framework does most of what you could possibly want. And where it doesn't writing a plugin isn't hard. All those Image processing apps you can get on iOS have certainly spent far more time on UI than engine.
Come to that I wrote a warping app on Symbian OS years ago, where there wasn't any image processing library to help. And I did part of the image processing code in assembler to get the speed I needed. And the UI work was still far greater.
Simulation and spatialization are very specialised domains. Most app work is not like that. And it may well still be the case that UI work is greater than engine work even with those - depending on the specifics.
Designers have the problem that programmers haven't yet come up with a better App for designing custom UIs than Photoshop. And even when using what is supposed to be the same font, Photoshop typography usually isn't per pixel identical to the target OS typography.
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.
Those comments are usually right. The initial question that newbs ask on StackOverflow very often reveals a basic misunderstanding. One often needs to realise what it is they really need to know rather than what they are asking.
No one knows how best to incorporate it into their projects or if doing so with offer them any advantage.
I'm not suggesting many will do that. It's possible to bridge between the two languages, but probably not worth it. What I'm suggesting is that there will be plenty of uptake for new projects.
No one even knows if Apple will continue to support the language if it doesn't gain significant traction over the next few years.
And so enterprise programmers who need to write justifications for upper management will continue to use the old technology till the new tech is mainstream. As usual. However the bulk of influential OSX and iOS developers are not that. They are small businesses and indies, that can adopt new technologies quickly and don't have to justify their actions to managers who don't know much about the issues. They will realise that this is a significant improvement over Obj-C in many ways, and so will be adopted.
Do you want to make a just for fun wager that two years from now, Swift will have widespread adoption amongst iOS and OSX developers? I say it will.
It's not stupid when it's a fact that they don't.
What's stupid is believing things you have no evidence for.
The last time Jailbreakme worked was 3 years ago. iOS 4.something. We're on iOS 7.1 now.
I believe power tool manufacturers used the same excuse for cutting corners on safety guards.
That behavior is desirable for when a fallthrough case is ideal
How many times do I have to repeat that my problem is with fallthrough BY DEFAULT. That is never a good idea. If wanted at all (and there is never a true need for it) then that should be the exceptional case, with extra syntax to do it.
it's hardly a massive deal
It's an example. One that's real and causes bugs every day. And one that is inarguably bad language design.
There are plenty of other things wrong with C.
And if so why aren't you configuring your compiler to pick up on it?
And then when you *DO* want to fall through? There needs to be some kind of compiler specific extension in the code to suppress the warning you turned on. How much proof do you need that the language is flawed, than that you need to turn on warnings against legal syntax and introduce non-standard code constructs to overcome it?
"Why are some people so attached to a language that they can't admit it's deficiencies?"
I don't know, if they do exist then ask them instead of projecting your perceptions of such people onto me.
Still waiting for your admission that C's switch statement fall through by default is a deficiency...
Otherwise, if the cap fits, wear it.
Welcome to Moore's law. CPU power increases exponentially, and software uses that extra power. This is not an iOS peculiarity.
Your inclination is by the by. You've been told by several developers here how it works. Your disinclination to believe them makes no odds to the fact that they are right.
I simply gave it as an indefensible example of a bad design choice in C. And yes it's pretty bad in that it's bee a significant cause of bugs in C. Not the worst in C by any means, but one of the least defensible.
But I underestimated Slashdot. The number of people willing to defend the indefensible is surprising. It is NEVER desirable. There is no circumstance in which it is better than a list of values per case, plus a fallthrough statement for those incredibly rare cases where a true fall-through is wanted.
Why are some people so attached to a language that they can't admit it's deficiencies?