I wonder in what language the software for Mars Climate Orbiter was written. Python/C++/C/Assembler/w.h.y.?
Regarding the mis-specification/-communication of units used in the software (e.g. ‘m/s’ vs. ‘ft/s’), I would like to direct your attention to Bjarne Stroustrups keynote at Channel9. The recent standard of C++11 permits the creation of classes resp. objects of classes that hold units in their type.
Regarding the ‘queue’ example I would also like to point to C++, which many years ago acquired such a prefabricated type in its standard library. Just
The short answer:
NASA is not using in Python in any substantial way in any flight project or military deliverable. However, as JIffyClub and Clinton point out, there are some projects that use Python, particularly on the science side of the equation, where the requirements of flight projects or military deliverables are not present. LIkewise, I would expect that you could find it in some personal projects or replacing automation scripts that used to be done with shell scripts or Perl.
The very long (but interesting read to some) answer from an insider's point of view:
Although anyone can use anything they like for their daily work, the majority of people use C. To a much much lesser extent you see C++ and to an even lesser extent, Java. Few-to-none use ADA, Fortran or Lisp. Assembler is used if you happen to be working on optimization or writing a driver. For prototyping, at least in JPL, Matlab is the favorite by a long shot although a few people use Mathematica (I would expect someone might be using Maple too but I never saw anyone using it). In general, no large or medium project uses any scripting language, i.e., no python, ruby, perl, etc., because these projects tend to have special requirements.
The preference for C makes a lot of sense. By default, all large flight projects are written in C. For example, the code for the Mars rovers is in C with a single exception (Gestalt, the visual navigation software, which is written in C++). Thus, it makes little sense to develop the code in a language other than C knowing that for the code to be accepted by either a flight project or adopted by your peers, it will need to be ported to C anyways. Also, by default, drivers of commercial hardware that you might need to interact with are written in C. C is fast, there are very mature libraries for it and It allows you to write at very low-level, close to the hardware, which is useful. A huge plus is that there are many compilers that can write code that follows the C standard. Thus, If you develop your code in, say, gcc, it would compile without any major problems in a watcom or green hills or any other C compiler and you can be pretty confident that it will behave the same (you still need to test it, of course, but the expectation is that the surprises will be few to none). You could not say the same of many other languages. In particular, I am not sure whether there is any C++ compiler that can produce code that follows the C++ standard today, but I know that there wasn't any not many years ago.
C/C++ is the preferred language of military applications so if your project happens to have a military sponsor (fairly common at NASA), your C code would work too. I know of no project that uses ADA, even for military sponsors. One of the possible reasons for this is the close interaction between university research and military sponsors. UNIX and C/C++ are (or at least used to be) ubiquitous in academia and thus, graduate research projects from universities like CMU that had a direct impact on military projects were developed in C/C++. Likewise, an EE/CS/Math/Physics new graduate is bound to know either C or C++, so s/he can start contributing to any C/C++ project without being hit with the learning curve of a new language.
IMHO, for the rovers, C++ is not a good language without restricting it a lot, in which case, you might as well use C (the following scenario fits satellites as well). Most projects that you encounter on a daily basis that use C++ are completely oblivious of resource constraints. These are very important in a flight project where the processing power and amount of memory available, in both RAM and disk, are quite limited. Long gone are the days when military and space hardware requirements drove the chip and computer memory industries; nowadays, they are driven by the mass market. Thus we have powerful chips and inexpensive hard drives that are great for our laptops but cannot be used in outer space, where special radiation-hardened parts are required. The combination of the need of both rad-hard parts and throughly tested parts often leads managers to prefer parts that severely lag the capabilities of the state of the art parts that we are used to in our daily lives. As an example, the MERs had a 20 MHz RAD6000 CPU with 128 MB of DRAM. My laptop, already 4 years old, is 100 times faster (2.4Hhz) and has 32 times more RAM (4Gb). Likewise, each rover has 256 MB of flash memory, dwarfed by my tiny 180Gb HD, not to mention my 1TB external HD. So.. with this in mind you can see why managers have problems using C++, with it reputation of generating bloated code. In addition, certain features of the language, like templates, have a large tendency of producing large code footprints. In comparison, C code tends to be very streamlined.
Again, IMHO, another problem with C++ is that it takes a long time to master. You can say that you can start using the basic features of the language, but in that case, just use C. If you use more features, then you get into the problem of requiring people that master the language AND also the subject that they are contributing too. However, consider a typical case. An engineer who spends all his time working on, say, antennas or communications. This person is very likely to know C but very unlikely to know C++ (less alone master it). You could expect that s/he would deliver the driver for the antenna in C. The code of this driver could be easily reviewed by other communication engineers which, again, are all likely to know C very well and not know C++. After all, for them the language is just a means to get the job done, which is to get the antenna working. Their efforts go into making the antenna and using the least common denominator that can get it to work fast, reliably and safely and that is C, not C++. This scenario repeats across the board: the person that is working in image compression, in visual odometry, in firing the parachute, ... on and on. So why use C++? C++ is an amazing language and I can see why it is the preferred language for very complicated pieces of software but I do not see it as an option that stands out in flight software.
As an addendum pertinent to this class, I wrote the dust devil and cloud detectors for the Mars rovers - all in C. My code was loaded with assertions to a much larger extent than the 1:100 ratio discussed in class. A second person - Alex Fukunaga, now a prof. at Tokyo University - had the sole job to test my code against test sets provided by the scientists - Mark Lemmon (Texas A&M) and Ron Greeley (Arizona State) - to meet their hit and miss ratios. We did this to-and-fro, me working on the code, Alex testing it and providing feedback, for several months. During all this time, Steve Chien, the manager of the project, was passing updates to the QA team of the MERs. After the code met the scientists specs, Alex review the whole code. At this point my job was done.. the algorithms were running at specs and my only duty was to be available if something unexpected happened. However, the completion of the job, which now Alex was in charge of, was far from over. The code was reviewed by a red team, whose job was to to comb it, line by line, for any problems. All of the people in the red team were very familiar with C/C++ so reviewing my C code was no problem. After that Alex and Jeff Biesiadecki, our interface to the core of the MER project, integrated the code into the flight software. Jeff generated the calling commands and Alex tested the code again in a simulator, this time to check its interaction with the code of the rovers and vxworks, the rovers's OS, e.g., its behavior with respect to memory, timings, interfaces to cameras and buffers, interruptions, etc. Once integrated and tested, it was downloaded into a functional copy of the rovers kept at JPL, and tested again. This is as close as you can get on Earth to the real thing because the rover at JPL is an exact copy of the ones in Mars. This is the time where you get to put on white lab coats and shoe protectors and do your test in an air-filtered room: although the rover copy is on Earth, it is treated as flight hardware because it very much affects flight hardware (i.e., the rovers in Mars). For example, this same rover was used to figure out how to free a rover that has gotten stuck in soft sand. Again, Alex had to retest everything and now, we add the tests of actually processing input with the rover cameras. After all of this, the software was transmitted to Mars and added to the code of Spirit and Opportunity. So as you can see, Alex's effort of testing the software to flight-qualified level was several times the effort that it took me to write it.
I have always been a huge fan of assertions which helped the code pass the red team review without comments pertinent to errors but there was an error in our integration to the Mer code: a misunderstanding in the interface between our code and the MER code (what we discussed in class as a specification error.. we did have a detailed document that described exactly what we were going to give them.. or so we thought.. there was a minor issue that was wrong, though.. I don't remember what it was but the issue is that we had written something and they thought it meant something else). After that, the code was uploaded and has been running on Mars for several years now without a hiccup and my understanding is that the same code is now part of the code of MSL, the rover presently on its way to Mars.
So, 3 observations with respect to this class:
I work (and have worked) as a contractor to NASA and my perspective is a little different than that of @Goldsong. Python usage in science is growing fast, including at NASA. SunPy is one example, and there are others.
The Hubble Space Telescope exposure time calculators (http://etc.stsci.edu) are written entirely in Python, as is most of the data analysis software written by STSCI (http://www.stsci.edu/institute/software_hardware). Python is the primary language used for writing the data processing pipelines for the upcoming James Webb Space Telescope, and for some of the testing of JWST: http://conference.scipy.org/scipy2010/slides/warren_hack_smoke_mirrors.pdf.
So, while you may not find Python running on spacecraft, don't be surprised to find it in use at NASA (and elsewhere) for other tasks, especially data processing and analysis. Python, NumPy, SciPy, matplotlib, and the wealth of third-party libraries are a powerful and free stack of software for science.
Some other links:
While C++ does indeed provide a queue type, I can easily see said queue not being optimal for plenty of situations. For example, the queue may reallocate when adding elements, which is something we wish to avoid. Not that this is relevant -- the queue is but an example, and there are many more exotic data structures that are not readily available.
Even in the case of data structures and algorithms that are available, these must still have been implemented by someone, and are not guaranteed to be bug-free. The most obvious historical example is the bug in common implementations of binary search which was discovered decades after the algorithm was first conceived.
Anton Golov ♦
i have no idea exactly, but I guess it may have been ADA which AFAIK was the language of choice for this kind of applications many years ago (even though the Mars orbiter was not that old)