20,741
edits
Modernizing FlightGear Scripting: Difference between revisions
Jump to navigation
Jump to search
Modernizing FlightGear Scripting (view source)
Revision as of 15:41, 8 October 2016
, 8 October 2016→Motivation
| Line 108: | Line 108: | ||
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. | 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). | 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): | ||
* Python has much better, and much more, end-user documentation (in dozens of languages), which we don't have to write/maintain ourselves | |||
* Python has much better tooling to help with troubleshooting, debugging and profiling code (think IDEs, integrated editors for writing/debuggnig code) | |||
* Python also is being actively developed/maintained by an enormous community of contributors, which is to say we don't have to bother updating it, or fixing bugs in the runtime | |||
* Python is, and will continue to remain, relevant in the software engingeering industry even 30+ years from now (aka, it is more future-safe, and its success/availability is not tied to a single entity/use-case or application) | |||
* alternate/different GC implementations | |||
* JIT compilation/optimization opportunities | |||
* excellent support for threading and running code asynchronously (well, the GIL is there) | |||
* much better accessibility, and much lower barrier to entry: if I need help with Nasal, it's kinda problematic to expect the other party to have the runtime environment installed - whereas Python is a rather common thing these days, and it is kinda hard to imagine systems without a suitable Python implementation | |||
* FlightGear adopting industry solutions, and standards, is likely to become more relevant to professional players/companies/contributors (think being multi-platform, using OpenGL instead of DirectX, striving for OSG/HLA or CIGI adoption) | |||
* FlightGear supporting Python for embedded scripting/extension purposes is more likely to be appealing to educational setups already working with Python (think universities, college, CS/SE courses or aerospace programs) | |||
* With Python, when compared to Nasal, there is an "infinite" supply of people familiar with Python who use it professionally at their day jobs, many of whom are quite willing to use a language that is used in the real world, whereas learning a "niche" language is unlikely to be too appealing to people who need to make a living coding, simply because putting "Nasal experience" on your CV is unlikely to impress anyone (unless you happen to be an ENT doctor...) | |||
<ref>{{cite web | |||
|url = https://forum.flightgear.org/viewtopic.php?p=296287#p296287 | |||
|title = <nowiki> Re: Nasal must go </nowiki> | |||
|author = <nowiki> Hooray </nowiki> | |||
|date = Oct 8th, 2016 | |||
|added = Oct 8th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Thus, one of the key questions commonly posed is "''How coupled are Nasal and the scripting glue in FGFS ? Is there a clean break, or if not, can it be refactored without too much pain into something that would allow end dev users to use whatever scripting language they prefer, or have many modules already writen in, etc. If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined'' "<ref>{{cite web | Thus, one of the key questions commonly posed is "''How coupled are Nasal and the scripting glue in FGFS ? Is there a clean break, or if not, can it be refactored without too much pain into something that would allow end dev users to use whatever scripting language they prefer, or have many modules already writen in, etc. If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined'' "<ref>{{cite web | ||