@Adam: You sound like you want to argue, whereas I previously stated quite clearly that share certain *assertions* you are making, as in adopting a more mainstream language like Python, Lua or v8/ECMAScript (nodeJS) would mean that certain problems (you mentioned the mark/sweek GC) would simply not exist, equally compared to Nasal, v8 definitely has a faster runtime profile, mainly because of the fact that it is creating machine code and as a fairly sophisticated code generator/optimizer.
However, like I -and others- stated previously - those are rather low-level Nasal issues, you literally need to write tons of systems-level code in Nasal to actually encounter any of those - what is really limiting FlightGear's evolution of scripting support is the legacy main loop and its way of having a single sequential vector with subsystems whose ::update(double dt) method is invoked accordingly - it is this that is causing stuttering, and that requires the FDM/AP to be running carefully interleaved, and it is also this that means that Nasal code may impact/affect not only the framerate/spacing (latency), but also other crucial systems (think FDM/AP).
And yes, that is exactly why I previously said it would be annoying to have the feeling that we're required to rehash previously stated comments, especially those backed up with facts.
You mentioned a number of wiki articles and how they're suffering from extensive quoting, here is the breaking news: I am the right person to complain to, because I happen to be the culprit copying relevant information over to the wiki, usually trying to retain references to the topics where certain things have been said - so that people interested in working on certain features, can more easily find the corresponding information. Besides, I am also the one who originally added the "Need for help (GC)" section that you are referring to (but that doesn't mean anything) - so you are preaching to the choir, because I am well aware of all of this, and quite a bit more.
So, let me reiterate: adopting v8/Python or Lua would only make FlightGear's architectural issues much more prominent than they already are - Nasal is quite a bit more prepared for working in a non SGSubsystem based architecture than is currently the case - however, Nasal's niche nature is masking/shielding and isolating the project from an even higher rate of adoption, which is not necessarily a bad thing because the majority of active core developers consider the sheer rate of adoption that Nasal scripting has been seeing highly problematic for a variety of more or less valid reasons - supporting Python or Lua according to the FGNasalSys runtime model would not be difficult, but it would be highly problematic due to the repercussions that would entail.
We have already exceeded the point where we can simply stop telling people to use Nasal (or Canvas!) in a certain way - however, this fgdata/fgaddon level scripting is more often than not highly problematic for people wanting to make progress in the core development department (imagine wanting to be able to save/load and resume flights, do proper simulator re-initialization, doing proper multi-instance state synchronization/replication for multiplayer or FSWeekend/LinuxTag-like setups).
These use-cases are next to impossible to support without also having a well-defined interface in place that all extensions mechanisms use - however, Nasal is so accessible and so easy to use that people will simply use it without paying much attention to core developer requirements - this problem would only be magnified by people using Python or Lua.
Obviously, that is not say that Python or Lua support would be bad - or that the Nasal/GC would exist today if we had access to Lua/Python - but the real issue isn't unlike JavaScript running in a tabbed browser with one thread per tab: You don't want flightgear.org JavaScript code to affect your home banking and vice versa.
In the case of FlightGear, the project has failed to come up with a properly isolated execution model that supports multiple execution contexts (think aircraft code vs. scenery code vs. gui code vs. systems code) and potentially multiple threads (despite Nasal having threading support) - bringing Python/Lua to the table would lower the barrier even more (think better tooling, documentation, examples) so that development of 3rd party aircraft/scenery addons would surely explode within months, causing a real issue for people developing the C++ code (Curt and others acknowledged on various ocassions that being the case)
In reality, Nasal is being widely used by content developers because it's way easier to use than JavaScript and will get the job done - but that also means that the solutions that people come up with may often conflict with goals that core developers have, but that would be no different should a different language be adopted - unless that language happens to actually run outside the main loop using an IPC mechanism and well-defined extension mechanisms so that there is no way for such scripts to interfere with the rest of the simulation in any adverse way.
Bottom line, I don't think anyone is outraged at all - Thorsten and I were just expecting that you would more carefully state your opinions/assertions or try to back up your statements with data/facts, so that we can review those and make up our own minds. With your kind of background (C#/Windows, right?) your help could definitely be useful for anything involving Windows testing/development or even just troubleshooting - equally, if you disagree with the quality of the docs (or the wiki specifically), you are invited to help clean up such articles by reviewing/improving such pages.
To explain myself: Let's assume you don't have much of a background in 3D rendering (which I don't), however you see something useful that may be of interest to people wanting to get involved, and you cannot realistically expect them to search the archives for postings made 5+ years ago (heck, because they may actually have a life) - but you may lack the time/insight (or motivation) to actually rewrite useful information (that may become out of date over time) - thus, the easiest way for me to preserve such information is to copy it over to the wiki, where it may linger until someone "adopts" such additions by reviewing/copy-editing and improving/maintaining them - e.g. see:
http://wiki.flightgear.org/Howto:Shader ... discussionNow, if you are familiar with 3D programming and effects/shaders in FlightGear, you won't find any of that useful and even consider it an asthetically unpleasant addition to the whole article - Thorsten keeps pointing that out, but most people not having Thorsten's background may actually find that helpful.
Equally, there are a number of core developers who have stopped documenting their additions to the core code in the form of dedicated README.* files added to $FG_ROOT/Docs, and who more often than not simply announce their additions well after the fact, without ever providing/updating or maintaining much if any documentation at all, so that quoting the archives may be the most straightforward way to "bootstrap" new articles by allowing wiki contributors to help review those additions and update the wiki accordingly, e.g. see:
http://wiki.flightgear.org/FlightGear_Qt_launcherAnd then there are "side-efforts" like FGPythonSys whose developers actively discourage quoting, but apparently still seem too appreciate that their efforts are being summarized that way until they find the time/motivation to actually create dedicated documentation, which can be seen be repeated postings on the forum/devel list linking back to such quote-based summaries:
http://wiki.flightgear.org/FGPythonSysLike you said, it's a pain/gain thing, and all of us have a life - which is why quoting is such an easy way to retain potentially useful information, until it is reviewed and properly edited/cleaned up.
For the full background on quoting, and why it is being used despite being considered problematic by most people, see:
http://wiki.flightgear.org/FlightGear_wiki:Instant-Refs(Ironically, that's using code written in JavaScript ...)
PS: Here's some friendly advice: don't try to argue with Thorsten, it will just end badly - if in doubt, look at my own posting history and any arguments between him and myself