20,741
edits
Nasal for C++ programmers: Difference between revisions
Jump to navigation
Jump to search
First official Nasal.EXE release !! - i.e. covering a more and more common debate: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html
(First official Nasal.EXE release !! - i.e. covering a more and more common debate: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html) |
|||
| Line 109: | Line 109: | ||
On the other hand, Nasal really is a powerful tool in FlightGear, and if you find that something should, but currently cannot, be done in Nasal space, it is extremely easy to add support for new features to the Nasal engine using extension functions or property listeners to trigger C/C++ code. | On the other hand, Nasal really is a powerful tool in FlightGear, and if you find that something should, but currently cannot, be done in Nasal space, it is extremely easy to add support for new features to the Nasal engine using extension functions or property listeners to trigger C/C++ code. | ||
=== Shouldn't we favor C++ over Nasal? === | |||
Please, if you do know C++ and the SG/FG code bases, you are obviously invited to contribute directly to the core source code - nobody is trying to keep people from contributing there - see [[Howto:Start core development]]. | |||
That said, among some core developers, there's apparently the misconception that other FlightGear contributors increasingly favor Nasal over C++. | |||
Obviously, some core developers are particularly concerned about the amount of Nasal code added to FlightGear (i.e. the base package) recently. | |||
So to put things a little into perspective, trying to explain the current situation: | |||
* We must not miss the fact that these are complaints about the plethora of Nasal code added to FG by '''non-core developers''', these are usually people who don't know C++, who don't know the FG/SG code bases and who don't know how to build FG from source or at least who don't regularly rebuild a custom binary from source. | |||
* It's not that C++/core developers suddenly decided to stop writing C++ code and instead use Nasal, Rather, the opposite is true, there are still a number of core developers who refuse to use Nasal at all and stated so publicly. | |||
* So let's face it: How many "qualified" Nasal coders can you name? How many Nasal developer are even able to program in C++, are familiar with the STL and Boost? How many Nasal coders would be potential C++ core developers? And then, how many of them are able to use git and gitorious? How many are actually able to build FG from source? | |||
* For example, up to a certain point, the local weather system has been entirely developed without ever building FG from source, and without using git. | |||
* While writing Nasal code is obviously much simpler than writing C++ code, writing really good Nasal code is still difficult - on the other hand, writing really bad code in Nasal is much more difficult than in C++. | |||
* Just because someone is able to write a script in a dynamic, untyped, garbage-collected programming language doesn't automatically mean that they are able to write quality C++ code that can be added to the main code base, using dependencies like the STL, Boost, OpenGL, OSG etc. | |||
* The truth is, there's TONS of Nasal code in the base package that has an impact on performance, because of the way it is written, not primarily because of the well-known GC issues. | |||
* Often, most high quality examples of Nasal code were written by people who also happened to be core developers. | |||
* So it's way too simple to say that forum users are writing Nasal because they feel it's "just better". And, clearly, nobody on the forum wants to replace fgfs.exe with "nasal.exe"[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html]. It's really just polemics to suggest that forum users feel "core=bad" and "nasal=good". | |||
* Yes, it's true, Nasal code makes the main loop non-deterministic, i.e. the garbage collector - but there are people currently working on improving the GC: [[How the Nasal GC works]]. | |||
* On the other hand, we also have tons of C++ code which is not using smartpointers and yes, which is leaking memory - in other words which is "non deterministic", too (definitely from an embedded developer perspective). | |||
* Now "fixing" non-deterministic Nasal code involves re-implementing a single self-contained component (a single C file actually, with ~320 lines of code), the Nasal GC - or even just adding support for an existing GC implementation. Which is something that is currently being worked on by another contributor, so that the GC impact will eventually be not as severe probably. | |||
* Making the rest of FG stop leaking memory involves much more work unfortunately. | |||
* And then, we have threading-related segfaults because of C++ code, where running the same binary with the same arguments sometimes works, and sometimes simply doesn't, and crashes FG. | |||
* Really, writing badly performing C++ code is much easier than writing bad Nasal code. There are only a handful of ways to crash FG from Nasal. | |||
* And writing/reviewing Nasal code doesn't involve the same skills that C++ programming requires. | |||
* Nasal code doesn't need to be reviewed and committed by core developers - it can be reviewed by other Nasal programmers. | |||
* And, we've seen quality C++ code submissions which ended up not being committed or even reviewed. | |||
* Deploying contributions written in Nasal is MUCH simpler, and doesn't involve any core developers! | |||
* When compared to Nasal, we have less people in the FG communtiy who know how to program C++ and who know how to build FG from source, that's what it all boils down to, really. | |||
* We cannot possibly replace or rewrite the sheer amount of scripted code we have, and looking at all the features implemented in Nasal, most of them cannot as easily, or simply shouldn't be implemented in C++ at all. After all, FG is all about being open and extendable for end-users. | |||
* It's true, we get to see an increasing amount of features being developed in the base package. Which is a good thing because not every conceivable feature can be developed by core developers in C++ space. Many of these features were developed in Nasal because it was possible and simple. | |||
* Contributing to the C++ code, simply isn't easy. Which is not meant to sound negative: it's a long-standing issue. Also, anything coded in C++ is obviously not as flexible and configurable, not without making excessive use of properties and XML config files, and then there are still ugly corner cases like tied properties or properties only read once during startup, or tags that only support static value and no properties at all. | |||
* The other problem is that there is simply a shortage of active C++ developers familiar with the project and able to build from source. | |||
* So, it is MUCH easier to develop MOST end users features in scripting space than in C++. That's one part of the reason why we sometimes get to see tons of new features showing up in the base package, while only very few new features show up in the SG/FG repositories in the same month. | |||
* Anybody complaining about the degree of Nasal additions to FlightGear, needs to keep in mind that even developing just a single feature in C++ space takes often much longer (and involves more people, if they don't happen to be core developers), this applies especially to inexperienced programmers. | |||
* So whenever somebody is complaining about the plethora of scripted code in Nasal, it is a good idea to keep the user (non core developer) perspective in mind: people are trying to bring changes to FlightGear, to contribute in a meaningful way, without blocking each other and without facing a steep learning curve, without being limited by the number of releases per year or by core developers having some time to mentor them. | |||
* Nasal provides a very real chance for people to innovate and develop features without depending on core developers and without having to be able to build FG from source | |||
* We have tons of features that we would not have without Nasal in the first place, including the local weather package and the bombable addon - these are features that probably would have never been developed by core developers. Frankly, because C++ is just too low level a language for such things and because features implemented in C++ space often end up there because someone cared enough to implement them in the first place, not because some end user "requested" them. | |||
* if the primary concern is really shifting the development focus to increased use of C++ instead of Nasal, then, it needs to be made much easier for new developers to get involved, which includes reviewing patches and merge requests. At the moment, the project simply isn't there yet - which mostly boils down to a lack manpower obviously. | |||
* Also, what's the alternative here? That people stop developing their own features just because we don't have enough active core developers who can provide help and support to newcomers and actually mentor them to a degree such that their patches can be reviewed and committed? | |||
* This is not a problem about Nasal at all, it's a manpower and accessibility problem: due to FG's flexible design we have more and more users who want to add to it and extend/improve FlightGear. This however isn't particularly straightforward for people without solid multiplatform, C++/OOP, programming experience - they have to face an extremely steep learning curve. Nasal simply provides the lowest entry barrier here. | |||
Seriously, people who tend to write code in Nasal rather than in C++, usually do so for a reason - with Nasal we have: | |||
* pretty good documentation | |||
* a fair number of beginner tutorials | |||
* lots of examples and snippets | |||
* people able and willing to help | |||
* dedicated sub forum | |||
* experienced Nasal coders mentoring new contributors | |||
* a fully working runtime environment, i.e. no need to set up a build environment | |||
* no tedious merge requests necessary, or complete code reviews | |||
* no need to wait for a new release to use and distribute a new feature (remember, just 2 releases per year) | |||
In other words, if you are a C++ core developer who wants to see more C++ code added to FG instead of Nasal code, try to beat that! ;-) | |||
So what we are seeing, are more or less active core/C++ developers complaining about features getting implemented in scripting space without volunteering to implement them in C++ space instead. | |||
Given the shortage of active C++ developers, and an increasing number of people being able to write Nasal code (and develop moderately complex features in scripting space) it isn't really surprising that we are seeing so many features being implemented in Nasal currently. | |||
Really, what we've been seeing is a simple form of evolution where the project dynamics adapted to the situation at hand, by recognizing a lack of core developers and shifting the focus to where the manpower is, which clearly is not the C++ source code unfortunately ... | |||
<references/> | <references/> | ||