SpaceX News

ladajo · Post by **ladajo** » Mon Nov 19, 2012 9:11 pm

Skipjack wrote:
C++ to Mars? Yuk.
So you would write the entire code in assembler?

Ahh, the lost art of Hex.

ladajo · Post by **ladajo** » Mon Nov 19, 2012 9:16 pm

Also reminds of a chat I had standing in Shuttle Processing with a shuttle engineer. She was lamenting the lack of availability of "fossil" processor boards in the market. However, she was thankful that someone before her had had the foresight to buy up a pile-o-spares for a rainy day. She thought that without that pile-o-spares, the shuttle program may have had an earlier shut down date.

Nothing like rocketing a few Cosmic rays through your complex high density 3D processor card. Tends to increase the Hourglass Fluxrate.

Skipjack · Post by **Skipjack** » Mon Nov 19, 2012 9:28 pm

Nothing like rocketing a few Cosmic rays through your complex high density 3D processor card.

Thats why they have 6 levels of redundancy and cross checking between all of them and if necessary resyncing. They are probably processing several times (if not orders of magnitude) faster than the shuttles computers did, even if they had been programmed in assembler...
Not that the shuttles CPUs were hardened either, IIRC.

DeltaV · Post by **DeltaV** » Tue Nov 20, 2012 5:32 am

ladajo wrote:
Skipjack wrote:
C++ to Mars? Yuk.
So you would write the entire code in assembler?
Ahh, the lost art of Hex.

Gentlemen, don't be silly. Fortran90 forever.

DeltaV · Post by **DeltaV** » Tue Nov 20, 2012 6:26 am

I had a chance to work on F-35 and turned it down when I learned C++ would be used.
(++ = ommiePlot)

http://www.dodbuzz.com/2012/03/20/more- ... -for-f-35/

Management and development of the more than 24 million lines of software code continue to be of concern and late software releases have delayed testing and training. Development of the critical mission systems that give the JSF its core combat capabilities remains behind schedule and risky. To date, only 4 percent of the mission system requirements for full capability has been verified. Testing of a fully integrated JSF aircraft is now expected in 2015 at the earliest. Deficiencies with the helmet mounted display, integral to mission systems functionality and concepts of operation, are most problematic. DOD is funding a less-capable alternate helmet as a back-up. The autonomic logistics information system, a key ground system for improving aircraft availability and lowering support costs, is not yet fully developed.

http://www.freerepublic.com/focus/f-new ... plies?c=25

Ever worked on a software project in the millions of lines of code (mega-LOC)?

I have. cisco’s IOS. Watched it grow from hundreds of thousands to millions of LOC. Last I knew it was over 8 MLOC.

Once you get above the, oh, 500K to 1 MLOC range... most developers simply cannot hold the complexity of the whole system in their heads any more. Out of the entire company’s engineering department, there were only about 12 of us who could hold millions (plural) of LOC complexity in our heads for any length of time. That’s not “memorizing” the code, but simply knowing that “something happens like this over there” in the system map, so that when you make a change “here,” you know you must do something accordingly “over there.”

Most developers tend to lose this ability, and the result is bugs. Some easy to find, some horribly subtle and seemingly random.

Once you get to 10’s of MLOC, you’d better not be using something like C++ or C, because you’ll NEVER, EVER close all the bugs. NEVER. Every C++ system I know of at that size ships with known bugs that they haven’t found yet. Dozens to hundreds of known bugs will be shipped.

The way Boeing got a handle on the situation in the FMS system of the 777 project was to start two competing projects - one in C++ and one in Ada. After awhile, they evaluated which system was closing bugs faster, not writing as many new ones, making deadlines with more certainty. It was the Ada effort. So they closed down the C++ effort and put everything into Ada.

Now, this doesn’t surprise me in the slightest. Ada was created back in the 80’s to enable large s/w systems like these... but the problem is that most of the kids coming out of CS/EE schools today aren’t taught Ada, nor are they taught real-world, “Big System” s/w engineering. They don’t know jack, really. They come out knowing C/C++ and Java... and how to code their silly social media websites... and this corrupts their minds. How you think about large system design is, in part, predicated upon your implementation language.

Anyway, due to lack of newbie engineers trained in something other than C/C++, the F-35 systems are written in C/C++, last I looked. This is one of the reasons why I think we should just kill it now.

C++ in large systems leads to bugs that are hard to replicate, hard to find and a need for lots of static code analysis to try to find the bugs in the source. Seen it many times in industry. C++ is a horrible implementation language unless you literally disable many so-called “features” in the language to preclude them ever being used.

ladajo · Post by **ladajo** » Tue Nov 20, 2012 10:45 am

Every couple of days, I wish I could go into my laptop and remove all the unused operating system code.

So much waste, and unneeded complexity.

Skipjack · Post by **Skipjack** » Tue Nov 20, 2012 3:55 pm

the problem is that C++ makes faster executables. Ansi C would be even better actually. Of course Assembler would be best, but that is really tough for complex code.

DeltaV · Post by **DeltaV** » Tue Nov 20, 2012 4:34 pm

Speed without robust, predictable, deterministic behavior just means failures happen faster.

That is partially, but inadequately, offset by various signals taking longer to propagate through massive, untestable, Jabba-the-Hutt style coagulations of C++ obfuscatology, giving at least some fighting chance for watchdog/monitoring/alarm/backup routines to activate before things go to hell in a handbasket.

C++ does not belong in real-time, life-critical applications. Projects using it have demonstrated time and time again that they cannot constrain dangerous bloat and complexity in the final product.

seedload · Post by **seedload** » Tue Nov 20, 2012 4:51 pm

I love C++ but agree totally that it shouldn't be used in these kind of environments. Ada sucks, but suits the purpose.

krenshala · Post by **krenshala** » Tue Nov 20, 2012 4:57 pm

The fact that most programmers no longer have hardware limitations dictating a requirement for clean, concise, and (most importantly) compact code isn't helping matters either. I have repeatedly heard over the years "Why should I optimize or write smaller code? The user won't see a difference because the system has enough resources to run things just fine they way they are now."

Skipjack · Post by **Skipjack** » Tue Nov 20, 2012 5:02 pm

I can see the point in using Ada. Of course then you end up having problems with finding programers that can actually use it.
C++ is quite commonly used in medical imaging applications and there are ways to avoid bugs, e.g. a strict unit testing regimen. There can still be bugs of course, but they are rare and a medical imaging application is a VERY complex piece of software.

Skipjack · Post by **Skipjack** » Tue Nov 20, 2012 5:04 pm

The fact that most programmers no longer have hardware limitations dictating a requirement for clean, concise, and (most importantly) compact code isn't helping matters either. I have repeatedly heard over the years "Why should I optimize or write smaller code? The user won't see a difference because the system has enough resources to run things just fine they way they are now."

Indeed and on the other side you often have a management that is completely oblivious to the realities of software development and thus makes decisions that facilitates this sort of behaviour.

hanelyp · Post by **hanelyp** » Wed Nov 21, 2012 4:05 am

You can get robust, predictable, deterministic behavior from C/C++, but it takes a level of discipline and attention to detail that all too many "professional" programmers lack. I say that as someone working in the field. I also note that a great many of the goofs that can make a system unstable are still possible in Ada and other high level languages.

As far as C/C++ vs. assembly code, the latter can give slightly better performance, at the expense of a great deal of work and locking you to a specific architecture.

Skipjack · Post by **Skipjack** » Wed Nov 21, 2012 1:13 pm

You can get robust, predictable, deterministic behavior from C/C++, but it takes a level of discipline and attention to detail that all too many "professional" programmers lack. I say that as someone working in the field. I also note that a great many of the goofs that can make a system unstable are still possible in Ada and other high level languages.

As far as C/C++ vs. assembly code, the latter can give slightly better performance, at the expense of a great deal of work and locking you to a specific architecture.

Fully agree! In the end crappy programmers will write crappy code, no matter the language, though I agree that a language like Ada might make things a bit easier. But then, you should never let crappy programmers work on mission critical stuff.

paperburn1 · Post by **paperburn1** » Wed Nov 21, 2012 2:02 pm

Skipjack wrote:
The fact that most programmers no longer have hardware limitations dictating a requirement for clean, concise, and (most importantly) compact code isn't helping matters either. I have repeatedly heard over the years "Why should I optimize or write smaller code? The user won't see a difference because the system has enough resources to run things just fine they way they are now."
Indeed and on the other side you often have a management that is completely oblivious to the realities of software development and thus makes decisions that facilitates this sort of behaviour.

Cut and paste mentality, why develop what you can steal off of the internet.