FlightGear needed a built-in scripting language, and it has one.
A compact, clean, elegant and fast one. In total there are at the
moment more than 170.000 lines of Nasal in *.nas files and a few
thousands embedded in joystick drivers, dialog description files,
model animation files, keyboard.xml, mice.xml and several other
files. Extension functions interface perfectly to the property
tree, the event manager, the built-in XML parser etc. Nasal is
very tightly integrated in fgfs and used all over the place.
The Lua language is quite similar to Nasal, even syntax-wise
(where there are differences, Nasal is better IMHO).
Do we want two similar languages embedded in fgfs side by side,
so that people can choose? Hell, no! This is just needless bloat
("re-invention of the wheel" is an understatement!) and it would
be a source of confusion. On which basis would people decide for
one or the other? Would we expect them to evaluate both languages
and to find out which works better for them? Or just take a random
pick? What would be the advantage? That people who don't like
Nasal can have something that's quite similar? Doesn't sound smart.
So, having both in FlightGear is clearly not desirable.
Would we want Lua to replace Nasal?
Andy, the author of Nasal, is also FlightGear developer. He has
done the integration in fgfs himself, he knows about our needs,
he's almost daily in our IRC channel and always willing to answer
questions or to improve the language. Lua just can't beat that.
And it wouldn't be enough for Lua to be as good as Nasal, or
slightly better. It would have to be vastly better to even be
considered. It's an uphill battle and it doesn't look good for
Lua.
What are Lua's advantages? Random picks from Nicolas' email:
"debugger": Sure, that's nice. We have several debugging
utility functions for Nasal, but no debugger. But then again,
I wouldn't often have needed one. And to quote a fellow fgfs
developer after he had read the Lua wikipedia page: "No wonder
they need a debugger!" (People might be thrilled to learn that
Lua's arrays (which are emulated with hashes, because there
are no arrays at all) start with index 1 (Shudder!). But that's
not all: you *can* write to array[0] and don't get an error
message, but Lua will silently throw the value away and return
nil if you read it out! Yes, Lua badly needs a debugger! ;-)
"documentation": True. Nasal could use some more. Nicolas could
spend some of the time that integrating Lua would have taken for
writing Nasal documentation. :-)
These two points were the only clear advantages. What about
the rest:
"faster than nasal (that's an opinion, [...]": Exactly. Just
an opinion, with no benchmarks to back it up. And even if it's
slightly faster: the Nasal execution time is *not* a bottle-neck
in fgfs by any means.
"C API that allows loading of C/C++ modules through Lua": That's
seriously presented as an advantage? It means that we would in no
time see fgfs aircraft coming with binary blobs that users are
supposed to install, but which they can't explore. That's not
only dangerous, it also undermines FlightGear's Open Source
character. This misfeature (in our context) alone should be
enough to reject Lua! That's a gift for commercial freeloaders,
not something that we profit from. If something needs to be fast,
then we can code it in C++ right away, and make it available to all
aircraft.
"user community": Nasal and FlightGear have their own user communities,
thanks. Nasal isn't FlightGear only. It's used in other projects as well.
And the Lua community wouldn't buy us much either. We wouldn't want that
aircraft depend on external Lua modules, which users would have to
download from www.luarocks.org or wherever and install them just to
fly that aircraft. People contribute to fgfs because they want to,
not because they are already familiar with its scripting language,
which is easy enough to learn.
* Nicolas Quijano -- Wednesday 04 March 2009:
> I really didn't want to get into that kind of argument (language
> comparisons, etc)
How telling!
> In the game biz, it's never the best solution to roll your own [...]
FlightGear is neither a game, nor a "biz".
> And no, nasal is not really crucial, at least not with jsbsim.
> Why was Nasal chosen in the first place ? Wasn't it to supplement a
> fledgling FDM module at the time, yasim, that was lagging behind jsbsim and
> its property system ? Or so I've inferred and been told :)
First: the property system was adopted *by* JSBSim. It's not something
that JSBSim brought to the project. And second: Nasal has nothing to do
with YASim other than it's by the same author. It doesn't have much to
do with FDMs at all. It's used all over the place. Who was the source
of this nonsense again?
> it doesn't bother anyone that the overall feeling given by more
> than a few longstanding community members is that Nasal is NOT well
> liked, quite the contrary ?
More from the uninformed source? Where's the evidence? Names please!
Nobody ever said that s/he doesn't like Nasal to my knowledge. Many
people said over time that they like it. I do. I can't stand the
Lua verboseness ("end end end").
All of Nicolas' smearing seems based on false presumptions and
questionable secret sources. Or are they just made up?
Regarding my "veto" power (or lack thereof): It was clear that despite
quotes and smiley this would make some people foam at their mouth. Of
course, there's no formal veto power. But I am pretty sure that there
will be no official FlightGear with Lua *and* me as an active contributor.
Sure, the project could easily survive without me. Many people wouldn't
even notice. (Just like it survived without Lua or Nicolas as a
contributor. Has he even contributed a single line of code yet?)
m.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
