One of the crazier aspects of the design was that the chip design basically required the Ada computer language to take over the world. As far as predictions of the future go that has to be one of the most expensive misses of all time.
It was built for the US Department of Defense and it is easy to believe that something with US government backing might have massive staying power, even if only just for (sometimes lucrative) defense contracts.
The biggest problem with Ada at the time was how expensive it was to purchase compilers, which is obviously par for the course for something built for defense contracts on a defense budget but would have been a lot harder to swallow for general software companies. Even then there was room to imagine that competitor compilers might be built (especially if you think you've got a chipset designed to make that in theory easy to do by moving many of the language intrinsics/underlying virtual machine directly into hardware as a physical machine).
The only thing missing was a reason for programmers to switch to it. There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises. Actually, it sounds a lot like Rust minus the buggy compiler part.
The idea that the defense contractors would drive the industry over-estimates just how much code they write. Sure it's millions of lines every year, but compared to worldwide C development it is a drop in the bucket.
I see Ada as having a fundamentally different philosophy from languages like C and BASIC. Ada compilers were allowed to not implement all of the standard library features, and many didn't.
> ...such a huge compiler for a new language is doomed to be buggy, especially at first...
Was this actually what happened though? There was always the Ada Conformity Assessment Test Suite (ACATS), which tested a compiler's implementation. If compilers ever hindered Ada's adoption, it wasn't because they were buggy, it was how expensive and resource intensive they were.
> There were promises that the code would be safe, and that if it compiled it should just work, but the buggy nature of the compilers undercut these promises...
...except that it did kind of work in the end though, didn't it? Ada is still very widely used in a lot of places, and has been for a long time. Lots of new code is still being written in Ada too. There's lots of literature available about how well Ada integrates in environments where code is audited against safety regulations.
> The idea that the defense contractors would drive the industry over-estimates just how much code they write.
This is certainly true now, but was this true when Ada was being designed in the late-70s/early-80s? My understanding is that C didn't become the dominant embedded-systems language until much later. I wasn't there, mind you. I could have some historic details wrong.
Edit: It's worth adding that of the languages the parent poster mentioned above, the only language which still sees mainstream use is C. I know Fortran and LISP have very healthy communities and enjoy a lot of use in niche industries, of course. I don't think this is what the parent poster meant exactly, however it's very common to hear people talk about Ada as a failure on the basis that it didn't completely overtake the software industry. You don't really hear people condemn BASIC, or Pascal in the same way though, even though Ada enjoys much more modern usage.
The implication I was making, in case it wasn't overt enough, had a lot more to do with money/budget/revenue than lines of code. The US DOD has massive budgets and over-spends those budgets on all kinds of wild things (so long as they can pass Congressional oversight, at least). The amount of money the US DOD spends on defense contractors will always attract a lot of attention, even if the amount of code that the US DOD gets back from all that spending will always be a drop in the bucket to the overall software industry.
A different, unrelated, implication that is often used is that the DOD has increased requirements for safety, security, and oversight and that "defense-grade" or "defense-level" signifies something stronger than consumer-grade. You can see some of that in the 432's attempted marketing: imagine having access to "defense-grade" Ada-capable hardware in the microcomputer form factor at a fraction of then-current mainframe costs. Of course, in reality, not everyone needs "defense-grade" and the "dream" of using the same language and similar tools to the US DOD never had quite the appeal that Intel marketers must have hoped for. But you can certainly see why Intel marketers might have thought there some advantage in "defense grade".
The US DOD and its defense contractors have never exactly "led" the industry, but they've certainly had a large shadow over of it for most of computing history. (Says the person sending this little collection of thoughts and opinions over a vast and incredible inter-network of networks that began as a Defense advanced research project.)
Adding some special instructions for Ada might be reasonable, but betting your future on a single programing language dominating everything is beyond bold.
So splitting it all in 3 wasn't necessarily the crazy idea we might think it is today - it still all fitted on one circuit board!
(The dependence on Ada makes a lot more sense in this context: Your mainframe vendor telling you what language you could use wasn’t odd at all in that space.)
DEC also essentially fell victim to this misapprehension, and unlike Intel didn’t have a Plan B.
Memorial page with photos: http://hampage.hu/nosztalgia/netto/ursus/index.html
In 1995, when another university got a VAX 9000 cluster for the bargain basement price of 50 000 CHF (~130 000 USD equivalent today) -- the Swiss basically discarded it as outdated, this truly was cheap -- and they tried to switch it on, it blew the fuse ... of the district. They needed to run a new power line from the nearest substation.
I think the really big problem with the 432 was all that hard wired microcode - rumor has it that it was buggy enough that subroutine calls could take over a millisecond (because they effectively called malloc() which in turn could trigger garbage collection) - stuff that's simply on say a 68k (push the next PC on the stack and jump) becomes a nightmare on a 432 if to fix a bug you need to spin the chip to change the microcode (to be fair at the time rammable microcode was all the rage, but it did take more area and you had to solve the booting problem).
Anyway turning off the interrupts for a millisecond is a non starter for so many microcomputer applications ....
* nested virtualization -- anything can run inside anything inception style (IBM; maybe others)
* smart peripherals -- hey storage get me this record! hey terminal send me the whole message when the user's done typing it out! (most of them)
* binary abstraction -- your code is compiled by a bytecode of some sort that's dragged along to abstract decades of underlying hardware changes (IBM, burroughs, probably others)
I think there's a bunch of stuff that's unique to unix that people just presume "this is the way" but since I'm mostly stuck in that universe I can't give a quick overview of all the wonky things that are totally alien to unix but totally normal to other systems.
https://www.youtube.com/watch?v=Z90nKW8VhhI
Moments of sadness, moments of guilt
Stains on the memory, stains on the quilt
Chapter of incident, chapter and verse
Sub-heading chronic, paragraph worse
Lost in the limelight, backed in the blaze
Did it for nine pence, those were the days
Give me my acre and give me my plough
Tell me tomorrow, don't bother me now