Nombas,
Un-Incorporated
Nombas doesn't exist any more. All the good stuff was sold to Openwave, then sold to someone else, then sold to someone else, then I lost track.
Sorry about that.
|
Update, Aug 19, 2022: I probably created this page 11 or more years ago (although I see one update in 2014). By then I’d already been out of the hardcore JavaScript world for many years (what is ECMAScript up to now, version 89?, I don’t even know). I’m updating this now because JWST (James Webb Space Telescope) launched almost a year ago, and lately more lay-ish people have taken notice that the Nombas engine is controlling a lot of what goes on in the satellite and between the earth and the satellite. It was nearly two decades between our first getting involved, until JWST finally launched, with delay after delay. I wondered sometimes if it was ever going to fly. I find much of the coverage (like this article in The Verge yesterday) thrilling. I’m extremely proud to have been involved. But it’s also common for people to sense concern that NASA’s $10 billion telescope is running on ancient software, with a language not known for its reliability, and created by a fly-by-night company that no longer exists. To very briefly address those concerns:
It is my opinion that NASA settled on the Nombas engine, after extensive research of their own into all the options available at the time, not so much because of the JavaScript language itself (although the familiarity of the language was a bonus), but because of the solid and robust nature of the ScriptEase engine and the tools that went with it. At Nombas, went to extremes to make software as unbreakable as possible. This started with good code and good coders, and was stressed to software limits by what we called “the server farm”, which continually ran every conceivable iteration of code input and outputs (and countless inconceivable iterations brought about by randomness). Our automation tests assured that everything that could go wrong was forced to go wrong, and that the engine recovered in the proper way to the controlling script or processor, with no crashes, no loss of memory (we actually ensured that every single memory allocation would recover from failure based on total size, count, or just randomly), and no side effects. You don’t want to be using the latest and flashiest software, just because it is the latest and flashiest, only to find yourself launching astronauts to your satellite, a million miles out into space, just to press ctrl-alt-del. |
|
Minor Update, Aug 24, 2022 (a minor little thing): I’ve read a few places recently that the ScriptEase engine that was selected for JWST 20 years ago was written in C++. No, it was written in C. The early 90’s version had been in C++, but we found C++ to be a problem for embedded systems, which were becoming important to us. This was partly because C++ was less common at the time, so more difficult to integrate. But the greater problem was the difficult in bullet-proofing C++ systems, due to the ease of unintended consequences, but mostly because of the exception-in-constructor problem: What to do if there’s an error (for example, out of memory) while creating a constructor? I found it very confusing, and managed differently (if at all) by the many different C++ compilers at the time. As I wrote earlier, we insisted that anything that could go wrong would to go wrong in testing, and that we would recover appropriately from that. Accomplishing this robustness goal in multiple version of C++ was too complicated. By the way, that original version of the engine was written in C++ interpreted the language we called “Cmm” (for “C minus minus”). It’s a little funny to think that Cmm was written in C++. |