The iPhone APIs are written in Objective-C (some are just plain C) which is a nice language with nice and interesting features. If you have to deal with these APIs anyway, using another language wouldn't change much. You will have to create objects in the same way, send them messages in the same way, implement the same callbacks etc. Code is not much terser or easier to write with these bridges since you're not abstracting much, if anything.
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).
Check out MacRuby and some of the Obj-C bridges for other languages (MacRuby isn't bridged though), you'll be pleasantly surprised.
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 :)
No it isn't. As I said below, Hecl works fine on phones much slower than the iPhone. Ok, you don't want to do a big, huge complex app in a dynamic language, but they would be just fine for quick one-offs. Just like with regular computers...
Yeah, but that's not very interesting, so I don't include it :)
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.
> Yeah, but that's not very interesting, so I don't include it :)
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.
Sure, those languages are better, but the point is making programming more accessible to more people (something Python has done quite well too, indeed).
Great point. The problem of developing iPhone applications is that the API sucks. Let me say this again: the iPhone API is not good at all, it is a crude example of how try to be veryCoherentAndOrtogonal: is not enough. A good API is a matter of design, any amount of MVC can't change this fact.
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:
My own language, Hecl, is written in Java, is no way as fast as the C version of Lua, and yet it provides acceptable speeds for apps on phones that are slower than the iPhone. Just don't try and write an action game in Hecl - save it for the configuration and level descriptions or something. So I don't think that speed is an issue for most applications; Lua is plenty fast.
I'm not 100% sure, but my experience has been that scripting languages are more compact in terms of code:
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:-)
> I'm not 100% sure, but my experience has been that scripting languages are more compact in terms of code:
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?
I don't know Objective C very well (the last time I looked at it was in 1998, when it was probably at its low point, between Next and Apple), but with Java, Hecl definitely provides a more compact API to deal with many of the system API's.
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...
I have never heard of or seen any iPhone APIs written in C++, although some of the low-level stuff is in C. It's possible to include your own C++ code, but I really don't think Apple has any of their own. Have you got an example?
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.
I find the automatic garbage collection particularly impressive, but I wonder how it affects performance: Apple could have included the ability to use Objective-C 2.0's GC on the iPhone, but they didn't.
Actually, it's often not performance that's the problem like you might be thinking. Some apps, for example, actually become faster with Obj-C 2.0 GC enabled, since all of the retain/release message sends become noops. (Some will be slower, too, of course.)
What you do definitely lose is easy predictability of memory usage. Memory usage can spike when you don't anticipate it. On a desktop this is no problem, since you have a ton of memory to work with, and if you do use too much, it just swaps to disk. On iPhone, if you exhaust the memory, the phone reboots. Oops.
This seems to violate clause 3.3.2 in the iPhone SDK agreement, since it embeds an interpreter. That said, Apple's already accepted one app using it, so it was either ignored or in line with their intentions (even if not the wording).
Regardless, very cool. Saves me writing my own faux-VM for a project I'm working on. I'd intended to compile code to Obj-C and build everything on that, but this will save me a whole lot of time.
The SDK agreement seems (both in letter and intention) to be forbidding apps from downloading code that is run by a custom interpreter. It does not prevent an app from interpreting code that is part of the app itself.
"No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s)."
I wonder if iPhone's browser does XML and XSLT, like all modern browsers do?
It happens that XSLT is Turing complete, and the browser can certainly download stuff from teh internet. This could mean that merely embedding the browser into your iPhone app effectively turns it into an interpreter for programs downloaded from anywhere. Sure it's sandboxed but technically that shouldn't matter. And I'm sure you could introduce hooks to the browser from native side, to make something interesting out of it.
The code is being compiled from Actionscript bytecode as part of a larger project. Although I'd planned to compile it to straight Obj-C, I'd still need garbage collection and AS-type (ECMAScript) objects.
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.