Hound dog departed

[bomber]

So it's got very little to do with making flightgear better but about the amount of time and effort you've put in ?

Do you really think it's wasted time ?

I'll give you an example of why I think your time will not have been wasted. At work when I do a drawing that takes maybe a couple of days and for some unknown reason it becomes corrupted or even deleted I find I can redo the design in a fraction of the time it originally took. This is because the time and effort isn't in the doing it's in the thinking, the iterative process of 'well that didn't work, how else can I do it'..

My first Lancaster model took 3 months to model, a lot of learning about the plane and visiting it.... I deleted it and started again.... it took 3 weeks....so I deleted it and started again... it took 3 days.

The fear that you'll lose something is ungrounded, you'll take all that knowledge with you and redo things and you'll do it quicker and better than you've got at present.

You're young, I'm 52 and not scared of change... why should you be ?

[D-ECHO]

So now we've been happily talking around the problem, though I think it's a VERY important thing to consider. Who does the change? For sure there are many good reasons for switching to nasal but let's be realistic. Either we have to find people re-writing the (tons of ) code because I don't think there will be many aircraft developers jumping on it "Yeah, something to do!" or we have to be able to make a script to convert it all to python WITHOUT BREAKING A SINGLE AIRCRAFT FUNCTION. And then there is still the problem about people (like Joshua) having spent hours learning nasal and now are for sure VERY HAPPY to have to spend hours again to learn a new language, python.
Let's don't talk around the problem, if there are no senseful answers it doesn't seem to be possible.

[IAHM-COL]

If the core developers deprecate even the idea of implementing python from the very beginning (on multiple accounts, and under multiple arguments including security, fantasyland, and others), I am certainly not surprise that no-body takes the task at hand or volunteer at it.

why writing just 1 line of code into a feature that has already been vetoed?

Your question is "who will implement the change"?, but my point is, why would anyone try to implement the change when they already said: <<we are not interested so>>.

Let's assume it takes 1 month of a highly skilled c++ code familiar with python embedding (for which there is lots of good information on line into how to expand your c++ base to be able to include python). Now what? Can this change be implemented in FG? So far the answer is: Do not even try. That's 1 month that person will better spend somewhere else, I think.

(unless you are keeping a hostile fork, such as bugman is doing)

[D-ECHO]

I'm talking about porting the scripts

[IAHM-COL]

You also seem to be in the posture that it should be a complete and immediate replacement. As in:

From now on, python works and nasal does not.

Such situation is insanity. I can't understand why are you thinking that way.

It should be to the very least an smooth transition.
For the future maybe 5 years or so, nasal should still operate as expected.
People willing to code in nasal could off course do so. But I am certain most will jump fast into the improved capabilities and cleanliness of python-code.

Possibly so, slowly the code-base of nasal shrinks to very few case scenerios, and then "maybe" it becomes, much later... after years of coexistence, a reasonable time to shut down nasal... if you wish.

Now. I am a person that prefers options. (I guess that's one of my main reasons of being linux-guy).
What's the problem if FG can interpret two scripting languages, for a much larger time?

And the developers get the option to use one, or a mixture of both in their codes?

[KL-666]

Let's don't talk around the problem, if there are no senseful answers it doesn't seem to be possible

The answers can not and should not be given now, not by me, not by you and not by Thorsten. We are all assuming things, without knowing. Therefore do not blockade an investigation into the matter, but let some young bright people gather together and come up with a plan and what it takes to get there. Only then one can judge if it is much work. Not now.

Part of the plan can be a phasing out period of 10 years, which it0ouchpods may not find a problem anymore. Btw, he would have wasted much less time if nasal had been python currently. If he wants to do something other than flightgear, he could grab python for it. Nasal is unfortunately useless in the real world.

Anything said now about the amount of work is pure fantasy (to speak in Bugman terms). So shouting it is a lot work is not only silly, but by the tone it is done on the other forum, it scares away young bright people who now do not come forward to offer their investigative work.

Kind regards, Vincent

[IAHM-COL]

I-ECHO Hooray (not D-ECHO)

https://forum.flightgear.org/viewtopic. ... 30#p296287

Why is Python the language (aka without libs) superior to Nasal the language - besides the fact that you're more familiar with the first?

I think, the common line of reasoning is basically this:
<devils-advocate mode="on">

• It has much better, and much more, end-user documentation (in dozens of languages, possibly even Elvish ), which we don't have to write/maintain ourselves
• it has much better tooling to help with troubleshooting, debugging and profiling code (think IDEs, integrated editors for writing/debuggnig code)
• it 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
  alternate/different GC implementations
• JIT compilation/optimization opportunities
• excellent support for threading and running code asynchronously (well, the GIL is there)
• FlightGear adopting industry solutions, and standards, is likely to become more relevant to professional players/companies (think being multi-platform, using OpenGL instead of DirectX, striving for OSG/HLA or CIGI adoption)
  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" on your CV is unlikely to impress anyone (unless you happen to be an ENT doctor...)

</devils-advocate>

[KL-666]

I can advise everyone to read the posts of Hooray after the one quoted above. Hooray is exploring ways to open up the core code for other scripting languages. Therefore nasal must first evolve from "the" scripting language to "one of the" scripting languages. A very important step in my mind, even if you later decide not to add other scripting languages.

Also he emphasizes the importance of getting scripting languages in separate threads. Also an important step to do before other languages can be added safely.

Good can-do thinking Hooray!

Kind regards, Vincent

[Lydiot]

So now we've been happily talking around the problem, though I think it's a VERY important thing to consider. Who does the change?

I think that was part of my point actually.

You also seem to be in the posture that it should be a complete and immediate replacement. As in:

From now on, python works and nasal does not.

Such situation is insanity. I can't understand why are you thinking that way.

It should be to the very least an smooth transition.
For the future maybe 5 years or so, nasal should still operate as expected.
People willing to code in nasal could off course do so. But I am certain most will jump fast into the improved capabilities and cleanliness of python-code.

So my questions then are what arguments can be made to those who currently code for FG to change over to Phython AND to make the two compatible in practice, as well as what arguments can be made to those who aren't currently coding to start doing so.

I really think that from the standpoint of moving forward it's critical to create an argument that includes the details of your solution so that people can be convinced to migrate. I don't think those who currently code in Nasal will be convinced by simply stating the above (and I don't disagree with you), I think they need to see a much more concrete solution in order to get on board with a change.

Perhaps Hooray is on to something.

[IAHM-COL]

that includes the details of your solution

I have no solution. We are in the same boat here Lydiot. I am not a developer, and thus I cannot code a solution for this.