Board index FlightGear Development Nasal

advantage of using nasal  Topic is solved

Nasal is the scripting language of FlightGear.

advantage of using nasal

Postby senia » Wed Oct 17, 2018 8:08 am

Hey guys,
I'm new to these kinds of things and my question may seem simple so bear with me :)
I'm not very familiar with the core programming of flight gear but I was wondering why did you use Nasal and not python (or other well-known languages)?

and what is the point of using a scripting language for this project really? couldn't you use the c++ language for the whole project (performance-wise)?

I'm fascinated by the project and want to know more and of course, I search the forum before asking questions like a good student! :D
senia
 
Posts: 2
Joined: Wed Oct 17, 2018 7:44 am

Re: advantage of using nasal

Postby Thorsten » Wed Oct 17, 2018 8:15 am

I'm not very familiar with the core programming of flight gear but I was wondering why did you use Nasal and not python (or other well-known languages)?


Please do a form search and you'll find long arguments exchanged back and forth on the relative merits of different scrpting languages.

I'm not really sure Python was widely known (or even available) when Nasal was added to FG - that's likely the reason why it was not used back then. As for why things aren't 'simply' changed - the downside of converting a few hundred thousand lines of code to a different language far outweighs any benefit.

Nasal does what it's supposed to, in the end it's as simple as that.
Thorsten
 
Posts: 10982
Joined: Mon Nov 02, 2009 8:33 am

Re: advantage of using nasal  

Postby Hooray » Wed Oct 17, 2018 3:55 pm

Hi & welcome,

I don't think there is a short answer that is "correct", other than encouraging you to search the forum and look up all the pros & cons stated in related discussions.

Now, when it comes to scripting vs. C++ the one thing to keep in mind is that it is indeed much easier to write FAST code in C++, but it is also much harder to write correct, bug-free, code. In other words, C++ code comes with the obvious benefit of performance, but stability is another issue - because it requires enormous expertise to write proper C++ code, especially whenever you are not dealing with code written from scratch, but with a legacy codebase like FlightGear, that already has tons of code written in C++, that must remain functional - especially anything involving multiple threads (i.e. using multiple CPUs).

Scripting on the other hand, comes with a compromise: it is more difficult to write fast code, especially when compared to C++, but it is also much harder to screw up things, and you can write code without having to know how to rebuild fgfs - i.e. it is also an option available to aircraft developers who don't necessarily need to be coders.

When it comes to Nasal in particular, you really have to keep in mind that it takes two things to integrate a scripting language inside an existing application: 1) familiarity with the internals of the application in question (fgfs in this case), and 2) enormous familiarity with the scripting language, not just the scripting side of things, but also internals like the VM. And actually there is a 3rd one: you want to have someone involved in the project who can handle any issues that may occur.

At the time, Andy Ross came up with his own "toy" language from scratch, called it NASL (and subsequently Nasal), and he also was an experienced FlightGear contributor, so that all 3 requirements were satisifed, and that's how Nasal ended up in FlightGear (however, it wasn't the first scripting option either, Erik added JavaScript support once and PLIB PSL was also integrated once - it's just that at the time, Nasal was considered superior by those interested in scripting - mainly for the 3 reasons stated above).

As others said already, today, there are plenty of viable options when it comes to embedded scripting - back in the day (early 2000s), Python or Ruby were not exactly mainstream either, and not even today are they necessarily suited for being embedded into an application like fgfs.

Lua would have been, and probably still is today, a more likely candidate when it comes to embedding an existing language into an existing legacy code base.

Now, asking why Python/Ruby or Node.js/JavaScript were not used instead is akin to asking why you didn't win the lottery.

Then again, there are very real technical issues - even if someone were to volunteer and contribute a working Python/JavaScript integration, there is an existing legacy code base that comes with a certain architecture (read: cruft). Many (most) of the Nasal related issues are actually not due to Nasal but due to the fgfs side of things, i.e. the interface/method that is used to integrate the scripting world with the rest of the sim, and that would remain a challenge regardless of Nasal being used or not, FlightGear's architecture was never designed with such requirements in mind (referring especially to multi-core platforms and scripting outside the main loop).

If you are interested in learning more about the nitty gritty details, you could check the FlightGear wiki and look up articles mentioning "FGPythonSys".

Finally, even if you/someone were to provide a working Nasal alternative/replacement today, there is meanwhile quite a bit of existing Nasal code that the project has accumulated over the better part of almost two decades now. And from a coding standpoint it's not exactly straightforward to ensure that this keeps working, short of writing a Nasal parser and VM in whatever new scripting language is to be added (say the equivalent of nasal2python).

Other than that it's literally a mammoth task to provide a migration path for existing features implemented on top of/via Nasal.

And to be honest that is not specific to Nasal or scripting, it's a general thing when switching back-ends: There is an ongoing effort to replace the built-in FlightGear GUI (called PUI) with something Qt5/QQ2 based, and it's literally become a multi-year effort (all shouldered by a single enormously experienced fg core developer) without much/anything tangible (or even just visible) materializing in terms of Qt-based dialogs/UI functionality that is a concrete runtime replacement of PUI.

Nevertheless, nobody is arguing that PUI would be superior to Qt5 (far from it), but there is a certain degree of legacy functionality that must remain functional regardless of the technology stack/back-end in use , short of someone offering to rewrite such features using the new technology stack (scripting or UI).

In addition, the transition period can be rather long and painful, too - for instance, in the case of the UI transition, the community has been repeatedly asked to put other efforts on hold and not to work on alternate UI back-ends (e.g. via Canvas), in order not to derail the underlying core development effort, despite other attempts actually having produced workable in-sim replacements of some PUI widgets/dialogs, years ago already.

Thus, such back-end migration are likely to cause friction and irritation, especially if they prove unable to deliver on their promises (in retrospect). And that also applies to other efforts that were rather aggressively promoted by some senior folks, without delivering much over the course of a whole decade (e.g. HLA/RTI has been repeatedly referred to as having a reputation for being "pie in the sky" by other contributors).

Which is just one way to make the point, that sometimes people let the perfect be the enemy of the good (enough), spending years debating and re-implementing existing features without a proper reality check, i.e. a pain/gain analysis: https://en.wikipedia.org/wiki/Perfect_i ... my_of_good

http://wiki.flightgear.org/PUI
http://wiki.flightgear.org/Qt5_Launcher
http://wiki.flightgear.org/QtQuick_use_in_FlightGear
http://wiki.flightgear.org/Pui2canvas

Besides, while re-implementing a working Nasal VM would of course be possible, that would not magically fix up coding issues that crept up in Nasal code due to mainloop/interfacing issues (think timers/listeners used to implement complex subsystems inside the main loop).

Thus, some fictional Python/JavaScript or Ruby module would have to deal with machine-translated Nasal code that is using the same problematic programming paradigms. And it's worth taking into account that not even all C++ code is using the recommended SGSubsystem/Mgr based APIs either.

Now, when it comes to truly Nasal specific issues (think the mark/sweep garbage collector) it would definitely be less work to fix up that (as in integrating/supporting alternate GC schemes) than integrating a new scripting language, let alone replacing Nasal in its entirety.

From a software engineering standpoint, Nasal is much better prepared for leveraging modern multicore hardware than the legacy FlightGear architecture is. It is very unfortunate that none of the SGSubsystem APIs were ever fully exposed to Nasal space so that aircraft/scenery and addon developers could use those instead of timers and listeners.

https://en.wikipedia.org/wiki/Scripting_language
http://wiki.flightgear.org/What_is_Nasal
http://wiki.flightgear.org/Nasal_FAQ
http://wiki.flightgear.org/Nasal_success_stories
http://wiki.flightgear.org/Modernizing_ ... _Scripting
http://wiki.flightgear.org/Python_in_FlightGear
http://wiki.flightgear.org/FGPythonSys

To be honest, whatever you find in FlightGear in terms of concrete features isn't necessarily there because it's superior on technical grounds, but rather because FlightGear is evolving "organically", so that features getting implemented has more to do with who is/was around at any given time and what expertise they could bring to the table, and what FlightGear had to offer in terms of interfaces/extension mechanism.

For some features this has obviously worked out rather well (think property tree, XML), for many others it hasn't worked out at all in retrospect.

There's some shining examples actually - for instance, a scripted weather system (originally called local weather, now referred to as Advanced Weather) that was at some point entirely prototyped and implemented in scripting space using Nasal, despite some rather strong resistance among some of the most senior project contributors, who were hoping for such "key" (read: core) functionality to be implemented in C++.

However, due to the choice of fgdata-level extension mechanisms (base package), there was/is no endorsement needed by those overseeing the development of the simulator "kernel" (core developers) - this has obviously pros & cons, especially from a QA standpoint (not referring to the weather system).

There are other examples, like spacecraft implemented inside FlightGear without any support from C++ developers, so that new avenues can be explored without core development necessarily being a bottleneck.

Besides, it is worth keeping in mind that for many 3D modelers wanting to develop aircraft, FlightGear scripting via Nasal is often their very first exposure to scripting/coding, so that Nasal provides for a fairly low barrier to entry, while still using a syntax and programming paradigms that may come in useful at some later point in time, e.g. when writing shaders (Nasal's syntax is very close to C, which is what GLSL is also based on to some extent).

Finally, someone like Thorsten who literally spent a decade of contributing to the simulator primarily via Nasal coding, is unlikely to be particularly thrilled by announcements to phase out Nasal, or even "just" to see his contributions getting machine-translated into a language/style that he may no longer feel comfortable with (regardless of the programming background)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: advantage of using nasal

Postby senia » Thu Oct 18, 2018 7:32 am

Thank you guys, now I get why you chose nasal.
All the best,
Sohail
senia
 
Posts: 2
Joined: Wed Oct 17, 2018 7:44 am

Re: advantage of using nasal

Postby Hooray » Tue Oct 30, 2018 4:37 pm

One thing that I didn't mention but that's often cited as being the main motivation for wanting another/alternate scripting language is community support, i.e. tutorials, examples and documentation - but also 3rd party libraries, i.e. toolkits and frameworks that are readily available. The thing to keep in mind here is that with the current fgfs-side interface, the code will look the same regardless of the language in use (apart from syntactic differences obviously), and it will also face the same fgfs/architecture-induced challenges (if not shortcomings).
However, a much better supported scripting platform like Python, JavaScript or Ruby is also going to make these fgfs-level issues even more prominent, because the barrier to entry would be much lower, but also because people will often be already familiar with the other language, so will have some expectations - that may not be in line with how fgfs wants things done.
Nasal however is entirely niche, and while the language is fairly "standard" compared to JavaScript, most of the really useful APIs are fgfs specific anyway.

If someone really needs "Python the platform" to script a certain fgfs specific system, they'd be well-advised to just do so, and manually implement the interfacing part - because the way the Nasal integration is done (timers + listeners) is most definitely not what people need who want to use 3rd party toolkits/libraries.

Which is to say, when it comes to fgfs scripting, Python/JavaScript minus all its dandy libs isn't all that useful to begin with, unless you are in need of good support resources (docs, tutorials, manuals etc) - sooner or later, you will at least want to have the kind of fgfs access that Nasal provides, which also comes with certain bottlenecks that are not due to Nasal, i.e. you want to have some kind of IPC/RPC mechanism in place and run the scripting interpreter outside the main loop, at least in a different thread, ideally in a different process.

So, even if FGPythonSys were a workable alternative right now, it would face these challenges, unless it's using an IPC mechanism like HLA to hook into fgfs without having to run inside the main loop. And this would become very prominent, and problematic, the very instant any of the libs and toolkits that make Python/JavaScript so awesome, are going to be used by someone writing a "fgfs script".

FWIW, we also had some talks about a dedicated LLVM-based back-end for Nasal, which may provide additional insight: Proposal: a Nasal JIT LLVM front-end
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11329
Joined: Tue Mar 25, 2008 8:40 am


Return to Nasal

Who is online

Users browsing this forum: No registered users and 1 guest