Native UIKit iPhone Apps Written In Lua
mobileorchard.com
mobileorchard.com
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.
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.
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.
But I don't think GC is too far off for iPhone.
In some cases, stacking two layers with conflicting policies could thrash from caching/garbage collection logic.
This is at least the argument of most full stack proprietary formats.
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)."
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.