I used to program a 96-processor machine. It could do what were for the time some quite amazing things in quite a small package. The interconnections were dynamically reconfigurable, so you could make the mesh of processors match the mesh of your problem (within limits) and avoid bottlenecks getting data from one place to another.
Very cool, very advanced, and no one seemed to "get it."
But it was impossible to get programmers to understand how to write programs for it, and it was impossible to get problem domain experts to write decent programs at all. Every problem people brought to me to get parallelised was trivially re-written to run tens, sometimes hundreds of times faster. It was a solution looking for a problem that never showed up.
I learned a lot from that project, some of which is still in action today, about programming large, multi-processor systems. But I still remember Occam (and its friends (yes, it had friends)) with some fondness.
A fascinating system. As a college student I thought it was the coolest concept (and it's still awesome 30ish years later). The immediate obvious problem, and what took it down, was the amount of hardware required and the paradigm shift to use them - not a huge obstacle, but enough to hinder proliferation.
I've attended Computer Architecture lectures with David May - incredible character with profound knowledge of anything related to computer hardware.
His new company (http://xmos.com) is also worth looking at if you're interested in parallel computing.
While we never got it to production, we had a project based on the transputer in my first startup back in 1987 (a couple of naive high school kids in Denmark bootstrapping a high end workstation company).
Our plan was to use it to create a infinitely expandable workstation for both 3d and audio work. The design of the transputer was incredibly elegant, it was pretty much as easy to design with as a 6500 one chip computer and didn't require any extra support chips.
The Occam language was also pretty elegant for its time. It was essentially parallel Pascal. I don't remember it having any OO features, but the automatically parallelized looping constructs were unique for their time.
I do miss Occam. It was a good way of thinking to layout your program in steps with data moving through the system. Other, newer languages do the same thing but feel like they don't trust the parallelism in some ways ("here's how you write programs, oh yeah, this is how we do parallel").
I often think Occam and Forth / Postscript are the languages that made me think the most about what a program should be.
Very cool, very advanced, and no one seemed to "get it."
But it was impossible to get programmers to understand how to write programs for it, and it was impossible to get problem domain experts to write decent programs at all. Every problem people brought to me to get parallelised was trivially re-written to run tens, sometimes hundreds of times faster. It was a solution looking for a problem that never showed up.
I learned a lot from that project, some of which is still in action today, about programming large, multi-processor systems. But I still remember Occam (and its friends (yes, it had friends)) with some fondness.