@KL-666:
well, aircraft quality is not a function of scripting language features - in fact, Nasal provides many more features than are being used by 99% of its users, including core developers - to see what is possible, just look at some of the code written by people like mfranz, AndersG - or more recently Philosopher. We have people here who have written massive amounts of Nasal code, who still stand no chance understanding what's going in code that was written using meta-programming techniques.
So it's really not so much a lack of features, but rather a lack of understanding by people using it.
Entirely replacing Nasal also is not straightforward - quite a few people have discussed this over time (see the archives), and some of them really familiar with the internals of the project, but also with the type of Nasal use in FG.
Also, replacing Nasal with something else would be of very little use.
Still, there are people looking into this and considering this step at some point... personally, I don't see that happening within the next 5 years (at least) - simply because at that point, HLA is going to become increasingly mature - and then, it no longer matters what language you are using as long as it has HLA bindings, i.e. you could use Python, Ada or Java - it would no longer matter. But that will obviously cause new challenges for the project, because FG may end up being "too partitioned", and requiring too many different runtime environments (think python, lua, jre etc)
Thus, it would be a much more natural step to simply use cppbind and provide HLA bindings for Nasal, so that we can run existing code outside the fgfs main loop.
Extending Nasal to make it stronger, and more strict, would be possible - but at the cost of making it more difficult for people to use it.
Extending it would not even be very difficult, we now have a handful of people here who understand the internals of the Nasal engine fairly well, thanks to work that Philosopher has done (see $FG_ROOT/Docs/nasal-internals.pdf)
We could come up with restricted modes that enforce certain "best practices", either through Nasal-space interfaces using metaprogramming, or by coming up with a DSL for certain well-defined tasks, such as instrument modeling - that would provide all the flexibility needed, without sacrificing Nasal.
Like hvengel said, even JSBSim suffers from a lack of expressability at times - and at least there, Nasal is generally not considered a viable solution.
A while back, some core developers were considering to add a dedicated systems modeling component to FG, i.e. in the form of "SPICE".
You can probably find a few related discussions, i.e. see:
https://www.mail-archive.com/flightgear ... 27607.htmlThe point being, we cannot keep on reinventing the wheel - Nasal itself is already very much a niche language.
But thanks to TheTom's cppbind work, exposing new C++ systems to Nasal has become pretty straightforward.
So I guess that's something that would be worthwhile to reevaluate - but overall, the whole debate is kinda academic obviously, because you are just making generic claims and requests without necessarily contributing to the solution of the real problem. And thus, my responses are kinda pointless, too ...