Thorsten wrote in Sun Oct 09, 2016 6:53 am:It is not a goal to attract more developers by having feature X, where X is a different value for every FlightGear user.
Not sure whether abassign is doing it on purpose, but I think
this illustrates the 'X is different for everyone' point rather nicely. I guess we've also seen Lua and javascript proposed elsewhere (did I miss anything?)
(Come to think of it, I really do like Fortran... and it's very fast)
Obviously, I am absolutely provocative in a context of calm sea that seems to be the place of amusement by Fgfs developers.
I like to shake up the waves if this can lead to thinking in a less obvious way.Deepening the short text of my opening remarks, I can summarize as follows:NASAL was born to solve the problem of the need to be able to perform many tasks in parallel, efficiently and disconnected on the operating system.
The NASAL programs are generally very small and immersed inside the XML which is the interface to the structure of FGFS data.
NASAL suffers from being too specialized and therefore an unsuitable development which unfortunately makes it a scripting language related only to the environment of FGFS.
Throw away the NASAL development environment is still a shame because many of FGFS objects were written in NASAL.
Many find themselves well to develop the so NASAL environment because breaking the toy that pleases many developers?
The extreme specialization of NASAL indicates that it is not easy to find something alternative that can actually give evolutionary advantages to the developer of FGFS.
I think it was in January when it was proposed Python, I liked the idea, I write Python code since 2000, I use it for many problems and I am moderately satisfied. Unfortunately, with time, I noticed a big problem with Python is an efficient environment to manage individual processes, but it has no facilities that can comfortably handle multi-processes that need to exchange data. This applies to almost all procedural languages, as they are derived directly from the typical batch methods of execution of Fortran / Cobol / PL-1 / C. Perhaps only JavaScript makes sense as it is a language that is typically dipped into the XML structure. But I see a great advantage in this, its just-in-time compiler is very efficient, but then must still interact with the XML that is to bind with the FGFS core.
However, the basis of everything I do not like XML, I find it distracting and redundant, in the context of the Web makes sense as used to describe a single page, but when you have to build dynamic pages, the music changes! Of course there is the JavaScript that helps, but it is a language aimed at the execution of code on the client with the ability to send / receive, with only some method.
Javscript has good performance as can be compiled just-in-time, but the executable works only on a thread. With HTML5, something is changing by the insertion of WebWorker, but paliative care to enlarge the application area of a language born for other things.
I'd rather something that would eliminate the XML! He would put everything in one language that allows to have an efficient interprocess activities and essentially consists of small modules that can be easily synchronized.
Erlang being designed as PBXs programming language (
https://en.wikipedia.org/wiki/Erlang_(programming_language)) has many useful features in the FGFS ambient. Obviously has a very different programming paradigm, certainly a few of you you can mentally accept ... and so it is natural to ask the ability to have a connector that might serve as an interface between the FGFS and Erlang world. This is also true for other languages, such as Python. Personally I do not think it makes sense to develop libraries that emulate what makes NASAL, I see only a huge waste of time, while I would focus on the binding of those essential functions described in XML that can be substitute, and at this point, by a program Python or other language like Erlang.
At this point my reasoning is simple: to have APIs that allow to retrieve the XML functions that are the basis of all FGFS world. These can be in C ++ and then will be those who want to implement a certain environment to build its counterpart via the interface libraries of its programming language.