As someone with very limited training in visual basic from my school days plus a brain-full of creative ideas at least as cool as flappy-bird balanced by the full understanding that an app may be a passion project with zero return on investment, how would you suggest I get started on building my first app?
As someone with very limited training in visual basic from my school days plus a brain-full of creative ideas at least as cool as flappy-bird balanced by the full understanding that an app may be a passion project with zero return on investment, how would you suggest I get started on building my first app?
So I wonder then if Apple is developing anything using Swift.
You are impatient as usual. Consider that just a few months ago, its compiler still had major bugs. They would require stability to build anything of that scope from it, and it was probably not stable when they began writing the photos app. I plan to try it. I'm still looking for a "good" way to call C++ from it, mostly because it could be re-purposed to run on Android as well. The language itself also has a lot in the way of stable math libraries.
JavaCowboy: Swift does have union types in the way enums. For example, an enum can have error codes and an associated value for results. Even the Wikipedia link you sent mentions this.
So I wonder then if Apple is developing anything using Swift.
You are impatient as usual. Consider that just a few months ago, its compiler still had major bugs. They would require stability to build anything of that scope from it, and it was probably not stable when they began writing the photos app. I plan to try it. I'm still looking for a "good" way to call C++ from it, mostly because it could be re-purposed to run on Android as well. The language itself also has a lot in the way of stable math libraries.
It saddens me that you [are forced to] use HTML & JavaScript to realize 90% of your cross-platform needs ... I suspect that it is used, mostly for UI -- and leads you to address the LCD of features of Android and iOS.
My long-term assessment is that Swift is bigger than Apple -- and, within several years, will go the way of Darwin and WebKit.
With Cordova one cannot say I am forced to a LCD of Android and iOS. Cordova has some neat plugins (written in ObjectiveC and Java) to accomplish much more than the LCD. Example: a sharing plugin uses the native sharing mechanism of iOS (with Airdrop) and the native sharing interface on Android.
I would love to see Swift becoming universal, but this means Apple will need to open its specification, will avoid linking the language with the iOS and OSX APIs and avoid using any patent in the technology, which is of course not a given fact. Both Webkit and Darwin are based on open source projects, so there Apple was not entirely free in its choices
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.
With Cordova one cannot say I am forced to a LCD of Android and iOS. Cordova has some neat plugins (written in ObjectiveC and Java) to accomplish much more than the LCD. Example: a sharing plugin uses the native sharing mechanism of iOS (with Airdrop) and the native sharing interface on Android.
I would love to see Swift becoming universal, but this means Apple will need to open its specification, will avoid linking the language with the iOS and OSX APIs and avoid using any patent in the technology, which is of course not a given fact. Both Webkit and Darwin are based on open source projects, so there Apple was not entirely free in its choices
How efficient is code that will work for both Obj-C and Java (Dalvik)?
Let me ask you a question. Can I do this with Swift enums (as it's not clear from the Swift language guide):
enum StringOrInteger
case String
case Integer
Do I need to define my own case classes within the enum, or can I wrap an enum around everything?
What I'm really asking is can I do the equivalent of String|Integer easily in Swift via an enum.
And, again, String|Integer is a contrived example. I'm asking about doing this for any classes otherwise unrelated in the class hierarchy?
Yes, Swift indeed has Union types. You can quite easily do this with enums in Swift! Consider you are building an App that searches the internet but because your code is asynchronous you need to keep track of when the search produced some results, no results were returned, it is in the middle of loading, or you haven't searched for anything yet. Also, when you have got search results, you want to access them. You would define an enum like so:
enum State {
case NotSearchedYet
case Loading
case NoResults
case Results([SearchResult])
}
Here you can access the results directly of there are any. In this case the enum doesn't have a type (e.g. Int.) But you could have added that if made sense.
How efficient is code that will work for both Obj-C and Java (Dalvik)?
That depends on the quality of the compiler. I don't see a technical reason why Java could not be compiled for iOS runtime or Swift not for the Dalvik runtime, if it were allowed by Apple or Google.
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.
Since there hasn't been any major theoretical advance in the last few years, it was not appropriate to release a whole new language.
They needed improvements to Objective-C. Perhaps they could have just made an Objective-C 3.0 with automatic memory handling and remove parts that lead to common errors and make headers optional. It looks like interactive code is possible with Objective-C:
The Swift beta didn't even have access modifiers (public, private, static). Microsoft only open-sourced C# last year so Apple couldn't have adopted it when they started developing Swift:
Chris Lattner worked on Objective-C so he must have decided starting over was the better route to go. The following page is about a company's assessment of bugs in their shipped software over 3 years and determined 40% of them would have been prevented by Swift:
"Silent failures due to nil-messaging
Improperly handled NSErrors, or other Objective-C error failures
Bad object typecasts
Wrong enum lookup tables being used for values"
"let me talk about one specific bug with nil messaging that cost us a lot of money... it turned out that under certain very rare circumstances a nil value ended up being passed in to these movement methods (due to premature invalidation of a coordinate object). In our robots, the lowest point on the Z axis is 0, with Z values increasing as the Z axis moves up. Now, what happens when you query the integer value of a property by sending a message to a nil object? You get back 0. So, when this nil object was passed into our movement methods, our robots would promptly drive their print heads clean into the deck of the positioning system, smashing them. The one bug maybe cost us $10k total in replacement hardware and other support expenses over all the times it triggered in the field.
Of all the new language features, optionals in Swift seem to be the most complained-about among the Objective-C developers I know. However, I believe that the safety they introduce against really nasty bugs far outweighs any inconvenience when writing code."
So Swift helps with premature invalidation (consult your developer if effects last more than 4 hours) and in their case would have saved money.
Performance is going to be a problem just now because it's only been out for such a short time - comparing 30+ years of stable Objective-C tools vs 5 months for Swift. There's a thread here about C# performance vs C++:
That was 6 years after the language was released and some of the tests showed tens of thousands of times difference. It takes time to figure out the best practises and how to get the best performance. They can optimize the compilers over time too.
What they couldn't have done was stick with Objective-C as it was. They could have modified it, they could have picked an established modern language like C# but with Swift they have full control. C# would have been nice as it has an established developer base and would then be completely cross-platform (minus proprietary APIs). Swift syntax is a bit cleaner but they could have hit the ground running if it had been available to them:
I don't like that there are so many languages that do the same thing. Like spoken languages they each have their own expressiveness but progress is faster with fewer languages. Given the amount of critical bugs that have arisen through trivial errors, the existing languages needed improvement. I think it would be good if Swift and C# converged and stayed open source but it's probably unlikely. Apple having full control has its benefits at the expense of being cross-platform.
I suspect Apple will provide an update at WWDC about what's happened over the year with Swift. I doubt they'd go into Swift 2.0 so quickly but there could be a point release that fixes a lot of the performance and stability problems. Given that Objective-C can be mixed in so easily, there's no problem with it at all as far as Objective-C developers are concerned. Add as much or little C or Objective-C that gets the job done best.
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.
I agree ...
Consider:
Chris Lattner was, purportedly, hired by Apple to update its compiler and runtime (LLVM) and then debugger (LLDB). Later he became responsible for Xcode and all Developer tools (I assume this was because of his proven accomplishments, above).
So, at that point, Apple [mostly] owned the complete stack:
the language - Obj-C
the memory management
the underlying APIs and Frameworks
the GUI constructs NIB/XIBs and Storyboards.
the IDE
the compiler
the debugger
the runtime
the performance tools
the testing tools
the target hardware and infrastructure
Over the years Obj-C, had has had it's share of updates and new features -- Garbage Collection, then ARC to name two.
As I understand, Lattner was given the mission (or took it on himself) to gently bring Obj-C, that venerable veteran, into the 21st century -- to better compete with more modern languages and attract aspiring developers -- while preserving the huge investment in the existing Obj-C codebase.
Again, as I understand it, at some point it became evident to Lattner that dropping in a supercharger, a bigger engine or a stick shift would fix some of the Language issues -- but would ripple through the entire stack, with mostly negative effects ... that upgraded car needs better brakes, safety features, road tests, etc.
At some point, I suspect, Lattner put palm to forehead and said to himself: "It's not just the Language, stupid -- it's the whole stack".
From his perspective, it was obvious that the Language could/should be aware of the compiler and vice versa -- and both could/should capitalize on that knowledge ... Same applies all up and down the stack.
Lattner had demonstrated he could make Obj-C, the Language, compiler/runtime agnostic -- but could he make it compiler/runtime aware and vice versa ... Same applies to the entire stack.
Apparently, the answer is no or not easily.
... Enter Swift ...
Admittedly, long winded with some big assumptions ... But what I think Lattner is doing is rethinking and reimplement ing the entire stack ... Swift, the Language, is an integral, but small part of that.
If my hypothesis is correct ...
There may not be justification for a new Language, by itself -- but it's what it can bring to the entire stack
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.
Objective-C was showing it's age and many of the recent improvements added to it were more or less "bolted on". There were also some core assumptions built in, as well as a lack of support for "native" number and string types, that more or less prevented any further improvement without breaking existing software and code.
To go with your car analogy, there may not have been "quantum" advances in automotive technology over the last 30 years (OC was created in early 1980's), but at some point you're spending a lot of time and money and effort simply trying to keep the old beater on the road.
How efficient is code that will work for both Obj-C and Java (Dalvik)?
That depends on the quality of the compiler. I don't see a technical reason why Java could not be compiled for iOS runtime or Swift not for the Dalvik runtime, if it were allowed by Apple or Google.
I think there's more to it than just the quality of the compiler.
If the language has knowledge of the compiler, debugger, runtime, tools (the underlying stack) -- it can include directives to them to generate faster, safer, more efficient code ...
Apple controls the underlying stack, and with Swift, controls the Language -- so it better optimize the whole process and the resulting product.
A developer friend told me that Swift is not quite ready for production development, it slows down development. There is a price to pay for being on the bleeding edge, one more easily absorbed by some of the big names in this article rather than indy developers who don't need more overhead.
Good point. 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.
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.
Also, as to Marketing Fluff -- I don't consider Chris Lattner a marketeer -- Not only did he create Swift, but he was responsible for Apple's implementation of LLVM ... He has come credentials.
I'll grant you that Lattner is worthy of a lot of credit and he personally has made very few claims regarding swift, choosing to keep his comments technical. But I feel his primary goal (originally) was to make a "safe language", rather than an objective-c replacement...
Comments
This:
https://itunes.apple.com/us/course/developing-ios-8-apps-swift/id961180099
Was the photos app developed using any Swift?
So I wonder then if Apple is developing anything using Swift.
You are impatient as usual. Consider that just a few months ago, its compiler still had major bugs. They would require stability to build anything of that scope from it, and it was probably not stable when they began writing the photos app. I plan to try it. I'm still looking for a "good" way to call C++ from it, mostly because it could be re-purposed to run on Android as well. The language itself also has a lot in the way of stable math libraries.
This:
https://itunes.apple.com/us/course/developing-ios-8-apps-swift/id961180099
I actually plan to watch that. Their lectures are good, even if they do go a bit slow.
Swift does have union types in the way enums. For example, an enum can have error codes and an associated value for results. Even the Wikipedia link you sent mentions this.
This one is different ...
I've taken hundreds hours of Computer-related programming courses since 1956 -- And even taught a few myself!!
This is the best instructor and style I've seen!
It saddens me that you [are forced to] use HTML & JavaScript to realize 90% of your cross-platform needs ... I suspect that it is used, mostly for UI -- and leads you to address the LCD of features of Android and iOS.
My long-term assessment is that Swift is bigger than Apple -- and, within several years, will go the way of Darwin and WebKit.
With Cordova one cannot say I am forced to a LCD of Android and iOS. Cordova has some neat plugins (written in ObjectiveC and Java) to accomplish much more than the LCD. Example: a sharing plugin uses the native sharing mechanism of iOS (with Airdrop) and the native sharing interface on Android.
I would love to see Swift becoming universal, but this means Apple will need to open its specification, will avoid linking the language with the iOS and OSX APIs and avoid using any patent in the technology, which is of course not a given fact. Both Webkit and Darwin are based on open source projects, so there Apple was not entirely free in its choices
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.
How efficient is code that will work for both Obj-C and Java (Dalvik)?
Let me ask you a question. Can I do this with Swift enums (as it's not clear from the Swift language guide):
enum StringOrInteger
case String
case Integer
Do I need to define my own case classes within the enum, or can I wrap an enum around everything?
What I'm really asking is can I do the equivalent of String|Integer easily in Swift via an enum.
And, again, String|Integer is a contrived example. I'm asking about doing this for any classes otherwise unrelated in the class hierarchy?
Yes, Swift indeed has Union types. You can quite easily do this with enums in Swift! Consider you are building an App that searches the internet but because your code is asynchronous you need to keep track of when the search produced some results, no results were returned, it is in the middle of loading, or you haven't searched for anything yet. Also, when you have got search results, you want to access them. You would define an enum like so:
enum State {
case NotSearchedYet
case Loading
case NoResults
case Results([SearchResult])
}
Here you can access the results directly of there are any. In this case the enum doesn't have a type (e.g. Int.) But you could have added that if made sense.
How efficient is code that will work for both Obj-C and Java (Dalvik)?
That depends on the quality of the compiler. I don't see a technical reason why Java could not be compiled for iOS runtime or Swift not for the Dalvik runtime, if it were allowed by Apple or Google.
Agreed.
He should be excellent. Paul is a fellow NeXT alum. He's been immersed with ObjC for over 25 years.
They needed improvements to Objective-C. Perhaps they could have just made an Objective-C 3.0 with automatic memory handling and remove parts that lead to common errors and make headers optional. It looks like interactive code is possible with Objective-C:
http://www.merowing.info/2014/10/playgrounds-for-objective-c/
Microsoft's C# came out in 2002 but didn't add a lot of features until years later:
http://csharpindepth.com/articles/chapter1/versions.aspx
The Swift beta didn't even have access modifiers (public, private, static). Microsoft only open-sourced C# last year so Apple couldn't have adopted it when they started developing Swift:
http://news.microsoft.com/2014/11/12/microsoft-takes-net-open-source-and-cross-platform-adds-new-development-capabilities-with-visual-studio-2015-net-2015-and-visual-studio-online/
Chris Lattner worked on Objective-C so he must have decided starting over was the better route to go. The following page is about a company's assessment of bugs in their shipped software over 3 years and determined 40% of them would have been prevented by Swift:
http://www.sunsetlakesoftware.com/2014/12/02/why-were-rewriting-our-robotics-software-swift
"Silent failures due to nil-messaging
Improperly handled NSErrors, or other Objective-C error failures
Bad object typecasts
Wrong enum lookup tables being used for values"
"let me talk about one specific bug with nil messaging that cost us a lot of money... it turned out that under certain very rare circumstances a nil value ended up being passed in to these movement methods (due to premature invalidation of a coordinate object). In our robots, the lowest point on the Z axis is 0, with Z values increasing as the Z axis moves up. Now, what happens when you query the integer value of a property by sending a message to a nil object? You get back 0. So, when this nil object was passed into our movement methods, our robots would promptly drive their print heads clean into the deck of the positioning system, smashing them. The one bug maybe cost us $10k total in replacement hardware and other support expenses over all the times it triggered in the field.
Of all the new language features, optionals in Swift seem to be the most complained-about among the Objective-C developers I know. However, I believe that the safety they introduce against really nasty bugs far outweighs any inconvenience when writing code."
So Swift helps with premature invalidation (consult your developer if effects last more than 4 hours) and in their case would have saved money.
Performance is going to be a problem just now because it's only been out for such a short time - comparing 30+ years of stable Objective-C tools vs 5 months for Swift. There's a thread here about C# performance vs C++:
https://social.msdn.microsoft.com/Forums/en-US/0990061a-0618-495f-81da-48badf4db2fb/c-array-vs-c-array-speed-difference?forum=csharplanguage
That was 6 years after the language was released and some of the tests showed tens of thousands of times difference. It takes time to figure out the best practises and how to get the best performance. They can optimize the compilers over time too.
What they couldn't have done was stick with Objective-C as it was. They could have modified it, they could have picked an established modern language like C# but with Swift they have full control. C# would have been nice as it has an established developer base and would then be completely cross-platform (minus proprietary APIs). Swift syntax is a bit cleaner but they could have hit the ground running if it had been available to them:
http://swiftcomparsion.qiniudn.com
I don't like that there are so many languages that do the same thing. Like spoken languages they each have their own expressiveness but progress is faster with fewer languages. Given the amount of critical bugs that have arisen through trivial errors, the existing languages needed improvement. I think it would be good if Swift and C# converged and stayed open source but it's probably unlikely. Apple having full control has its benefits at the expense of being cross-platform.
I suspect Apple will provide an update at WWDC about what's happened over the year with Swift. I doubt they'd go into Swift 2.0 so quickly but there could be a point release that fixes a lot of the performance and stability problems. Given that Objective-C can be mixed in so easily, there's no problem with it at all as far as Objective-C developers are concerned. Add as much or little C or Objective-C that gets the job done best.
I agree ...
Consider:
Chris Lattner was, purportedly, hired by Apple to update its compiler and runtime (LLVM) and then debugger (LLDB). Later he became responsible for Xcode and all Developer tools (I assume this was because of his proven accomplishments, above).
So, at that point, Apple [mostly] owned the complete stack:
Over the years Obj-C, had has had it's share of updates and new features -- Garbage Collection, then ARC to name two.
As I understand, Lattner was given the mission (or took it on himself) to gently bring Obj-C, that venerable veteran, into the 21st century -- to better compete with more modern languages and attract aspiring developers -- while preserving the huge investment in the existing Obj-C codebase.
Again, as I understand it, at some point it became evident to Lattner that dropping in a supercharger, a bigger engine or a stick shift would fix some of the Language issues -- but would ripple through the entire stack, with mostly negative effects ... that upgraded car needs better brakes, safety features, road tests, etc.
At some point, I suspect, Lattner put palm to forehead and said to himself: "It's not just the Language, stupid -- it's the whole stack".
From his perspective, it was obvious that the Language could/should be aware of the compiler and vice versa -- and both could/should capitalize on that knowledge ... Same applies all up and down the stack.
Lattner had demonstrated he could make Obj-C, the Language, compiler/runtime agnostic -- but could he make it compiler/runtime aware and vice versa ... Same applies to the entire stack.
Apparently, the answer is no or not easily.
... Enter Swift ...
Admittedly, long winded with some big assumptions ... But what I think Lattner is doing is rethinking and reimplement ing the entire stack ... Swift, the Language, is an integral, but small part of that.
If my hypothesis is correct ...
There may not be justification for a new Language, by itself -- but it's what it can bring to the entire stack
It's not just the language ...
Ahh ... That explains a lot. He understands the strengths and weaknesses, and what's important and what's not.
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.
Objective-C was showing it's age and many of the recent improvements added to it were more or less "bolted on". There were also some core assumptions built in, as well as a lack of support for "native" number and string types, that more or less prevented any further improvement without breaking existing software and code.
To go with your car analogy, there may not have been "quantum" advances in automotive technology over the last 30 years (OC was created in early 1980's), but at some point you're spending a lot of time and money and effort simply trying to keep the old beater on the road.
When that happens, it's time for a new car.
I think there's more to it than just the quality of the compiler.
If the language has knowledge of the compiler, debugger, runtime, tools (the underlying stack) -- it can include directives to them to generate faster, safer, more efficient code ...
Apple controls the underlying stack, and with Swift, controls the Language -- so it better optimize the whole process and the resulting product.
A developer friend told me that Swift is not quite ready for production development, it slows down development. There is a price to pay for being on the bleeding edge, one more easily absorbed by some of the big names in this article rather than indy developers who don't need more overhead.
Good point. 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.
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'll grant you that Lattner is worthy of a lot of credit and he personally has made very few claims regarding swift, choosing to keep his comments technical. But I feel his primary goal (originally) was to make a "safe language", rather than an objective-c replacement...
[IMG ALT=""]http://forums.appleinsider.com/content/type/61/id/55204/width/800/height/1000[/IMG]