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.

With 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.

These 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-init

With 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:

Anybody 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_Properties

And 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:

My rant about Nasal is mainly born out of my frustration, wanting to build certain kinds of extensions to FlightGear. For one thing, a virtual flight instructor which can setup scenarios more intelligently than the current scenarios do, for another I'm extremely fed up with my joystick and yoke configurations. Yes, I've read tons of Wiki and Forum stuff about it. I still can't fly certain helicopters because the inputs are too sensitive, while others work nicely (and I can land the Gazelle and Huey in DCS on a dime with exactly the same input hardware).

The problems I am encountering when trying this in Nasal is that Nasal development feels clumsy. It just doesn't have the kind of standard library and scientific programming support even Ruby or Lua have, let alone Python.

Yes, "Nasal must go" was a provocative eye catcher. What I am currently looking for is rather "Nasal must go as the default/only practicable way to extend FlightGear". I also don't think putting Python in the FlightGear core is feasible or necessarily a good idea. The paradigm of binding a C/C++ core to a scripting language has its own disadvantages, and that makes it very difficult to switch. Another idea is trying to replace Nasal with a javascript engine, then using a transpiler from Nasal to javascript to run legacy code. But again, unfortunately this is not my area (which is web,scientific python, ML and security).

So, the only paradigm which allows me to do what I want with FG, is remote controlling FG through a Python framework. Unfortunately, no such framework exists. And instead of making it easier for other people to use my extensions, it would make it harder. In my opinion already ridiculously hard to use FlightGear even as a pure user.

I have started such a framework, but that's where the extensive yak shaving comes in. I already succeeded in tracking properties and turning them to timeseries, and the next steps would be to improve the asynchronous organization, and implement various lower level tools. This is the sort of style I want to achieve:

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.

I used to have a colleague who always had the latest and greatest running on his machine, and was using very advanced and elegant coding techniques (I still remember the jokes about his 'recursive runtime templates'). Of course that should have beaten the crap out of us rigging old Fortran code to the purpose.

Except that damn Fortran is FAST - the compilers have decades of optimization behind them. And the code we were modifying existed for a decade and was hence near bug free. And it's simple, streamlined code, not pointers pointing here and there.

So he ended up not getting much else done except updating his Linux distro all the time to have the latest libs of everything.

Anyone who thinks working with well-tested niche solution that gets improved incrementally is an actual problem ought to read Superiority.

The problems I am encountering when trying this in Nasal is that Nasal development feels clumsy. It just doesn't have the kind of standard library and scientific programming support even Ruby or Lua have, let alone Python.

I'm mostly using things like Numpy and Pandas, just like many people in the aerospace industry I know. So I don't fear my judgement to be as questionable as you might think. Also, not everybody wants to learn how to master a niche language which has no appeal other than being integrated into FlightGear. I don't get why it should be comforting that experts with years of experience in Nasal and FlightGear are able to do full-featured orbital dynamics in it. I'm not an expert at Nasal, and I don't think it's worth it or even necessary to become one.

I totally understand that Nasal is ingrained in FlightGear, and that it is not going anywhere. But that's precisely the problem. If you wonder why there is a lack of core developers for FlightGear, why people build more free or open source extensions for FSX than for FlightGear, and why for example Blender Addons proliferate like crazy, you only need to look at what is necessary to build good extensions in FlightGear and how hard it is to instruct users how to install 3rd party scripts. Of course it's doable, but at a high cost of frustration. These factors matter.

Neither is this about following "the latest and greatest". Python (also Lua and Javascript) has been great for more than a decade now, and the scientific programming ecosystem is mature and popular. Including in domains where there was only Fortran before. Could you do everything in Fortran? Surely. Is it as much fun? Are you iterating as fast? Is it accessible to potential contributors? Probably not.

I still believe that Nasal is a big factor holding FlightGear back. That doesn't mean there is a way out of this situation with or without ditching Nasal. Hypothetically, and I know this is just speculation, I believe FlightGear would be a better project today if it had chosen Python or Lua at the time. I can't prove it, of course, other than comparing the history of FlightGear and Blender, just stating my opinion.

If you wonder why there is a lack of core developers for FlightGear, why people build more free or open source extensions for FSX than for FlightGear, and why for example Blender Addons proliferate like crazy, you only need to look at what is necessary to build good extensions in FlightGear and how hard it is to instruct users how to install 3rd party scripts.

I must have heard the line 'there's going to be many more contributors if FG only had X supported/better documented/...' a hundred times by now. Initially I was naive enough to actually go and add support for X a dozen times. Guess what - it almost never happened! And hence I stopped falling for the line. So there's unfortunately zero historical data to back up your position.

People contribute to FG because they want to - and usually acquire the necessary skill set on the way. Learning the tool takes usually far less than solving an actual problem. Compared to the years I spent coding ALS, learning GLSL syntax was a negligible fraction (and I might equally well have learned DirectX).

So while people interested in problem solving just learn to use whatever tools are there, others complain that FG isn't exactly as they'd like it to be, and in my experience they almost never change from that attitude.

Hypothetically, and I know this is just speculation, I believe FlightGear would be a better project today if it had chosen Python or Lua at the time.

Possibly. I don't think Nasal is the super-greatest tool, its main advantage is that it's a tried and tested and working tool.

P.S.: FG intentionally should *not* have a proliferation of addons like FSX - we aim to merge into mainline what is reasonable to aviod having a plethora of mutually incompatible stuff like for other sims. So pointing out that there's no proliferation of addons is not a meaningful measure of success of failure.

Beaver wrote in Fri Oct 07, 2016 10:47 am:If you wonder why there is a lack of core developers for FlightGear, why people build more free or open source extensions for FSX than for FlightGear, and why for example Blender Addons proliferate like crazy, you only need to look at what is necessary to build good extensions in FlightGear and how hard it is to instruct users how to install 3rd party scripts.

Along the same lines as Thorsten, such an argument doesn't help. Why? Because those developing FlightGear don't care. It is not a goal to attract more developers by having feature X, where X is a different value for every FlightGear user. Instead it is about building something awesome.

Talking about building something awesome, do you have coding skills? If so, what is your opinion of code implementation via test suites? If you are interested in converting your dreams into any type of reality, then join in the thread at viewtopic.php?f=6&t=28378&p=283183#p289080, git check out my FGPythonSys branches (into clones of the official repositories), and start implementing awesome new features

I was going to make the same suggestion - if nothing else, it may help you appreciate the finer points made by several people in this thread, despite many of them standing on opposite ends of the Nasal vs. Python and PUI vs. Qt5 debates.

Apart from that, I don't see any new questions or points raised in this debate that haven't been discussed previously, you will find the corresponding topics in the archives, including responses from some of the most senior contributors - regardless of whether they want to see Nasal go or not.

There's a lot that I could respond to, but I would only reiterate points made by others before - so, if you are seriously interested in this, beyond just venting your frustration, it really shouldn't be too much to ask you to do a little research first to check your facts - you will find that the wiki articles I linked to conveniently summarize most related discussions and developments

Personally, I am convinced that FGPythonSys could benefit FGNasalSys and vice versa - but for most of this to happen, many implicit dependencies need to be detangled and cleaned up - which is why being able to entirely disable Nasal, and only init some bits of it, is a crucial part of the equation - even if you never again want to run a single line of Nasal code in your fgfs process, you need to come up with a way to still "boot" into a mostly functional fgfs environment.

Like I said, I have previously done excactly that, and documented the whole journey, and shared the code/patches to do all of this.And I am interested in seeing FGPythonSys "picked up" and continued even if I should personally never have a need for Python, and despite understanding fully well that having actual Python support would add to the scripting related challenges that fgfs is facing.

But like we once said, we could definitely come up with a reimplementation of a subset of FGNasalSys and FGPythonSys to have an abstract FGScriptingSys that would be designed to be async from the get-go, and like Richard said, it sure seems like the Phi approach (remote properties and remote RPC via fgcommands) could be a straightforward to make that happen, without having to wait for the HLA/Qt5 folks to retire so that they can actually scratch off some items from their virtual todo lists.

I am start the discusion about python in flightgear.And i see for lots of use cases for python in fgfs beside nasal.For example for a you can use python for all the systems in a aircraft include glass cockpits, a gps simulation and weather simulation with Global forecast system and live lightning data form blitzortung.org using websockets and nasal for some digital displays on a airport that show Density altitude or the landing lights at Kai Tak (VHXX) that be include in site the xml file.

And for the code i think we can share some code, e.g. props, aircraft, geo, clipboard, etc and create only the python/nasal hooks.

And i see for lots of use cases for python in fgfs beside nasal.For example for a you can use python for all the systems in a aircraft include glass cockpits, a gps simulation and weather simulation with Global forecast system and live lightning data form blitzortung.org using websockets and nasal for some digital displays on a airport that show Density altitude or the landing lights at Kai Tak (VHXX) that be include in site the xml file.

You could also do these in Fortran. Or C++. Or Pascal. Or java. Or Nasal - there's nothing in there which requires Python.

Well, come to think of it, we have a weather simulation which works fine in Nasal. And again, compared with the years spent coming up with the algorithms, the few days spent learning the Nasal howto was a tiny correction. We also have glass cockpits - working in Nasal.

See, the problem with the weather sim is finding someone who understands both meteorology, rendering and math enough to make it all work - and again, once you have that, whether you do it in Nasal or Python or java is not important.

You're missing the point that

1) dependency on a huge number of external libs is considered a bad thing (TM) in FG, hence even if you convince people to implement language XY, you don't get to use all the libs in anything that goes to the repository

2) hence you're left with finding an algorithm that does what you want it to, and implementing that algorithm is the thing that takes a long while, not the week spent learning how Python syntax differs from Nasal syntax

3) but adding more scripting languages to FG means more complexity and more breaking points - so the benefit for whatever you add should outweigh the problems

So what you'd have to argue is why Python the language (without any libs) is more powerful than Nasal the language (without any libs) - and your argument boils down to 'I like it better because I'm more familiar with it'.

Well, take a week to get familiar with Nasal and you'll be familiar with it.

By the way (to beaver): I'm not able to do orbital mechanics in Nasal because I'm such a Nasal expert (other people know its internals far better than my 'useful tool' attitude and write far more elegant code) - I can do orbital mechanics because I understand the physics and can cast it into an algorithm - and it doesn't matter to me whether that algorithm is realized in Nasal, Fortran, JSBSim tags or some other tool at hand (and if FG had Python instead of Nasal, I'd do it in Python without a second thought). In fact, I have algorithms which are distributed across two very different realizations (fast low level guidance on JSBSim, slow high-level planning in Nasal for instance).

So for that simple reason you'll have a really hard time convincing me that apart from your personal preferences and prior knowledge, one scripting language is intrinsically better than the other. If you understand the algorithm, it doesn't matter which one you use.

(And if you need numerical power, you do the problem in C++ or GLSL, scripting numerically critical problems is a bad design mistake)

The point of FGPythonSys is simply implementing something for fun - pretty much the same reason that most things in open source are done. I find that justifying its existence is a little pointless. Anyway, one interesting thing that could be designed would be a set of aircraft base classes in FGData implementing some basic functionality/instruments/systems, etc. Then the aircraft can use OO (object oriented) inheritance to expand on the base class in an aircraft specific way. Of course this could be done in Nasal, but Python's OO design is far more advanced, especially with GC (garbage collection). Not that such arguments are relevant

By the way, I'm thinking that aircraft/content Python would be a restricted subset of the full Python framework. Anyway, all of this is in the realm of fantasy unless people are willing to get their hands dirty and play with C++ code.