Why waste time learning to use JS on the iphone, when you may as well just write the app in C++ or Obj-C? At some point, you'll need to go native, and then you've lost a portion of your time-investment. Instead, just learn it properly, and you can always do things.
You'll have a single code-base for multiple platforms (iPhone, Android, web, even desktop with something like Adobe AIR)
The interface may be tweaked to fit the format of each platform, but the application logic (which is likely the complex part) will be entirely the same.
Well to push the nasty programming aspects as far out to the edge as possible and be able to do most of the programming in a pleasant programming language.
And the common code base for porting is another factor, too. I don't see a great future for Objective-C, but being really good at Javascript seems like a safe bet for a useful skill.
So far I have only read the tutorials to some extent. I don't like that there is no garbage collection on the iPhone, and that I have to write header files. The pointer stuff looks suspicious, too, but I have not read far enough to know how awful it will be.
I seem to remember that Joel On Software wrote once that garbage collection gave one of the biggest productivity boosts modern languages provide.
Oh, another thing I don't like is the stupid hungarian notation of the API.
Also, it seems kind of pseudo-dynamic: if it is dynamic, what is the point of header files and interfaces? It doesn't make sense to me.
"I don't like that there is no garbage collection on the iPhone, and that I have to write header files. The pointer stuff looks suspicious, too, but I have not read far enough to know how awful it will be."
If those are your only complaints, may I suggest Objective-J and Cappuccino... http://cappuccino.org ;)
We have garbage collection (it's just JavaScript underneath), no header files, and no raw pointers (again, just JavaScript objects).
But pointers in Objective-C aren't really a big deal, you just have to be sure to declare your variables with the "*". After that they're just like objects in any other dynamic language.
As far as the "pseudo-dynamic" claim goes, it is indeed an interesting mix of dynamic and static. You can add new methods (in "categories"), introspect objects for their methods, etc. If you don't want static typing just declare all your variables as "id".
The more I learn about Objective-C the more I find it to be a very elegant language. It's pretty amazing how 20 years ago they were able to take a very rigid non-dynamic language, C, and turn it into something so dynamic. Even 20 years later Objective-C and Cocoa are still very modern language/framework combo (granted it has been updated by Apple over the years).
Header files are a blessing. They move many bugs from runtime to compile time. The point of the header file is to make a contract. Sometimes that isn't appropriate and there you can "go dynamic" if you need to, but you are moving your errors to the runtime.
The retain/release model of object lifetime management in Objective C becomes nearly automatic for the programmer. That being a dangerous "nearly", you can still screw up.
Garbage collection is much nicer, but given the limited memory I can understand why they didn't enable it on the phone.
Remember: You can screw up badly with garbage collected systems too, it just doesn't result in a core dump on a desktop machine. You can accidentally leave references to objects you will never access again (cache structures are notorious) preventing it from being reclaimed. On a desktop that leads to a bit of memory bloat and maybe some swapping if the app runs long enough. On an iPhone you run out your RAM and get terminated.
Thing is, I programmed (garbage collected) Java on mobile phones for years, and those devices had far less memory than the iPhone. So the "it makes sense for a mobile phone" argument simply doesn't fly with me.
Header files: Java doesn't have header files, and I am sure it provides the same level of compile time error catching (or doesn't it?). I just deeply resent having to write the same code twice, and I suspect the explosion of files required doesn't make things easier, either.
There is also a personal preference: having coded Java for years, I would simply prefer a dynamic language now, instead of Objective-C (which also has the Java-style interfaces, I have heard - why do they need BOTH interfaces and header files? One would be sufficient for the compile time checks, I would think). .
"... Why waste time learning to use JS on the iphone, when you may as well just write the app in C++ or Obj-C? ..."
Answered the Q right there.
"... It's pretty obvious that in order to be able to build the best possible iPhone application you would have to know Objective-C. Having a clear path, paved with JavaScript, to that end result should be any JavaScript developer's goal ..."
I can see a time that the browser on the iPhone will be a nice WebApp platform without entirely having to "go-native" (but still understand).
There is a large class of applications for the phone that do not need to be native. I'd guess (unscientifically) that its about a third of the apps on the app store, and probably growing.
That's not the point. There is a large class of desktop apps that could be programmed in Javascript also. The point is - why would any developer or any development studio bother with investing time and effort in learning Javascript for the iPhone, when you can just invest the time in learning how to use C++?
Using Javascript will give you a short-term boost, but at a long term cost. And at some point, when you do switch to the native API, you need to restart learning.
The difference in using C++ and javascript on the iphone is pretty small - they have similar syntax and organisation. C++/Obj-C actually has some advantages in terms of speed, because of the much larger availability of sample code and tools to work with it.
And of course, there is the native vs intepreted advantage of C++ code.
Also, I'm not sure where you got the idea that you can write iPhone apps in C++, you can't, the API is almost entirely Objective-C and some straight C (though there may be a few C++ APIs)
