

Native UIKit iPhone Apps Written In Lua - mobileorchard
http://www.mobileorchard.com/announcing-iphone-wax-native-uikit-iphone-apps-written-in-lua/

======
cesare
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).

Just my two cents.

~~~
tumult
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 :)

~~~
cesare
Yes, MacRuby is something slightly different.

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.

~~~
tumult
Yes, I actually agree with you. Especially iPhone is a little ways off from
being suitable for a scripting language.

~~~
davidw
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...

~~~
tumult
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.

~~~
davidw
> 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.

~~~
tumult
The ends and the means are not necessarily the same thing!

I would rather teach a new programmer Scheme, Python, Ruby etc than PHP, VB,
etc.

~~~
davidw
Sure, those languages are better, but the point is making programming more
accessible to more people (something Python has done quite well too, indeed).

------
spicyj
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.

~~~
tumult
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.

But I don't think GC is too far off for iPhone.

------
daeken
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.

~~~
mbrubeck
EDIT: This is wrong now; see below.

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)."_

~~~
yason
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.

~~~
ptomato
Or, you know, javascript. Which the iPhone's browser definitely supports. And
which isn't governed by the terms of the SDK anyway.

------
mml
woo!

