Ok you have been working with Swift for 24 hours. Lattner has been working with it since 2010 and working on the building blocks for 15 years. He also probably has an IQ of 200. He says it can replace Obj-C and by extension most likely C, C++, C#. He has a whole team of geniuses working together on this. I'd take his word over anyone else especially someone who has only one day under their belt.
Lattner knows jack squat about ObjC [he's admitted consistently on the LLVM/Clang threads. He also knows squat about Clang and how it's put together, though he's well-versed in C++ and knows C. His expertise and thesis is centered around architecture and implementations of Compilers, and LLVM is a product of it.
Someone he would have relied heavily on are the likes of Federighi, Forstall, Peter Graffagnino, several Cocoa experts at Apple, outside language experts like Aaron Hillegass, and several others working intimately on Clang. His addition of blocks and ARC for a replacement of Object Retain/Release wasn't a solo project. There is a specific leadership at Apple with decades more experience than Chris.
In light of the contextual interpretation, I could argue that having all variables be 'optionals' by default would be a more natural and consistent approach.
It could also increase program size and complexity. Optionality also implies nullability, which means that you can use a simple scalar type to box to an object, but have to include flags as well. Personally I don't know if this is a real issue or not, but its the one that leaves bits of crud like this in a number of languages.
The next step (pun intended) would be to allow Swift development on iOS itself. In fact, only Swift development and not C/C++/Objective-C. People can build their sprites in some drawing app, use the app extensions to bring them in to XCode for iOS and run it in real-time. That should make Alan Kay happy.
I would much prefer a different next step, which they kinda sorta have with those interactive debuggers - I'd like to directly link the GUI builder to the code, similar to but better than .net/VB. Ideally I'd like the ease of HyperCard in terms of moving from the GUI to the code that runs it. I think that is a much greater barrier to easy development and THEN you'd be ready for the jump to iOS. I mean, can you imagine storyboards on a iPad? *shudder*.
I want to love Swift, but at this stage I just can't, not in its current state. I've only gotten through about the first 200 pages of the iBook but there are things that, IMO, could/should be more rationalized, particularly some of the syntax. A couple things off the top of my head:
Variables are declared: var foo: Int
That's fair enough, but then 'optionals' are declared: var foo:Int?
That's too little of a difference (ok, I'm used to C's * for pointers and that's only a single character so...). Anyhow, so I want to use my optional, it's easy in a boolean context to determine if it has a value:
if foo {...
but in a scalar context I have to refer to it:
bar = foo!
or decompose it in the boolean context:
if var bar = foo {
// do something with bar
But, that's not all. I could actually declare it:
var foo: Int!
What does that buy me? The ability to refer to it in a scalar context directly:
bar = foo
In the boolean context it's still interpreted as 'does it have a value' thus the context is clearly known in interpreting it. So, why two different ways to specify it and use it?
In light of the contextual interpretation, I could argue that having all variables be 'optionals' by default would be a more natural and consistent approach. The compiler can certainly warn you if you're attempting to use it before assigning it a value and even if you ignore that warning it's a runtime fault to use it if it doesn't have a value. With 'optional' as the default (only?) type, all variables could be used in the exact same way; e.g.
var foo: Int
...
if foo {
// do something with foo
} else {
// foo has no value
}
Second, the inconsistency between:
let array = [a, b, c]
let dictionary = [d : 1, e : 2]
According to the documentation this creates, respectively, an immutable array and dictionary, except the dictionary is truly immutable and arrays are only sort-of immutable.
While the dictionary cannot be changed at all and the array can't change size, the contents of the array can be changed. That's hardly immutable and certainly different from the true immutability of NSArray.
That's probably enough for now for you all to take me to task. :-)
I'd love something more modern than Objective-C, something where everything is an object, say. Or any number of other things, but as it stands, I don't think Swift is it.
what the optionals buy you is safety. With obj C the nil pointers are (unlike other languages) safe to message but not safe to pass to methods which expect a non- nil value. You are right about the strange mutability of the immutable array.
Given that the AppStore launched in 2008, and I'd have to surmise that the vast majority of submissions are from people who never looked at Obj-C before that point, that implies Apple convinced thousands (millions?) of people to pick up Obj-C in the last five years.
So why shouldn't they convince them to switch to something that's supposedly much better? MS did with C#.
Because it's not bedroom developers anymore. Actually adding swift to existing objective C projects shouldn't take that long but because interoperability is perfect only one way it doesn't buy you much, as you can't use new features like tuples in Swift code called from objective C. That said the playground is awesome.
A lot of modern development is based around web programming and the iPhone was originally going to be web apps only. It needed performance and access to graphics frameworks though and C-based languages are the most popular but they are no good for rapid application development and that's what's needed these days. Turnaround times are more important than raw performance for most apps. For the ones that need the performance, they can do it the way they know how. Swift offers both performance and fast turnaround times.
It could even replace Applescript (hopefully).
It would be nice if they'd open source it and make moves for it to compete with C#. If it was in 3rd party SDKs like Unity, they can natively compile apps without XCode and could more easily call iOS system APIs. That might mean people don't bother buying Macs for iOS development, although the simulator would still be Mac-only and wide support and adoption of the language would be beneficial.
I doubt that's the case. A lot of apps are very simple apps, they need to be turned around quickly and deployed to more than iOS. 3rd party SDKs are used a fair bit and many simply use web languages:
The next step (pun intended) would be to allow Swift development on iOS itself. In fact, only Swift development and not C/C++/Objective-C. People can build their sprites in some drawing app, use the app extensions to bring them in to XCode for iOS and run it in real-time. That should make Alan Kay happy.
Trust me. Except for unity no serious app is, at the moment, developed in anything other than objective C. Which is fairly rapid development by the way once you know it well, the learning curve is the framework not the language. I don't think a huge amount of time is actually saved by not typing semi colons or getting type inference if you have to consult the manual to work out how a table view controller works. In fact Swift is harder to master, albeit easier to type, because it has new features. You could ignore the new stuff I suppose but extensions, methods in structures and generics look good. Tuples schmuples.
All of this language learning is no time at all compared to learning the decades old and still accelerating iOS/OS frameworks. I've read the manual and watched the first wwdc video and i think I could port an app in a weekend. Provided it works as advertised.
As for C and Swift. I haven't seen much explanation how to import it yet.
It doesn't have the performance of C or Lattner and Federighi would have put up the sorting and other graphs to show it. It doesn't have the added overhead of ObjC 2.0 [they've put the magic into the compiler] but it sure won't match C11/C99.
The Python comparison was obnoxious.
That doesn't make any sense. 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.
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.
Wrong. Objective-C has runtime overhead that C does not. Swift may have less overhead but it will still have runtime costs that C doesn't. Swift's memory safety, bounds checking, etc. all have runtime costs that C does not share. The generated code would not be the same between C and Swift to have those runtime features.
I want to love Swift, but at this stage I just can't, not in its current state. I've only gotten through about the first 200 pages of the iBook but there are things that, IMO, could/should be more rationalized, particularly some of the syntax. A couple things off the top of my head:
Variables are declared: var foo: Int
That's fair enough, but then 'optionals' are declared: var foo:Int?
That's too little of a difference (ok, I'm used to C's * for pointers and that's only a single character so...). Anyhow, so I want to use my optional, it's easy in a boolean context to determine if it has a value:
if foo {...
but in a scalar context I have to refer to it:
bar = foo!
or decompose it in the boolean context:
if var bar = foo {
// do something with bar
But, that's not all. I could actually declare it:
var foo: Int!
What does that buy me? The ability to refer to it in a scalar context directly:
bar = foo
In the boolean context it's still interpreted as 'does it have a value' thus the context is clearly known in interpreting it. So, why two different ways to specify it and use it?
In light of the contextual interpretation, I could argue that having all variables be 'optionals' by default would be a more natural and consistent approach. The compiler can certainly warn you if you're attempting to use it before assigning it a value and even if you ignore that warning it's a runtime fault to use it if it doesn't have a value. With 'optional' as the default (only?) type, all variables could be used in the exact same way; e.g.
var foo: Int
...
if foo {
// do something with foo
} else {
// foo has no value
}
Second, the inconsistency between:
let array = [a, b, c]
let dictionary = [d : 1, e : 2]
According to the documentation this creates, respectively, an immutable array and dictionary, except the dictionary is truly immutable and arrays are only sort-of immutable.
While the dictionary cannot be changed at all and the array can't change size, the contents of the array can be changed. That's hardly immutable and certainly different from the true immutability of NSArray.
That's probably enough for now for you all to take me to task. :-)
I'd love something more modern than Objective-C, something where everything is an object, say. Or any number of other things, but as it stands, I don't think Swift is it.
How can you have a discussion about optionals without even mentioning if-let? That's the standard method for using them. I would except to see if-let throughout all well-written Swift code. Much more so than forced unwrapping (the ! operator).
Also a major reason for the optional variable addition is to deal with the fact that any and all existing object methods can return nil in place of a real object. if-let gives us a much cleaner, more consistent way to address this.
As to why immutable arrays and immutable dictionaries behavior differently, I'm sure that that's based on excellent feedback from the Apple "dogfooding group" (I love that term) and not someone's carelessness or desire to think different. Also as explained in the documentation having an array that can't change size is a great advantage to the compiler (compared to an array that can be any size and change size). There is no efficiency gain for not allowing elements of an array to change, so why tie the developers hands. Of course they could have introduced fixed-size immutable arrays, fixed-size mutable arrays, and mutable arrays, but that would be added complexity for very, very little gain.
Anyway, I expect that only after use will some of these design decisions become more obvious, but at first blush it appears that they have tried really hard to learn the lessons from other languages while developing a language that's perfectly suited for the massive libraries at the heart of OS X and iOS.
Lattner knows jack squat about ObjC [he's admitted consistently on the LLVM/Clang threads. He also knows squat about Clang and how it's put together, though he's well-versed in C++ and knows C.
Apple must really have their head up their collective ass to make such an incapable moron the Director of the Developer Tools overseeing hundreds of brilliant engineers.
"LLVM not only powers Apple's software, but is also tightly integrated into the development of Apple's custom silicon, including the A6 and A7 Application Processors."
And there we have the proof that Apple with put A chips in their Macs.
That's not proof but it's definitely a powerful point for the next time the rumour crops up.
That guy has an absolutely biased perspective. Microsoft .net = the pinnacle of software development? Silverlight the choice for cross-platform? Bitch, please. Microsoft is fighting to stay relevant outside of enterprise coding.
It must suck to realize that despite how "superior" the Windows Phone 8 development languages and SDK are, all the notable mobile app developers have learned Obj-C (maybe even put up with it) to get published on iOS. It's gotta burn.
He's also not giving Apple any credit for WebKit, and their support for fast JavaScript engines: two web developer technologies that helped kill the clumsy, misguided XHTML spec and bring about the age of HTML5 and modern Web apps. Web apps that have ensured the web remains open and cross platform, not "Best Viewed in IE6".
Apple must really have their head up their collective ass to make such an incapable moron the Director of the Developer Tools overseeing hundreds of brilliant engineers.
I think this is one of the most significant announcements by Apple is recent years. Although C-variants including Obj-C, are powerful in the right hands, they are just 2nd generation languages in the sense that we used to refer to Fortran and Cobol as 3rd generation languages. The syntax is inherently far too complicated for C-based languages to be used efficiently by all but highly trained professional programmers.
From what I have seen from the Swift documentation so far, it is moving away from these unnecessary complications of C-based languages. If this simplicity translates to the use of Swift with the incredibly powerful Cocoa frameworks, then Swift will open the app developer world up to far more people and stimulate the development of far more imaginative apps in the future, regardless of the platform used.
That doesn't make any sense. 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.
And yet Apple themselves showed the swift being faster than objective C in at least two common scenarios on their slides.
I think this is one of the most significant announcements by Apple is recent years. Although C-variants including Obj-C, are powerful in the right hands, they are just 2nd generation languages in the sense that we used to refer to Fortran and Cobol as 3rd generation languages. The syntax is inherently far too complicated for C-based languages to be used efficiently by all but highly trained professional programmers.
From what I have seen from the Swift documentation so far, it is moving away from these unnecessary complications of C-based languages. If this simplicity translates to the use of Swift with the incredibly powerful Cocoa frameworks, then Swift will open the app developer world up to far more people and stimulate the development of far more imaginative apps in the future, regardless of the platform used.
Well done Apple and Chris Lattner!
All general purpose programming languages are equally 'powerful'. Swift is strictly 2nd generation 'plus'. It is C but has borrowed a few features from Haskell. It would be embarrassing if it had not. Apple has sealed its fate by promoting such an old-fashioned 'new' programming language. Let fate take its course....
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.
All general purpose programming languages are equally 'powerful'. Swift is strictly 2nd generation 'plus'. It is C but has borrowed a few features from Haskell. It would be embarrassing if it had not. Apple has sealed its fate by promoting such an old-fashioned 'new' programming language. Let fate take its course....
Rubbish. If it takes a programmer 500 lines of code in language X to do what another programmer can do with 50 lines of code in language Y, then language Y is far more 'powerful' than language X because it costs far less to complete a specific programming task. On top of that it should take far less time to debug and maintain 50 lines of code than 500 lines of code, particularly if there is an interpretive compiler for language Y.
Now how many lines of code do you think a programmer will save by using Swift rather than Objective C? And how much steeper is the learning curve for Objective C than for Swift?
As for 'Apple sealing its fate' - can you name just one company that would not LOVE to share Apple's fate in the future? Microsoft, Google, Samsung ... ?
If this were the case, functional languages would have taken over several decades ago. The average intelligence of the programmer is the limiting factor. Sorry - it is hard to say - but true.
Comments
Ok you have been working with Swift for 24 hours. Lattner has been working with it since 2010 and working on the building blocks for 15 years. He also probably has an IQ of 200. He says it can replace Obj-C and by extension most likely C, C++, C#. He has a whole team of geniuses working together on this. I'd take his word over anyone else especially someone who has only one day under their belt.
Lattner knows jack squat about ObjC [he's admitted consistently on the LLVM/Clang threads. He also knows squat about Clang and how it's put together, though he's well-versed in C++ and knows C. His expertise and thesis is centered around architecture and implementations of Compilers, and LLVM is a product of it.
Someone he would have relied heavily on are the likes of Federighi, Forstall, Peter Graffagnino, several Cocoa experts at Apple, outside language experts like Aaron Hillegass, and several others working intimately on Clang. His addition of blocks and ARC for a replacement of Object Retain/Release wasn't a solo project. There is a specific leadership at Apple with decades more experience than Chris.
For Python fans, I can see quite a bit in there...
http://www.LearnSwift.tips/
Heads up hackers - may be that scripting is supported.
Good link. Thanks.
In light of the contextual interpretation, I could argue that having all variables be 'optionals' by default would be a more natural and consistent approach.
It could also increase program size and complexity. Optionality also implies nullability, which means that you can use a simple scalar type to box to an object, but have to include flags as well. Personally I don't know if this is a real issue or not, but its the one that leaves bits of crud like this in a number of languages.
The next step (pun intended) would be to allow Swift development on iOS itself. In fact, only Swift development and not C/C++/Objective-C. People can build their sprites in some drawing app, use the app extensions to bring them in to XCode for iOS and run it in real-time. That should make Alan Kay happy.
I would much prefer a different next step, which they kinda sorta have with those interactive debuggers - I'd like to directly link the GUI builder to the code, similar to but better than .net/VB. Ideally I'd like the ease of HyperCard in terms of moving from the GUI to the code that runs it. I think that is a much greater barrier to easy development and THEN you'd be ready for the jump to iOS. I mean, can you imagine storyboards on a iPad? *shudder*.
what the optionals buy you is safety. With obj C the nil pointers are (unlike other languages) safe to message but not safe to pass to methods which expect a non- nil value. You are right about the strange mutability of the immutable array.
Because it's not bedroom developers anymore. Actually adding swift to existing objective C projects shouldn't take that long but because interoperability is perfect only one way it doesn't buy you much, as you can't use new features like tuples in Swift code called from objective C. That said the playground is awesome.
Trust me. Except for unity no serious app is, at the moment, developed in anything other than objective C. Which is fairly rapid development by the way once you know it well, the learning curve is the framework not the language. I don't think a huge amount of time is actually saved by not typing semi colons or getting type inference if you have to consult the manual to work out how a table view controller works. In fact Swift is harder to master, albeit easier to type, because it has new features. You could ignore the new stuff I suppose but extensions, methods in structures and generics look good. Tuples schmuples.
All of this language learning is no time at all compared to learning the decades old and still accelerating iOS/OS frameworks. I've read the manual and watched the first wwdc video and i think I could port an app in a weekend. Provided it works as advertised.
As for C and Swift. I haven't seen much explanation how to import it yet.
It doesn't have the performance of C or Lattner and Federighi would have put up the sorting and other graphs to show it. It doesn't have the added overhead of ObjC 2.0 [they've put the magic into the compiler] but it sure won't match C11/C99.
The Python comparison was obnoxious.
That doesn't make any sense. 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.
Wrong. Objective-C has runtime overhead that C does not. Swift may have less overhead but it will still have runtime costs that C doesn't. Swift's memory safety, bounds checking, etc. all have runtime costs that C does not share. The generated code would not be the same between C and Swift to have those runtime features.
I want to love Swift, but at this stage I just can't, not in its current state. I've only gotten through about the first 200 pages of the iBook but there are things that, IMO, could/should be more rationalized, particularly some of the syntax. A couple things off the top of my head:
Variables are declared: var foo: Int
That's fair enough, but then 'optionals' are declared: var foo:Int?
That's too little of a difference (ok, I'm used to C's * for pointers and that's only a single character so...). Anyhow, so I want to use my optional, it's easy in a boolean context to determine if it has a value:
if foo {...
but in a scalar context I have to refer to it:
bar = foo!
or decompose it in the boolean context:
if var bar = foo {
// do something with bar
But, that's not all. I could actually declare it:
var foo: Int!
What does that buy me? The ability to refer to it in a scalar context directly:
bar = foo
In the boolean context it's still interpreted as 'does it have a value' thus the context is clearly known in interpreting it. So, why two different ways to specify it and use it?
In light of the contextual interpretation, I could argue that having all variables be 'optionals' by default would be a more natural and consistent approach. The compiler can certainly warn you if you're attempting to use it before assigning it a value and even if you ignore that warning it's a runtime fault to use it if it doesn't have a value. With 'optional' as the default (only?) type, all variables could be used in the exact same way; e.g.
var foo: Int
...
if foo {
// do something with foo
} else {
// foo has no value
}
Second, the inconsistency between:
let array = [a, b, c]
let dictionary = [d : 1, e : 2]
According to the documentation this creates, respectively, an immutable array and dictionary, except the dictionary is truly immutable and arrays are only sort-of immutable.
While the dictionary cannot be changed at all and the array can't change size, the contents of the array can be changed. That's hardly immutable and certainly different from the true immutability of NSArray.
That's probably enough for now for you all to take me to task. :-)
I'd love something more modern than Objective-C, something where everything is an object, say. Or any number of other things, but as it stands, I don't think Swift is it.
How can you have a discussion about optionals without even mentioning if-let? That's the standard method for using them. I would except to see if-let throughout all well-written Swift code. Much more so than forced unwrapping (the ! operator).
Also a major reason for the optional variable addition is to deal with the fact that any and all existing object methods can return nil in place of a real object. if-let gives us a much cleaner, more consistent way to address this.
As to why immutable arrays and immutable dictionaries behavior differently, I'm sure that that's based on excellent feedback from the Apple "dogfooding group" (I love that term) and not someone's carelessness or desire to think different. Also as explained in the documentation having an array that can't change size is a great advantage to the compiler (compared to an array that can be any size and change size). There is no efficiency gain for not allowing elements of an array to change, so why tie the developers hands. Of course they could have introduced fixed-size immutable arrays, fixed-size mutable arrays, and mutable arrays, but that would be added complexity for very, very little gain.
Anyway, I expect that only after use will some of these design decisions become more obvious, but at first blush it appears that they have tried really hard to learn the lessons from other languages while developing a language that's perfectly suited for the massive libraries at the heart of OS X and iOS.
Apple must really have their head up their collective ass to make such an incapable moron the Director of the Developer Tools overseeing hundreds of brilliant engineers.
That's not proof but it's definitely a powerful point for the next time the rumour crops up.
That guy has an absolutely biased perspective. Microsoft .net = the pinnacle of software development? Silverlight the choice for cross-platform? Bitch, please. Microsoft is fighting to stay relevant outside of enterprise coding.
It must suck to realize that despite how "superior" the Windows Phone 8 development languages and SDK are, all the notable mobile app developers have learned Obj-C (maybe even put up with it) to get published on iOS. It's gotta burn.
He's also not giving Apple any credit for WebKit, and their support for fast JavaScript engines: two web developer technologies that helped kill the clumsy, misguided XHTML spec and bring about the age of HTML5 and modern Web apps. Web apps that have ensured the web remains open and cross platform, not "Best Viewed in IE6".
Did you forget the /s?
From what I have seen from the Swift documentation so far, it is moving away from these unnecessary complications of C-based languages. If this simplicity translates to the use of Swift with the incredibly powerful Cocoa frameworks, then Swift will open the app developer world up to far more people and stimulate the development of far more imaginative apps in the future, regardless of the platform used.
Well done Apple and Chris Lattner!
And yet Apple themselves showed the swift being faster than objective C in at least two common scenarios on their slides.
How could it be?
I think this is one of the most significant announcements by Apple is recent years. Although C-variants including Obj-C, are powerful in the right hands, they are just 2nd generation languages in the sense that we used to refer to Fortran and Cobol as 3rd generation languages. The syntax is inherently far too complicated for C-based languages to be used efficiently by all but highly trained professional programmers.
From what I have seen from the Swift documentation so far, it is moving away from these unnecessary complications of C-based languages. If this simplicity translates to the use of Swift with the incredibly powerful Cocoa frameworks, then Swift will open the app developer world up to far more people and stimulate the development of far more imaginative apps in the future, regardless of the platform used.
Well done Apple and Chris Lattner!
All general purpose programming languages are equally 'powerful'. Swift is strictly 2nd generation 'plus'. It is C but has borrowed a few features from Haskell. It would be embarrassing if it had not. Apple has sealed its fate by promoting such an old-fashioned 'new' programming language. Let fate take its course....
All general purpose programming languages are equally 'powerful'. Swift is strictly 2nd generation 'plus'. It is C but has borrowed a few features from Haskell. It would be embarrassing if it had not. Apple has sealed its fate by promoting such an old-fashioned 'new' programming language. Let fate take its course....
Rubbish. If it takes a programmer 500 lines of code in language X to do what another programmer can do with 50 lines of code in language Y, then language Y is far more 'powerful' than language X because it costs far less to complete a specific programming task. On top of that it should take far less time to debug and maintain 50 lines of code than 500 lines of code, particularly if there is an interpretive compiler for language Y.
Now how many lines of code do you think a programmer will save by using Swift rather than Objective C? And how much steeper is the learning curve for Objective C than for Swift?
As for 'Apple sealing its fate' - can you name just one company that would not LOVE to share Apple's fate in the future? Microsoft, Google, Samsung ... ?
If this were the case, functional languages would have taken over several decades ago. The average intelligence of the programmer is the limiting factor. Sorry - it is hard to say - but true.