I kinda agree with Curt, even though I don't need to be convinced that Python is going to have a major impact on FlightGear scripting.
I do disagree that this is going to be primarily based on the difference in syntax/language, i.e. that the main factor will indeed be the plethora of modules available, and excellent support from a tooling/community and maintenance standpoint.
You need to have tons of programming experience to appreciate language differences like those Curt mentioned, many people are unlikely to have that, and they will just use the "best tool" for the job, especially aircraft developers with little or no background in coding - i.e. whatever is available that suits their needs, and that does not have much of a barrier to entry associated with it.
Python can literally shine here (IDEs, debuggers, documentation etc - you name it, it's basically available)
Nasal is currently serving that purpose, especially compared to core development - and Python could serve that purpose, even if compared to Nasal scripting in its current form.
If you want to see a "case history", I am not sure anybody will be able to make a compelling case at all - even the migration to OSG was a controversial one, as was the introduction of the effect system, and we all know the debates that Qt5 has caused recently.
And even HLA used to be fairly controversial among core developers, the whole issue of being CPU or GPU bound is another recurring debate.
Nasal is not necessarily the best tool for many of the current scenarios it is used in. And there is a technology lock-in, i.e. the remaining number of core developers are very much hesitant to review/discuss and commit Nasal engine related patches. With Python, the situation is hugely better - i.e. maintenance of the interpreter would be no longer a responsibility that FlightGear would need to handle.
Adopting "standard" solutions (like OSG, Qt5, HLA or CIGI) is generally a good thing for the project in the long term, and OSG is probably the most compelling "case history" you can find so far, with HLA only just about to become one.
Thus - within the reasonable use cases of scripting in FG - what can Python do Nasal can't? If all that Python does is enable misuses of scripting, it's not that useful.
right, but to be fair, even Nasal has been used for implementing unprecedented things, including a dogfighting addon, but also a weather simulation engine - and as you know yourself, a number of core developers didn't/don't agree with Nasal as an implementation language.
The thing is, Python is going to make even more things possible, without much oversight from the project (core developers and project "leaders") as a whole.
After 5+ years of contributing to FlightGear, you may have arrived at a solid understanding of what technologies to use in a certain context (think Nasal, properties, property rules, fgcommands, jsbsim systems, effects, shaders etc) - but many other people, including current contributors, don't have such a solid understanding, especially not in a novel technology stack. We are already seeing that in the way the Canvas system is being used by aircraft developers to implement features in a fashion that prevents them from being compatible with other features, such as the "flight recorder", "multiplayer", "multi-instance setups (FSWeekend/LinuxTag)" etc
Python adoption is going to make that even more prominent, unless it is based on an IPC stack (like HLA) that forces people to think about the problem, or we're just adding to the mess we are seeing in Nasal space already.
At the end of the day, I am not trying to convince anybody here - in fact, we can just go ahead and prototype Python integration using Curt's suggested subset of property tree functionality, possibly in conjunction with Stuart's and Mathias' HLA code, and see how that will evolve over time.
If I am wrong, that would be great - if I am right, we will be seeing more and more 3rd party addons using approaches, and technology stacks, that the FlightGear project (aka core developers) would be very much hesitant to adopt/support in stock FG, at which point the project is going to increasingle divide/split up, because the motivation for people to join "us" (the community of contributors) may not be all that compelling, especially given that the GPL is dead-easy to circumvent LEGALLY using HLA/RTI, and that we will see more and more debates about problematic approaches with tons of Python modules used in "addons", and a plethora of potential issues arising from that (security, deployment, backward compatibility).
Nasal scripting is already not very formalized, and compared to core development it's frankly a huge mess, unless the corresponding code is written by experienced FG core developers, like TheTom.
I still appreciate having the theoretical discussion, to exchange the pros & cons of adopting/supporting Python, even just as an option like Curt suggested.
Then again, there isn't much that hasn't already been said in this context, by people much more familiar with FG/Nasal and scripting internals than most of us, e.g. Andy or Melchior:
http://wiki.flightgear.org/Nasal_success_storiesMelchior Franz (former Nasal maintainer) wrote:Do we want two similar languages embedded in fgfs side by side, so that people can choose? Hell, no! This is just needless bloat ("re-invention of the wheel" is an understatement!) and it would be a source of confusion. On which basis would people decide for one or the other? Would we expect them to evaluate both languages and to find out which works better for them? Or just take a random pick? What would be the advantage? That people who don't like Nasal can have something that's quite similar? Doesn't sound smart. So, having both in FlightGear is clearly not desirable.
That is not to say that Python support could not be very empowering, but let's not ignore the potential issues arising from the increased popularity of FG scripting that /might/ bring over time (and I assert that this would be visible within 2-3 release cycles).