by Hooray » Fri Sep 09, 2016 11:15 am
Also, to be honest, given Thorsten's track record, most of us happily provide 1:1 support when it comes to git related questions - I think, I've seen a handful of long-term contributors explain git concepts/usage to Thorsten on the forum and the devel list, so at some point, it makes sense that git feels "superior" or at least very much beneficial in comparison to svn - but the average fgdata/fgaddon contributor is not supposed to be required to be familiar with coding concepts and distributed source code management systems. Thus, it really does make sense to use svn, to help lower the barrier to entry for those entirely new - especially people interested in artwork.
People able to write code, or code complex FDMs in XML, are unlikely to be bothered by svn/git either way.
Anyway, like Thorsten said - at some point, there's kind of a legacy infrastructure/code-base that we inherit - just imagine for a second somebody would announce that they're going to replace all Nasal code used by the shuttle with a rewrite in Python - that's unlikely to be too popular with most folks who've been working with Nasal so far, simply because of all the legacy features that must continue to work, and the barrier to entry is much lower, too - with Nasal being integrated right into fgfs, while Python support would require building a custom set of topic branches (see bugman's experimental work).
For pretty much the same reason, the Qt5 GUI port is considered controversial by some folks - because we do have an existing code base, and huge set of XML dialogs that must continue to work, rewriting all that functionality from scratch is not exactly feasible/worthwhile, certainly not as long as the underlying technolgy stack is intended to remain "optional", i.e. such an effort would tie up considerable resources in the light of ultimately still being optional, whereas coming up with a parser-based approach (no matter if that means C++ or Nasal) is much less work in comparison - which is not to say that Qt5 would not be superior on technical grounds (it definitely is, and always will be), it just means that the workload caused by such an effort may be hugely underestimated by the corresponding parties - in particular referring to the main code base, its single-threaded nature, and having to make Qt5 work without introducing even more threading related segfaults.
Thus, the fgmembers/fgaddon situation isn't exactly unprecedented - we have numerous examples of people working towards conflicting goals and using incompatible technology stacks - ultimately, it's software evolution at work, i.e. survival of the fittest.
However, given that FlightGear is suffering from a lack of resources like manpower and technical skills/expertise, it is likely that approaches that don't require an enormous technical investment upfront will continue to persist, not due to being technically superior, but due to causing not as much work, and providing an option to work "well enough".
As a matter of fact, this is why and how the Canvas system managed to make hard-coded glass displays obsolete, despite not providing comparable performance "out of the box": The canvas system lowers the barrier to entry so much that even people that are not familiar with C++ and OSG/OpenGL programming, can implement sophisticated glass cockpit systems without ever having to write a single line of C++ code, let alone patching/re-building FlightGear from source.
Which is to say that the Canvas system has managed to make 10s of KLOC of legacy OpenGL code obsolete by now, i.e. functionality that can be re-implemented using a fraction of the code written in scripting space (think NavDisplay, Map dialog, wxradar, agradar, groundradar, HUD, 2D panels etc).
To see for yourself, just look at the staggering amount of highly complex MFD developments (space shuttle, airliners) that were considerably boosted by providing the Canvas system - not a single of these developments required any major C++/core developer support, despite native OpenGL/OSG code obviously providing much better performance in comparison.
Now, Uncle Bertram may point out that OSG/OpenGL code written in C++ will always beat any Canvas code implemented in Nasal, but that's not the point - that would just as well apply to hand-written assembly code, too - optimized for each platform/OS and GPU. But we're still using abstraction layers to keep the workload manageable.
Equally, we've seen people suggesting/requesting on various ocassions that the advanced weather system be rewritten using native C++ code - but that never happened for obvious reasons: it would cause massive work, and provide a poor pain/gain ratio in comparison.