Thorsten kinda hit the nail on the head. He could have been more polite - but sometimes your opinion can be unpopular, while your still right - and sometimes you can be wrong, and still be very popular.
This being the "infamous merito-crazy" we are, we also tend to weigh feedback based on who's making certain statements, and especially requests and suggestions that require tons of work...
You/we cannot expect any contributors familiar with Nasal, and its internals, to immediately jump on the Python bandwaggon - but for the whole thing to work out, you need to get all parties involved. First and foremost, this means understanding the goals and priorities of all the people involved in "FlightGear scripting" (in general, unrelated to any particular solution).
Next, you need to understand what the legacy functionality, i.e. functionality that we simply "inherit" and that must (mostly) continue to work "as is", without causing tons of work - imagine for instance how someone like Thorsten is going to respond if I start telling him that his weather/ALS/shuttle code needs to be rewritten in Python, or that it has been automatically transformed, but that roughly 500-1000 lines of code need to be manually reviewed/debugged and tested, or that he needs to install some Python libraries to make everything work again.
Thus, the first step really is understanding who's got any stakes in FlightGear scripting, and to what degree, in what form and how that translates into workload/priorities (for instance, advanced weather being part of the base package is arguably going to be considered more important than some 3rd party aircraft outside fgaddon, or than the bombable addon - yet, the corresponding contributors will definitely yell at us if we break something that previously used to work fine with Nasal).
So, realistically, "porting scripts" isn't going to be a relevant discussion anytime soon.
If I was seriously interested in seeing support for other scripting languages, such as Python, my priorities would be different:
I would try to review what we have in terms of functionality, and who's involved, what must continue to work - with Python it seems, two important key players would be Curt and bugman, so that it'd be good to have them on your team. For them to be on your team, you must understand their goals, requirements and priorities.
Next, you would need to understand the priorities of those who have major Nasal stakes (e.g. the MFD/Canvas folks), who will also not be too happy if some commits revert much of their work to some pre-OSG/mid-2006 state.
And then there is the most obvious challenge, that of aircraft scripting - no matter if that means $FG_ROOT, FGAddon, fgmembers or any 3rd party hangars - this is the sort of stuff that is usually beyond the control of those making such changes, so that it is easy to break tons of aircraft without ever noticing it, because there is no good way to automatically "test" an aircraft and its features in isolation.
Thus, realistically, anything involving a new/additional scripting language will need to be aligned well within the constraints of the current environment, which means keeping Nasal for the time being, but detangling the mess this has become over time, and recognizing why this is so.
For instance, massive fgaddon/aircraft scripting and fgdata addons developed in scripting space are primarily a sympton of middleware developers wanting functionality that core developers don't prioritize developing (e.g. bombable or a dedicated weather system).
So, the surprising adoption rate that Nasal is, and has been, seeing is merely a symptom of the disparity for the functionality gap between what the core developer community can/wants to implement, and what middleware contributors, and end-users want to see/use FlightGear for, regardless of the reasons (e.g. some contributors don't appreciate having to deal with the devel list, while some core developers don't particularly appreciate having to deal with the forum/end-users), as long as this disparity exists, there will be an incentive for such "modules" or "plugins" to be developed, and it makes sense that scripting be used for this.
In other words, the use of scripting in FlightGear's base package, and aircraft/scenery in particular, is kinda symptomatic for the kind of modding functionality, and community, that FlightGear could -in theory- cultivate over time, which is surprisingly massive given the niche nature of Nasal as a language and extension mechanism, especially compared to more mainstream languages like Python or Lua.
Consequently, Thorsten's comments regarding the potential proliferation of addons and its ramifications is absolutely valid, and given how FlightGear scripting in its current "primitive" form has impacted FlightGear's evolution (think having a scripted weather system instead of a hard-coded one, think having a scriptable 2D drawing API for creating hardware accelerated MFDs, think having a scripted dogfighting addon etc), the ramifications of providing a more established scripting solution need to be carefully discussed from a variety of angles (think security, package/dependency management, threading, I/O etc).
What has been happening to many FlightGear subsystems over the course of the last 10+ years is that its developers recognized that they're falling victim to what an "architecture astronaut" would describe as the "singleton fallacy", aka, subsystems that were originally designed, developed and maintained with the implicit and hard-coded assumption of there ever being only a single entity/subsystem managing certain entities.
More specifically, this means in non-coding terms that simulation related concepts like that of an aircraft, FDM, autopilot etc are implemented in a way that prevents the simulation from ever having more than one instance of said component, which is kinda like the difference between using one sheet of paper per telephone number or creating a list to keep multiple phone numbers, or even maintaining a full phone book.
With FlightGear, there is actually a long and impressive history of this
Singleton Fallacy being incrementally recognized, discussed and then addressed over time, such as e.g. FlightGear being originally designed with there only ever being
ONE:
- CPU
- aircraft
- joystick
- FDM instance
- autopilot
- route manager
- view
- fgfs window
- fgfs instance
- machine running fgfs
- weather engine
- renderer
- scenery/terrain engine
These days, this is no longer a safe assumption to be made, and in fact it's rather restricting one that is turning out to complicate FlightGear's future evolution rather significantly, because the real world has evolved very differently - with multicore and multi-gpu hardware being available at Walmart's, it's no longer farfetched to imagine a distributed setup of FlightGear running spread across multiple computers, with multiple instances, multiple windows, each showing different (possibly independent) views.
When it comes to scripting, FlightGear is also designed for having a single mainloop that sequentially updates its subsystems and a single subsystem implement scripting support, all of which end up updating a single monolithic property tree.
This is unnecessarily complicating matters for people interested in more sophisticated use-cases, one of which would be using alternative scripting solutions.
But for any of that to become an actual option, FlightGear needs to evolve beyond the point where there is only a single scripting interpreter, in the form of just one Nasal execution context, because that's hugely chaotic from a scripting standpoint (just imagine all JavaScript code in all your browser tabs would be running in the same context, i.e. facebook, twitter and ebay code running all in one context).
We kinda saw the same thing happening with Microsoft Windows which used to have the implicit assumption of there only ever being a single user/account, whereas Linux evolved differently, as a multi-user system, carefully designed to support this use-case.
So far, FlightGear has -in many parts- accidentally been developed into a rather monolithic singleton-monster that has tons of hard-coded assumptions that make it look more like a product created by Microsoft than opensource afficionados - not unlike the first internet browsers, where you had to open a new instance to view another website (no support for tabs back then).
And this shows particularly in the reset/re-init department, i.e. the whole initialization sequence is a rather massive mess that is complicating any efforts to re-architect FlightGear to support other use-cases (or "startup modes").
This is one of the reasons why it is so important to deal with Nasal first prior to dealing with FGPythonSys: FlightGear has the hard-coded assumption that there will always be a full simulator session up and running, i.e. it really is much more akin to what Microsoft Windows used to look like in the early 90s than what Linux looked like (it already having an incremental, and configurable startup sequence using a combination of scripts and so called "run-levels").
If you don't recognize that this is the case and why that is the case, i.e. the legacy codebase that we have to deal with, you are only going to add one more problematic subsystem to FlightGear, with the major exception that this particular subsystem would be a massive technology enabler to help de-skilling (lowering the barrier to entry) contributing even more, with tons of resources available that would enable people to go literally crazy and use an extremely popular language in all kinds of places in FlightGear, without understanding the ramifications of doing so.
Almost certainly, this degree of scripting support would not just cause a proliferation of addons and optional modules, but it would also cause tons of challenges on the security front, and package/dependency management (imagine having to install Python modules to run a certain aircraft/scenery tile or AI scenario etc).
Over time (as in 3-5 releases), FlightGear would turn into a bloated, bug-ridden and fragile application that runs slower than molasses, lagging like hell, where deploying FlightGear resources would become a nightmare quickly. Just imagine for a second Python had been used instead of Nasal, and Thorsten had used all sorts of Windows-specific Python modules to implement his contributions (weather, ALS, earthview, shuttle), simply because his nvidia GPU only works under Windows, and he cannot do any testing under Linux.
In theory freedom of choice is a great thing, in practice that also depends on the repercussions - just look at the components where freedom of choice is actively encouraged and cultivated (3D models, FDMs, weather, GUIs, scenery engines, Rembrandt vs. ALS etc).
This sort of "freedom" always has repercussions - and that may be acceptable for end-user functionality, but it is hugely problematic when this freedom competes with other mechanism to develop the program in a consistent fashion - just look at what Nasal adoption has done to core development, and how FlightGear middleware development has been literally boosted by making scripting available to people who no longer need to patch/rebuild fgfs. In fact, look at the Canvas system it has literally
KILLED OFF any core development of glass cockpit gauges in its entirety. And at the same time, Nasal scripting and the Canvas system don't translate into immediate benefits for ongoing core development other than the end-user/forum community no longer having to deal with the devel list to implement certain functionality (and vice versa), and looking back in time, things turned out rather crazy looking at the messy situation.
Meanwhile, Nasal is massively complicating certain core development efforts, such as the reset/re-init effort, because it's a feature that is there to stay, and that must continue to work - but it's encouraging such a "free form" of contributing that the core engine does not even "know", let alone "understand", what a script is really doing (in terms of functionality/dependencies) - which is very much empowering for middleware contributors but a PITA for anybody wanting to modernize the simulation to better formalize and standardize certain features (as in not loading unneeded modules, keeping the garbage collector "pressure" low, or running scripts on different threads).
At the end of the day this also means that this freedom has repercussions beyond just being a PITA for core developers to deal with, because it is this very freedom of choice that is having repercussions on performance and complexity of the simulation.
Adding another, and potentially more popular, scripting option to the equation using the same approach is a particularly ill-informed move, especially because this is not just free-form functionality that is added, but functionality that can be used to add even more free-form functionality and so on and so on.
No matter if you hate Nasal or not, you cannot realistically make any progress with Python without also looking at Nasal and its shortcomings, and the very first steps will involve reviewing what is needed to make it incrementally optional so that parts of Nasal can be disabled/detangled and moved to other cores.
And for that to happen it would make sense to identify a common subset of people interested in FlightGear scripting.
Absent that, this will just be another "pie-in-the-sky" effort - that even if it should end up in the commit logs, it will be an optional feature that doesn't integrate well with the rest of FG, and that merely adds to it being even more fragile than it already is.
Thus, this whole idea has much more to do with being willing to make concessions and find compromises than doing actual coding, because the people interested in non-Nasal FlightGear scripting will inevitably need to team up with Nasal folks (experts!) to make all this work, without breaking tons of Nasal functionality. And for that to happen, there need to be benefits for the Nasal folks, such as groundwork that translates into improvements to the general FlightGear scripting integration - so that it can support multiple instances, languages, threads and use IPC to talk to the rest of FlightGear, quite possibly introducing multiple private property trees for certain subsystems to make the whole thing tangible.
But that is aking to asking two countries at war to start peace negotiations ...