you are making this a "black & white" issue once again - highlighting the merits of hand-crafted GLSL code over generic Nasal code is obviously not going to convince anybody who's even just a CS undergrad - those are very different runtime environments. The octree/quadtree argument also still holds true, because that's exactly the method internally used by OSG - it comes as no surprise that a native/C++ implementation outperforms the Nasal implementation - however, your Nasal implementation predated any C++ efforts in this department, i.e. took place at a time when nobody was even bothering implementing stuff specifically for AW, so I'd say it did serve a purpose. It's obviously unfortunate that the project is not more coordinate to avoid such redundant efforts, but that's the way it is - and as you can see, people trying to do something about it, are having a hard time convicing others to adopt certain approaches
The GLSL examples you mentioned are prime examples for the fact that algorithmic optimizations beat any micro-optimizations (
including hand-crafted Nasal code) - but the whole discussion is kinda ridiculous in the context of simulating missions/adventures in FG, where you typically won't need the performance offered by GLSL (or even native C++ code), as you undoutedly know (and GLSL optimization passes are still fairly rudimentary too in comparison to sequential code).
The whole discussion was not about the "general principle" of generic code being slow - but rather about generic Nasal code not having to be inferior to hand-written "optimized" code given the current scope (MISSIONS/ADVENTURES). Coming up with "performance" as an excuse not to extend existing frameworks (namely Stuart's tutorial system) is not particularly compelling in this particular case
In fact, once you start using a generic framework (even just prototyped in scripting space) it can be replaced within minutes by using Nasal/C++ bindings. Something that is really difficult without using established programming techniques, like for example generalization (even just classes and objects).
So what you are basically saying is this: "I do not want to have to use/understand existing libraries/frameworks to play with these ideas", which is obviously fine - but it isn't much different from people coming here wanting to code a weather system in Nasal from scratch, and being told by you, that they /should/ preferably look at AW/LW - because that's exactly what it is doing. even if it may need to be extended for certain things ...
Remember those guys that wanted to develop a "combat/dog fighting" system for FlightGear, without wanting to use flug's bombable work ? Or the guy who wanted to do AI missiles without looking at xiii's work ? They didn't want to have _any_ advice, they would come up with arguments like improved flexibility, design, realism, performance (hello !) ... Deja Vu !
I take it that this is one of those cases where you are not easily convinced (i.e. where it may take anywhere from 18-24 months for the realization part to kick in...), but I think we can still help each other by focusing on areas where we do agree, rather than technicalities where we obviously disagree - because you always manage to turn every argument back into something that I never said, which makes you sound right again to the layman -- and I'd really prefer to spend my time differently, and I'm sure you do too