Every engineering tool and every solution to every problem has strengths and
weaknesses. The trick is to make the best advantage of the strengths and
find suitable work arounds to minimize the impact of the weaknesses.
Hopefully we are successful in this, but software development is always a
process and there is always room for improvement.
On the subject of nasal and the property system. What this gives us is the
ability to create all kinds of specific aircraft functionality or
functionality specific to a location or time or specific landmark -- without
having to compile code to model every system of every aircraft into one
massively huge executable. Nasal puts more power and control into the hands
of our content creators (aircraft, scenery, etc.) Nasal allows people to do
things never anticipated by any of our developers who write C++ code. The
property system allows us to connect new systems models with new graphics
and animations with new external communication protocols without changing a
single line of C++ code. An aircraft modeler can create the logic of some
system (electrical, hydraulic, de-icing, SAS, CAS, etc.) along with the
graphics models to support it (cockpit controls, cockpit displays) and never
have to fire up the C++ compiler. Recently I've been playing with
prototyping a pretty sophisticated auto-land system in Nasal. Hopefully
that will eventually migrate over to my UAS work and this same logic will
work in the real world (fingers crossed) :-)
The downside is of course that all of this happens outside the domain of the
C++ compiler so you lose the ability to automatically catch variable name
spelling or type errors, we don't have debugger access to step through nasal
code. But from the standpoint of minimizing our weaknesses, Nasal does
catch and report quite a few syntax errors. If there is a spelling error in
a property name you usually can catch that because your code doesn't do what
ti's supposed to do. We have the ability to generate a notice whenever a
specific property is read or written to, and you can insert print()'s into
nasal code to help see what's going on ... so there is quite a bit of
available structure to debug nasal code and property system usage ... the
tools are just a bit different.
Best regards,
Curt.
P.S. An alternative to our "open scripting/property" system might be a
"plugin" system which is what many proprietary applications offer. I bet if
we sat around and brain stormed for a few minutes we could come up with a
few disadvantages to that approach ... because every approach has strengths
and weaknesses. In comparison, because FlightGear is an open-source program
and because we have a desire to keep everything open and all our cards face
up on the table ... this can lead to some different engineering decisions as
we develop our software.
On Fri, Feb 11, 2011 at 6:57 AM, AJ MacLeod wrote:
> On Fri, 11 Feb 2011 08:43:43 +0000
> Alasdair <ali...@btinternet.com> wrote:
>
> > On an OT philisophical note..
> > Is , or rather, was the introduction of NASAL scripting a "Good Thing"
> > or can it be considered as the hugest abomination to ever befall the FG
> > World
>
> I really can't see how anyone with any experience whatsoever in developing
> models for FlightGear could fail to agree that the property tree coupled
> with nasal is an utterly invaluable and incredibly powerful, yet flexible
> and simple to learn tool that opens up an entire world of possibilities that
> just wouldn't be feasible otherwise.
>
> "Hugest abomination"... sorry, but I'd have to question the sanity or level
> of FG knowledge of anyone who would suggest that with any kind of
> sincerity...
>
> AJ
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org -
http://www.flightgear.org/blogs/category/curt/<http://www.flightgear.org/blogs/category/personal/curt/>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
