lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 20-Sep-06, at 1:02 PM, Sam Roberts wrote:

> Which is too bad, I use OS X, and I'd like to be able to script it with
> lua. On the other hand, I'd rather learn js than applescript, so there
> is some good news there.

Actually, AppleScript is a really interesting concept. You should give
it a try. I'm sorry to hear that Apple is phasing it out (something
I suspected).

Apple is not phasing out AppleScript as far as I know. I attended a
Cocoa developers group meeting just last week and got an earful from a
very nice Apple engineer about how I need to learn Applescript (which
I concur) and how deep the Applescript integration is with their
applications and how they continue to improve it. Automator is the
next logical layer above Applescript, but Applescript isn't going
anywhere and I think the two are designed to work together.

Javascript for Dashboard I hear was motivated partly because the
authors wanted to learn Javascript and also partly because they
thought their intended audience would be willing to learn Javascript
(if not already know it). From a marketing standpoint, it's easy to
justify Javascript just by the sheer number of books available on the
topic. (It's a real shame O'Reilly dropped out of the publishing deal
for the Lua book at the last minute. I think it's a dumb decision too
considering what I'm perceiving as an increase of interest in Lua due
to World of Warcraft.)

As far as application land development on OS X, Objective-C is the
first class language for this. (Even Dashboard has a bridge to
communicate between Obj-C and Javascript for those widgets that need
deeper system service access.) But Obj-C has wonderful introspection
capabilities which help make it easy to bind other languages. The
PyObjC bridge is probably the most mature example of binding to ObjC.
It is really impressive and you can write fully polished and
deployable Cocoa applications all in Python. There is also a
Ruby/Obj-C bridge but I don't know much about it, but Ruby on Rails is
shipping with Leopard, so I expect it to pick up traction from that.

With respect to Lua, there is a LuaObjCBridge:
It is no where near as refined as the PyObjC bridge, but Lua is a much
easier language to bind with and I suspect many of the evil things the
PyObjC bridge had to do wouldn't be an issue with Lua. And as the
bridge is now, you still can get a lot of milage out of it.

Also, the Adobe folks showed off some really impressive Lua/Obj-C
integration of their own at the First Lua Workshop. I think they said
they rolled their own bindings but took ideas from the LuaObjCBridge.

With respect to Lua syntax, I don't think it's that weird. But my
measure is related to C. Particularly for Lua which revolves around
the idea that it binds easily to C, a casual/superficial similarity to
C syntax I consider favorable. The other advantage of C-like syntax is
that everybody who does serious programming can (kind-of) read C. They
may not be able to code in C and they might not understand all the
subtle points of pointers, etc, but C is just so ubiquitous that it's
hard to get by without having to read a small bit of C code every now
and then. (Back in my heavy Perl days, my team adopted coding
standards to try to write our Perl code in a C-style because everybody
can figure out C, but not everybody can figure out Perl.)

So when talking to engineers about embedding Lua into existing
projects, I find it easier to convince those engineers when the syntax
of the scripting part isn't totally alien to them. (Python in
contrast, looks distinctly different from C to me, even though I know
it to be a nice language to write in.)

The weird parts to me are the extra keywords such as "then" in
if-statements, and "in" and "do" in for loops. These keywords seem
redundant to me and I often forget them. If these keywords were to
disappear in future versions of Lua, I don't think I would miss them.
Also the lack of braces and the use of "end" I find a little 'weird'
from a C vantage point, but this one doesn't bother me much.