Howdy all, took my sweet time answering, and will not discuss this further
on the list.
I didn't want to start such a conversation, and consequently only answering
now, at the risk of seeing another polemic start : not answering could give
the wrong impression :)
On Fri, Feb 27, 2009 at 12:40 PM, Brisa Francesco <
> france...@brisa.homelinux.net> wrote:
> just a minor curiosity:
> what are the advantages of using LUA instead of Nasal ?
>
> Cheers
> Francesco
That's something you'll have to figure mostly out for yourself, as I really
didn't want to get into that kind of argument (language comparisons, etc)
because Lua tends to be come ahead in those when you mention brilliant,
small and efficient in the same sentence : lua.org
But off the cuff, and without getting into the internals, as I wouldn't
(yet) be able to really give Nasal a fair shake :
Documentation, debuggers, user community.
Plus side effect of having a C API that allows loading of C/C++ modules
through Lua (similar to python dlls) : that's a free, runtime usable plug-in
system. If you don't see how this could be useful, well, think harder :)
And you don't have to buy in the Lua way, there is no such way really,
unlike Python and other scripting languages where the proper way to embed is
embedding your app in the language and not embedding the language in your
app.
Lua embeds itself, like you want it to :)
It's also brilliant, smaller (runs on cellphones) and faster than nasal
(that's an opinion, but I really can't see how anyone says Nasal is fast, at
least from my experience so far)
I also think that using a roll your own scripting solution was a mistake,
and a serious block in the wider adoption of Flight Gear as a developer
sandbox (since on this list, we won't pretend it's a general public game,
right ? ;))
It made me turn away a couple years back : an end user developer doesn't
want to have to read source code to get started.
In the game biz, it's never the best solution to roll your own when you can
reuse, especially regarding scripting. Adequate solution, sometimes.
Reinventing the wheel in a project that already relies so much on third
party libraries simply makes no sense from an outsider's perspective, as it
takes away precious and spare manpower from the crucial bits of the system
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 :)
And then it grew from there...
And well, as you can see already with FGFS and nasal, users have a way of
misusing the tools you give them...
Proper documentation is one step in that losing fight, a real debugger
another : yes, always a losing fight to prevent user abuse, that doesn't
mean nothing has to be done about it...
Also, maybe unbeknownst to the authors, Nasal is really reinventing the Lua
wheel in many cases :)
Syntax has enough similarities that extensions to the Lua VM to execute
Nasal as Lua bytecode is in the doable.
var becomes local (Lua uses globals by default, local variables are
specified by using local)
Any left handed value can be hold anything Lua wise in it, be it the
built-in types, user types, or light user types (only a pointer to user data
accessed through Lua C Api)
Oh, and you can compile your bytecode to C and load it as one of the
aforementioned plug-ins as a first step of rolling back scripts into the
native codebase for performance purposes...
And Lua internals are really, really simple and mastered by a good portion
of its community.
Nasal simply doesn't compete at that level : community of users is far from
critical mass, documentation is inexistent, and performance is not a
priority, according to the author's own words on Nasal's site.
The whole property tree would be accessed through the Lua C api, mapping to
the same names inside Lua, and could be protected from writing from Lua,
etc. Again, Lua is naturally meant to be a sandbox : it started as a purely
configuration file parser and loader, and organically evolved over the last
15 years into a full fledged bytecode VM based language.
It also doesn't impose coding styles, is naturally sandboxed.
Research it, you'll come away a changed man ;) (kidding, you might not like
it, but I'd be surprised anyone seriously researching it wouldn't see some
clear advantages to it)
This isn't a really hard project, it's just very tedious for the most part :
the hair pulling would be from the amount of partial or complete porting of
nasal scripts.
As others have said, thanks to the property system (thanks jsbsim), there is
already an elegant mechanism to interact with the internals of the engine,
so adding another scripting language is quite trivial.
All things I had considered before mentioning the possibility of Lua.
And right after the first official release of OSG version would seem the
right time for a major "spring" clean up of the codebase, etc since a lot of
existing Nasal code is simply not working as advertised right now.
With a will to add many widely different and not necessarily complementary
features in FGFS, it's more urgent than ever than care be taken with
performance, relative ease of use, etc.
Or split it up in domain specific distros, a bit like SimGear is trying to
do/doing at the "lower" level engine part.
Witness : the last official release is extremely fragile when you start
tinkering around and adding stuff not in the release itself...
The share of FlightGear developers who would like to see support for
> another scripting language in FlightGear - even though their preference
> might not be Lua - is (still) alive. They typically just don't have the
> habit of taking part in a discussion at the level it has reached in the
> meantime ;-)
>
I fully understand that, and hence why I bothered to post, hoping to get
some insights (thanks to those who tried)
It's also why the word fork was mentioned. We're still evaluating things,
and since our project and goals imply having fun doing it (not work, no
commercial intent or defense contacts to seed financial support, just good
old brain and wrist oil), it's up in the air whether we fork off FGFS and
grow from there or use FGFS to bootstrap ourselves and build a custom
simulator using jsbsim (with credit due where credit is due for inspiration)
or any other possibility.
This being developed as a purely "for fun" project, I want to avoid
irritants :)
I'm just floored by how far FGFS has come since the early days, as I
regularly say, even more so when you take into account all the bickering and
infighting that seems to take place within the developer core :)
And the possibilities it offers : wide open.
So naturally, I'm not only flying in it and preparing the Virtual Red Flag
event, I'm evaluating it :)
OK, without getting into a religious discussion about the worth or
> advisability of adding another scripting into flightgear, it sounds like
> a lot of work and feature bloat for very, very little return. :)
>
And switching to OSG wasn't a lot of work for very little return for a
sizeable portion of your (former) userbase ?
That a lot of features, some obvious, some not, are still not working is not
a hit on the ROI in your opinion ?
You talk of bloat, but you moved to OSG, the ultimate bloated whale in the
world of 3d rendering !! (and that's common knowledge)
This is not a judgement on its quality btw, but it's bloated software
nonetheless :)
And I won't mention that is has no adequate documentation and no debugger.
Period. (<-- that's very serious)
Oops, sorry I just did ;)
All in good humour : thank you Ron for going beyond the knee jerk reaction,
all in the same email.
Thanks Martin and others who decided not to devolve into the kind of
discussion I didn't want.
In parting : 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 ? That's the overwhelming current I've felt. In fact,
outside this list, I haven't heard much praise for Nasal.
And I don't mean the windows using, non coder crowd that some of you really
look down if not frown upon :)
I mean some current and former core devs. I find it mind boggling that most
of the dev info I've found so far has not been through the mailing list
(archives are barely usable, so rely on google hits in the archives) or
developer documentation, but from private discussions and sheer luck in
searching for info.
Someone mentioned that I should fix Nasal instead : I think it should be
clear by now why I wouldn't do such a thing, when the same effort could be
used to bring a fully documented, open source (permissive license), Eclipse
and other IDEs integrated solution that has a few good debuggers into the
fray.
Fixing Nasal is not trivial, bringing in Lua is, replacing nasal completely
would then be mostly tedious (and probably less so than simply fixing all
the existing nasal scripts : porting gives you a reason to fix them at
least...)
Having debugged scripts while running the main exe in my IDE's debugger and
ping ponging between the two code flows in many projects this decade, there
is no way I'd invest myself in a language that doesn't come close to
offering the standard features you'd expect from such a deeply ingrained
part of a developer's sandbox.
I'll use it if I have too, but I'll do my best to avoid it.
And, maybe alas since it's contrary to some views expressed, I'm really not
the only one who thinks that, as you darn well all know.
I mentioned fork purposefully in my initial post as well as politely
requesting an effort to maintain the discussion at a certain level.
This failed, not that badly, but failed nonetheless.
This is not the way to grow a community, and it's not for nothing I blew a
gasket with Csaba/Jester the first time I posted on the forums : after
reading archives, forum posts, etc. all full of that snide, elitist attitude
exhibed by some, I jumped at the first sign of platform bigotry (platform
agnostic myself)
Sadly, I was completely wrong and Jester didn't deserve any recrimintations
from me.
Sorry in advance for saying all that, but you know it's true.
Apologies to those who might feel slighted and have no business being so.
That said, it would seem cliques and personal fiefdoms, and one's ability to
veto changes or not, are more important than having more people use and
develop the software.
Like many others, I don't have time for that sort of thing, even though I
manage to get sucked in once in a while ;)
I hope I'm wrong, back to lurking.
Hope no one is bored to death by the long "rant"
Cheers,
Nic
--
Be Kind.
Remember, everyone is fighting a hard battle.
------------------------------------------------------------------------------
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
