Modernizing FlightGear Scripting
| This article is a stub. You can help the wiki by expanding it. |
 |
Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments. |
Background
FlightGear has built-in scripting capabilities using a custom ECMAScript-based C-like language called Nasal. Over the last couple of years, we've seen some recurring debates in response to requests to provide support for additional scripting languages, possibly to replace Nasal scripting in its entirety.
Motivation
Nasal is de-facto unmaintained and has been unmaintained for several years meanwhile, Nasal is a niche language that is really only used by the FlightGear project, long-standing issues such as its garbage collector, which isn't suitable for a semi-realtime application/simulation like FlightGear, haven't been fixed in years.
In general, there are other, much better maintained, options for embedded scripting these days, such as e.g.:
- Lua
- Python
- Perl
Today, Javascript, Python and Lua have surpassed Nasal capabilities in pretty much everything the FlightGear community cares about: performance (garbage collection, jit etc), concurrency, parallelism, bindings, language ecosystem, and especially the developer base.[1]
In addition, documentation and end-user support for more established/mainstream languages is obviously much better than anything we have for the custom FlightGear/Nasal interpreter.
Many people argue that a more standard scripting language (like e.g. Python) would also attract more potential contributors to FlightGear, also the sizable community with 3rd party modules, means that new functionality can be much more easily implemented ("batteries included", and "no yak shaving" needed).
Challenges
FlightGear can't just ditch Nasal. Bringing another scripting language into the fold would certainly be a big undertaking.[2]
It is really important to note that in a small application which is probably 1/10 or 1/100th the sie of FlightGear, this (supporting Python) was a truly massive undertaking to make these changes ... on the order of 2-3 months of pretty much non-stop effort. For FlightGear it would be almost insurmountable. I think it's an interesting topic to discuss in theory. We can point to examples and all the good things that python could bring to the table. However, we can't get around the fact that this could be a multi-year effort to do the conversion in a way that truly modernizes FlightGear and truly leverages all the good aspects of Python ... and during that 'under construction' period of a year or more, most of FlightGear would be broken.
Edward came up with an alternative scheme where he built a python interface to the existing C++ property tree and some hooks to run python scripts, but still ... dropping nasal and converting to python requries porting AND carefully testing all the scripts though all their code paths and edge cases. Just that would be a massive undertaking, and it wouldn't be fair to just port the core nasal, and hang all the aircraft and scenery developers out to flap in the wind to figure it out for themselves.[3]
References
References
|