vitos wrote:I would really want to look on guy who could start to make highly precise celestial dynamics on base of unmantained second level interpreter language in situation of free choice. It's not personal, it's professional interest.
Don't worry: I don't feel offended at all, after all I didn't write the Nasal engine (and I also don't appreciate the fact that it's basically unmaintained at the moment) - and Thorsten also commented on Nasal not being suitable for this task, so I do share your concerns.
But obviously, Nasal is "Turing complete" and supports most modern programming paradigms. So there's nothing per se that you can't do in it.
Most issues making it really not suitable for this use case are related to the FlightGear architecture and its way of running its subsystems.
Also, I am not sure if you are aware of it, but there's a distinction between precision and accuracy actually.
Nasal numbers are all floating point with double precision, based on IEEE754.
I am not sure how you come up with the idea that Nasal is a "second level interpreter language"?
A conventional FG FDM will face the same frame rate-related issues because it is being run as part of the FG main loop (just at a higher rate due to not being interpreted), even if you were to fully implement it as a "standard" C++ SGSubsystem.
Even in C++, you would need to run the FDM in a separate process or thread to work around this and then synchronize output variables at frame rate.
Once you are using a Nasal worker thread to work around this, the only remaining issue affecting determinsm is probably the garbage collector - with the added advantage that you don't need to know a new programming language, and that you don't need to build any code from source. However, with Python (GIL) or Ruby you'd be off much worse actually.
There seems to be an increasing trend among non-programmers suggesting that Nasal is inferior and that "core C++ code" is superior, basically delegating the implementation of certain features to people who know C++ (i.e. core developers) - which is super-easy to do. But Thorsten has repatedly proven that there are many things possible in scripting space and if the frame rate is the bottleneck, then just look into doing your calculations in a worker thread instead.
Let me clarify, I have also seen Nasal worker threads being affected by (and also affecting) main loop performance (due to the GC) - but still, you can realistically achieve higher update rates by running some loops asynchronously.
In FlightGear, this is much easier to do using Nasal than with any other programming language.
Yes, obviously you can now simply wait for some C++ developer to step up and implement your fancy SFDM for you (I suggest not to hold your breath) - but in the meantime we could just as well look into using Nasal to come up with a workaround and explore its restrictions and try to make some progress in scripting space without depending on C++ work.
You would have NO EarthView addon if Thorsten hadn't implemented his own ideas in scripting space and waited instead for someone else to make require C++ changes. We would have NO advanced weather system if we had waited for some C++ developer to implement all of this in C++ code.
Yes, we have the freedom of choice. And yes, there are certainly better suited-languages available for "number-crunching".
Yes, you are free to use whatever language you want to implement a new special purpose FDM. But the decision will be up to the person looking into it. And hopefully their decision will be based on solid experience and not on some ill-informed rumours and comments found on the forum.
Using an arbitrary language to implement a SFDM as a separate process will require some form of IPC with the core FG process to exchange info (such as networking, shared memory).
By using Nasal, you don't need to worry about anything like that. The problems involved in using Nasal are well known (i.e. frame rate-limited and affected by the GC), but you'll get tons of advantages because Nasal IS THE programming language natively supported BY FlightGear.
Really, I am not trying to keep anybody from looking into C++ for this - if you can find/convince someone to do this in C++, GREAT! But, I am convinced that there's a fair bit of stuff that can be accomplished in the meantime, without having to wait for progress in the C++ department.
I am not saying this because I think Nasal can/should be used for everything (I don't!). But more often than not, I have seen people asking for some feature to be implemented in C++ space, that could just as well be implemented in scripting space easily - even by themselves, just by doing some reading. Basically offloading responsibility onto core developers.
However, the "most successful C++ feature requests" (because they got implemented QUICKLY!) I have seen, where based on solid facts and they were addressing shortcomings that couldn't be addressed otherwise.
Hat off to you (or anybody else for that matter) if you can come up with a SFDM in some other language. I just hope that it won't be coded in Visual Basic or .NET