Like Thorsten said already, "less Nasal" can be accomplished by getting rid of old or duplicate code, also the density of code can be increased easily by using some more general solutions. Compared to much of the Nasal library code in $FG_ROOT/Nasal, the LW is somewhat more explicit and verbose and doesn't take any "short cuts". A while ago, I already provided a number of examples to reduce large Nasal loops or function bodies in LW to a more compact form. Some of these examples I added to the Nasal tutorial for future reference.
Thorsten said, rightly, that these are technically more complex (while less verbose though) - I think the most important thing is that Thorsten is able to maintain his own code
so it's obviously his call.
But I'd volunteer to convert some of his code to such a more compact form if he wants to give this a try.
Regarding maintenance, I also share the view that "less Nasal code" is an important ingredient here. But not necessarily "more C++ code" though. If there is Nasal code that shall be moved to C++ space, the "compat_layer.nas" file is probably a good pointer.
Also, I find the LW code getting increasingly "accessible" after being split into separate files ("modules"). So this would probably be one of the easiest ways to improve the maintainability.
Also, some declarative stuff could be moved out of Nasal space into PropertyList XML files and loaded on demand. Also, anything that is related to GUI handling could obviously be moved out of the local_weather directory and directly embedded inside GUI XML files.
I can run LW without any major performance issues here, that's on an i7, 8GB, GX260M notebook. Some issues are quite obviously not related to the Nasal scripts running, but to the Nasal engine itself.
So, for complex Nasal systems, like Thorsten's local weather system or flug's bombable addon, it will probably be worthwhile to eventually look into the core Nasal interpreter, i.e. its known issues (garbage collection):
http://wiki.flightgear.org/Improving_NasalSo I agree with Thorsten here, prematurely optimizing things by moving Nasal code into C++ space just "because C++ is faster" would probably offer very little gain. It took Thorsten quite some time to convince me here, we exchanged quite a number of messages on benchmarking Nasal code and his local weather code in particular, he actually provided a list of likely hot spots, and I couldn't find anything that he didn't know about already.
Scripted code offers certain very real benefits over hard-coded C++ code. Thorsten could develop most of his code without having to go through building FG from source or without having to hack the C++ source code.
We would sacrifice lots of flexibility by moving more and more stuff out of Nasal space into C++ space, just because C++ is somewhat faster. Any Nasal code that is moved to C++ space is unlikely to be easily maintainable by Thorsten any longer. So, I'd be really careful about giving in to that "knee jerk reaction" of reimplementing stuff in C++ just because it feels "more natural" from a core developer's perspective.
Yes, there are huge amounts of Nasal code now, but this isn't to say that Nasal is the primary bottleneck.
Also, Nasal supports more programming styles than the ones currently adopted/used in FlightGear, or in LW in particular.
Multi-threaded programming, and functional programming in particular, are both supported by Nasal, but currently not at all used by any FlightGear scripts. Yet, both of these techniques would have the potential to help complex scripts more or less.
Functional programming in particular, can make scripts much more expressive, dense and succinct. This programming style feels quite natural to any mathematically inclined person. In addition, functional programs have the advantage that concurrency can be exploited more easily.
So there are options available to obtain better performance and maintainability while still keeping code in Nasal space, just by adopting a different programming technique.