You still start out with the same set of classes and methods as in Cocoa+Obj-C, but how you abstract on top of it can be radically influenced by the language you're using.
Lexical scoping with real anonymous functions, for example, is a huge win. It catches Obj-C up to the 70s, at least :)
Still, I would suggest people who are seriously interested in developing for the iPhone to check if plain Objective-C works for them, first.
My recipe is:
- Objective-C for the minimum necessary to deal with the iPhone specific APIs.
- plain C for critical parts which need to be optimized for speed and memory consumption.
- your favorite embeddable language implementation (mine at the moment is TinyScheme, but I've also used Lua) for scripting.
Also, consider that often you may need to include libraries written in c or c++. This is trivial to do from Objective-C.
You can do big complex apps in dynamic languages though. But iPhone is a somewhat restricted environment (not THAT restricted, really) where you are encouraged to use as small a footprint as reasonably possible.
Stuff like PHP indicates that plenty of people are quite happy to do quick one off's. Or Tcl/Tk for Unix, or VB for Windows. Scripting is a very sensible idea, and phones are quite capable of handling it these days.
I think it's extremely interesting creating something that opens up development to more people.
I would rather teach a new programmer Scheme, Python, Ruby etc than PHP, VB, etc.
What hurts me is that the limits are neither of Objective-C. Ok you have to deal with 1980 reference counting, but there are high level data types such mutable arrays, maps, and so on. It's not hard to imagine an higher level interface using Objective-C.
My guess is that what deserves to be tried is to build an higher level API on top of an higher level language, so you can write:
createUITable(0,0,400,300,lambda {|section,index| .... })
I'm not 100% sure, but my experience has been that scripting languages are more compact in terms of code:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
In terms of the API, well, that depends entirely on the project and their goals! A small, decent team of open source developers could probably cover most of the API in less than a year without particularly working that hard on it.
The real problem here is that interpreters for the iPhone seem to be a gray area at best (see discussion elsewhere here).
Anyway, looks like good work, and I think interpreters on phones are a great idea:-)
This is obvious. That's what they are for. But on the iPhone the tedious stuff is dealing with the APIs. And you would not gain much just by wrapping them with another language.
> The real problem here is that interpreters for the iPhone seem to be a gray area at best (see discussion elsewhere here).
As I have stated many times in other threads, there are apps (published on the Appstore) written with squeak smalltalk, games made with Unity (which uses javascript on top of Mono for scripting the game logic) etc.
What you can't do is to expose the interpreter to the user or to make it run code downloaded from the web.
Even if this wasn't the case, how could Apple even know, for instance, that I have statically compiled the Lua interpreter and used it to script part of the logic of my app?
In other words, the compactness translates to dealing with system APIs in many cases too.
BTW, dove sei? Io vivo a Padova. Non sarebbe male fare un HN Italy qualche volta...
Anyway, IIRC there's still some C++ somewhere (some parts of Core Audio, for instance) and some sample code from Apple itself also uses C++ here and there.
Performance will be affected, heavily, since you're running everything on top of an interpreted language (with garbage collection) which then must call the equivalent Objective-C function, for every single line of code.
Moreover, I don't believe that any of these wrappers (for Lua or any other scripting language) will ever cover all the APIs available on the SDK. So, what happens when I need to call one of these? What if I need to use some other library written in c, or c++? And what if I've use this code to write some apps, the projects stops being maintained and the API changes with a new release of the OS?
What does make sense instead, is to use a language like Lua as it is intended, embedding it in your app and writing only the interfaces for the parts that should interact with it. For instance, if you're writing a game, it would make sense to embed Lua to code the game logic (which would be completely independent from the iPhone specific stuff).
Just my two cents.