Thorsten is right, we did have a number of fairly informed debates relating to this idea - one of the more recent ones being inspired by the Python/FGPythonSys development that bugman and Curt mentioned.
In general, I would recommend to review those archived topics, or even just look up the relevant summaries (quote-based) via the wiki:
http://wiki.flightgear.org/Python_in_FlightGearhttp://wiki.flightgear.org/FGPythonSysRegarding Nasal in particular, it would be a good idea to review this:
http://wiki.flightgear.org/Nasal_success_storiesWith that being said, I might be in a fairly unique position to contribute to this discussion, because I am on the one hand fairly familiar with Nasal scripting, its internals and the FlightGear/SimGear side of Nasal, but I have also successfully patched SimGear/FlightGear to come up with a mode to optional initialize Nasal incrementally, and even to turn it off entirely.
You can find wiki articles summarizing both efforts, and patches/code below:
http://wiki.flightgear.org/Initializing_Nasal_earlyhttp://wiki.flightgear.org/Howto:Disable_Nasal_entirelyThese two efforts/patches were started at the encouragment of Zakalwe (James Turner), who was once highly interested in these changes as part of his ongoing reset/re-init work:
http://wiki.flightgear.org/Reset_%26_re-initWith all that being said, and with these efforts in mind, I would like to state that I am not at all opposed to providing an alternative to Nasal (as per FGPythonSys), and I am not even even opposed to replacing Nasal "eventually" - I share bugman's (and James'/Mathias') view that this could be accomplished in a semi-automated fashion by translating Nasal source code to whatever mainstream language people want to use (think lua, Python, Perl etc)
This isn't necessarily a difficult thing - anybody who's ever taken a class on compiler construction would understand how to write a source-to-source translator - with the Nasal lexer and parser being open source, it could even be "abused" to come up with such a source-to-source transformation tool, as per the behind-the-scenes conversations that Mathias and Jamed has a while ago.
However, the real issue is a completely different one - Thorsten is right, there isn't much to be gained from doing this, while the effort/workload isn't to be underestimated - ultimately, we would be sacrificing the degree of familiarity with components like LW/AW that contributors like Thorsten have, by turning our Nasal code into a machine-generate rewrite that's using a completely different syntax, and constructs - that may not be as familiar to people less familiar with other technologies/languages (think Ruby).
The other thing is, even if FGPythonSys would exist today, it would still be facing the same restrictions and limitations that any SGSubsystem/Mgr based Subsystem is facing due to FlightGear's legacy architecture - the meat of everything would have to remain what we know to be the core Nasal APIs interfacing between FG/SG, namely the property tree, fgcommands and a bunch of subsystem specific APIs and other extension functions - none of which can be considered "thread-safe".
This sort of thing isn't magically solved by replacing, or even just providing an alternative to, Nasal with a more established/mainstream language like Python - for that to happen, an IPC mechanism like HLA would need to be adopted, and a bunch of conceptually flawed/broken FlightGear legacy code would need to be fixed along the way, which is to say that this would literally take 5+ years to complete - even if you were never to look at any Nasal code at all.
It seems that people tend to understimate the magnitude and workload of such efforts rather massively, especially in the light of the pain/gain ration that is realistic given the circumstances and constraints we're dealing with (manpower, time, other resources).
Someone mentioned the Qt5 effort - that is actually an excellent example for this tendency to understimate the work that lies ahead, while overestimating the pain/gain ratio, despite history proving the opposite: The Qt5 effort is basically juggled by a single FlightGear core developer, who happens to have a massive track record of contributing to FlightGear/SimGear for over a decade, as well as being intimately familiar with the Qt/Trolltech (Nokia) technology stack - this single person has touched more components, and code, (and made more commits) than any other core developer in the last 10+ years - still, the Qt5 effort is contributing to crippling FlightGear rather massively by adding new segfaults and race conditions that can be definitely linked back to Qt5-related GUI code.
Thus, the situation with Qt5 vs. PUI (our legacy GUI engine) isn't too much unlike the situation between Python and Nasal (one being extremely mainstream/popular, and the other being a real niche solution, that is only really relevant in the context of FlightGear).
However, with all this in mind, I am the last person to argue that having Qt5/Python support in FlightGear would be
excellent to have, as long as it is working as well as the existing solutions we have; namely, our PUI GUI and the Nasal engine.
Absent that, we are facing a dilemma of having a massive code base with two niche solutions that use legacy code, whereas we have novel/more popular solution, that hardly work at all, and that are only being worked on by a single developer - whereas the legacy components (intended to be phased out sooner or later), simply represent over a decade of code, and brainpower, contributed by a bunch of major contributors - which is where, and why, the FlightGear legacy inevitably "competes" with a single person trying to re-architect FlightGear single-handedly.
Unfortunately, this hasn't been working out too well at all - another example would be the original metakit component in FlightGear, compared to the SQLite-based NavDB, which also happens to be the culprit for 90% of the support enquiries posted on the forum (coincidentally re-architected by the same major FlightGear contributor).
In other words, there is something to be said in favor of legacy components that simply work, and in favor of not phasing out stuff prior to having alternatives that work at least as well, or that provide a sane migration path - in the case of the NavDB, GUI and Python/Nasal debate, this simply isn't the case yet (unfortunately!).
What has been happening in the last 10 years is that FlightGear has been facing major challenges, some of which are induced by core developers, some of whom are obviously trying to single-handedly modernize a codebase without making sure that legacy code has working alternatives before deprecating certain functionality.
Really, we have been locking out more and more users, because FlightGear's priorities were not that much in tune with the reality as it's faced by many end-users (as can be seen on these forums).
There is an increasing tendency among some people to move towards a "technology-lockin", something that Mathias was very much opposed to, which is why he encouraged wrapping OSG APIs at the SimGear level, due to his own frustrating first-hand experience of porting/starting to part PLIB SSG to OSG 10 years ago (mid 2016).
Equally, with Rembrandt we have a fairly popular rendering component that nobody is really familiar with, and that nobody is willing/able to maintain these days - equally, with so much GUI/Qt5 and NavDB/SQLite related work contributed by a single FlightGear core developer over the course of the last few years, it is likely that those components would be also facing the same dilemma that Rembrandt, and to some extent even the OSG port, have been facing - being semi-complete, poorly understood by the remaining share of core deveopers, and hardly maintained at all - which -funnily- is one of the key complaints that people have about Nasal's status, too.
I kinda agree with most things that Richard said, even though GC is a problem under /some/ circumstances - but AndersG did offer several patches related to this, some of which helped improve the situation a little, but which complicated Nasal-heavy subsystems interacting with rendering related code (e.g. Canvas APIs accessed via Nasal, writing to a FBO/RTT).
But apart from that, even if bugman were to spend a full year developing FGPythonSys to bring it up to par with FGNasalSys, it would still be facing the same challenges, and contributing to the same issues in FlightGear - simply because the problem is not specific to Nasal.
If you don't believe me, review the patches that incrementally init bits of Nasal, or that disable Nasal in its entirety (or even just its GC) - and you will see that Nasal is not the major culprit at all.
There is work that lies ahead that would benefit FGPythonSys and FGNasalSys at the same time - such as a strong IPC mechanism, like HLA, or even just Emesary via remote properties (asynchronous remote properties and fgcommands, as per Torsten's mongoose/Phi work) - Torsten basically proved that you don't need to use HLA to come up with async modules that can interface with the rest of FG - if this, his, approach were to be formalized, standardized and extened, many other subsystems could be using this, none of which would be facing the challenges that Nasal/Python are currently facing (or in fact any other SGSubsystem not using SGthread, too).
Like Thorsten and bugman said, rewriting all existing Nasal code would not be an option - the only feasible/sane approach would be parsing a legit subset of Nasal, analogous to the pui2canvas translator which turns a subset of PUI/XML into Canvas GUI dialogs, without any of those having to be touched/edited:
http://wiki.flightgear.org/Howto:Proces ... ing_CanvasAnybody not considering to use a semi-automated translation/interpretation is deluding themselves and really just a time waster given the amount of legacy functionality that must continue to work (think checklist, tutorials, joystick configuration etc)
The amount of Nasal code is staggering - but that also means that there is only really a well-defined pool of APIs that must be exposed via an IPC to make the whole shebang asynchronous using Torsten's mongoose/Phi approach - which is basically just a resurrection/re-invention of Erik's original SGRemoteProperty idea:
http://wiki.flightgear.org/Remote_PropertiesAnd I think that's really what Richard is hinting at when he refers to Phi, i.e. its back-end, not the front-end part - and the back-end could, and arguably should, be also shared/used by other UIs, including possibly PUI and/or a Canvas-based GUI.
Unfortunately, for the time being, providing an alternative to Nasal, or even replacing it in its entirety would provide you with zero benefits, due to the legacy FlightGear architecture, which would require major re-architecting to make this a worthwhile goal.
But like I said, I am not opposed to discussing/adding options (that may sooner or later also have ramifications/benefits for the Nasal IPC mechanism), I just don't think that our priorities are currently too well aligned ...
PS: In general, might I suggest to spend a little more time researching your facts to make your point ? For instance, the following is also wrong:
OP wrote:Nasal doesn't have bindings to things like GTK,
http://kymatica.com/Software/AlgoScorehttps://github.com/andyross/nasal/blob/ ... c/gtklib.c