Linked by Thom Holwerda on Sun 12th Aug 2012 22:16 UTC
General Development "I cannot help but speculate on how the software on the Curiosity rover has been constructed. We know that most of the code is written in C and that it comprises 2.5 Megalines of code, roughly. One may wonder why it is possible to write such a complex system and have it work. This is the Erlang programmers view."
Thread beginning with comment 530918
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: How
by gpsnoopy on Mon 13th Aug 2012 10:03 UTC in reply to "How"
gpsnoopy
Member since:
2007-04-17

I was reading the JPL C coding guidelines the other week. While I can understand the rationales behind most of them, it did look very unpractical. Like for example the no recursion rule, as some very powerful data structures require recursion to be implemented efficiently (trees anyone?).

Luckily, I got to talk to someone who used to work on static code analysis on NASA code. Two things struck me:

- They don't always follow their own guidelines. As they can lead to worse and buggier code (see the recursion example above).

- These guidelines are written by researchers and paper pusher. The actual coding is done by an entire different group of people. IMHO it shows in the guidelines, as they sound nice in theory but I can see so many problems with them in practice.

While NASA (and similar agencies) are always proud of their strict rules and rugged procedures to produce perfect code and spacecrafts, one has to remember that these are also part PR stunt and that reality is always a lot greyer.

Reply Parent Score: 2

RE[2]: How
by kwan_e on Mon 13th Aug 2012 13:18 in reply to "RE: How"
kwan_e Member since:
2007-02-18

it did look very unpractical


It's even more impractical if a coding error requires tons more rocket fuel and metal to fix.

Reply Parent Score: 3

RE[2]: How
by viton on Mon 13th Aug 2012 16:04 in reply to "RE: How"
viton Member since:
2005-08-09

as some very powerful data structures require recursion to be implemented efficiently (trees anyone?)

Recursion cannot be checked statically.
You can emulate recursion iteratively with custom controlled stack. It will also be faster on RISC architectures. Recursion is dangerous (it could break through the limits of allocated stack for example)

As they can lead to worse and buggier code (see the recursion example above).
Bad example. Recursion (via recursive calls to itself) doesn't work nice with modern hardware anyway.

Reply Parent Score: 2

RE[2]: How
by ilovebeer on Mon 13th Aug 2012 17:28 in reply to "RE: How"
ilovebeer Member since:
2011-08-08

While NASA (and similar agencies) are always proud of their strict rules and rugged procedures to produce perfect code and spacecrafts, one has to remember that these are also part PR stunt and that reality is always a lot greyer.

Wound you mind elaborating on why you think NASA having struct rules & procedures is "part PR stunt"?

Reply Parent Score: 2

RE[3]: How
by zima on Sun 19th Aug 2012 23:56 in reply to "RE[2]: How"
zima Member since:
2005-07-06

Now, we can't know what he meant... but remember that NASA, at the very least for large part of its history, was (also!) about PR - that was basically the point of the Space Race after all.

http://en.wikipedia.org/wiki/Rogers_Commission_Report#Role_of_Richa... - and those observations shed some light on the organisational adherence to the professed values of NASA, and integrity of the rules themselves. Yes, 2+ decades ago, but... http://en.wikipedia.org/wiki/Columbia_Accident_Investigation_Board#... - and not long after, pushing for quite flawed Ares I (inherent vibrations of the "stick" and unlikelihood of successful escape system deployment - in the event of catastrophic failure, the parachuting descend would likely happen in a cloud of burning metal particles; generally, continuing with SRB - which got human-rated only by lowering the standards).

Even the whole STS programme (and not terminating it at a good opportunity in late 80s...) can be also seen as one big stunt - sure, it looked awesome (kinda like from... our dreams http://www.osnews.com/permalink?526126 ), absolutely, but... it didn't really deliver on any of its goals, as originally advertised. Moreover, it was probably conceptually obsolete before even seriously getting on the drawing board (considering that autonomous, unmanned rendezvous and docking was done already in the 60s)

Other space agencies, kinda similar... even if they managed to be somewhat more sensible occasionally (like how the Russians pragmatically used, and continued using, the first operational ICBM http://en.wikipedia.org/wiki/File:GPN-2002-000184.png ...and not nearly only for manned launches, eventually making it "the most reliable [...] most frequently used launch vehicle in the world" http://www.esa.int/esaMI/Delta_Mission/SEM8XK57ESD_0.html - a century of service seems well within its grasp, considering just inaugurated launch complex in French Guiana), there were still brain-farts here and there... (why exactly did the Soviets run, in parallel throughout the 70s and 80s, three+ separate manned programmes, vehicles? In the end, only one ever actually launched with people on board; and that's not the only such example, they didn't have a centralised governing body in the style of NASA, there was often a lot of infighting between the bureaus - but a) that was a horrible way of doing those things b) still, the irony of the communists doing it competition-style is priceless ;p )

PS. Present (luckily not planned ones) US spacesuits are perhaps also an illustrative example... wth, from where did the thought come that went into their core design? A basic difference in concept & construction (entering into vs dressing in a spacesuit - treating it in the former example as what it is, a miniature spacecraft) means that while donning Orlan is a dozen or so minutes deal, with US suits it takes over an hour, for no real benefit (only greatly complicating procedures and likelihood of failure).

Edited 2012-08-20 00:15 UTC

Reply Parent Score: 2