5 ms·

I hypothesize what was really missing to make the transputer successful was a language/compile-target to express propagators: https://youtu.be/nY1BCv3xn24 https

I hypothesize what was really missing to make the transputer successful was a language/compile-target to express propagators: https://youtu.be/nY1BCv3xn24 https://youtu.be/nY1BCv3xn24 We are starting to see languages that could leverage such an architecture: * http://minikanren.org/ http://minikanren.org/ * https://cuelang.org/ https://cuelang.org/ * https://github.com/ekmett/guanxi https://github.com/ekmett/guanxi Is there an algebraic logic strongly associated with what we conventionally think of as types (see https://cuelang.org/docs/concepts/logic/ https://cuelang.org/docs/concepts/logic/) which we can effectively and efficiently compute unions and Boolean satisfiability?

dboreham 7y ago
The thing that sunk the Transputer was that you couldn't (for the time it had a hardware performance advantage over competitors) program it in C.
- rudolph9 7y ago
  What did you program it in?
  - fallous 7y ago
    Occam was the native INMOS provided programming language.
    - pdfernhout 7y ago
      I programmed in Occam for a time. It used two spaces for indentationally-significant code which I thought a great idea then -- and which is one reason I liked Python and took easily to it. https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) For a time around 1986-1987 I had several Transputer boards in a robot lab I worked in at Princeton University. I liked the INMOS sale pitch that someday you could have a transputer at every robot joint. Something similar is relatively easily accomplished now using various serial connections between microcontrollers -- even if it might still be easier to just run cables to the joints from boards elsewhere. That combination of Transputer boards (including several loaner boards from another lab on campus which has got them related to NSA-funded signal processing stuff) for a time gave me the most powerful computer on the Princeton campus in terms of total memory and CPU cycles -- even if the IBM 308X mainframe in the computer center no doubt had more total I/O capacity. One other thing I liked about transputers was the (for the time) high speed serial links between them which could also go to special chips to read or write parallel data. I used such chips to interface a network of transputers to the teach pendant of an Hitachi A4 industrial robot so they could essentially press the buttons on the pendant to drive the robot around. Interesting how modern USB in a way is essentially just a serial transputer link. A PU undergrad student I helped used that setup for a project to use sensing whiskers to "feel" where objects were (inspired by a robotics magazine article I had seen by a group in Australia who had done that for a different robot). While transputers not supporting C was an issue early on, another issue was just that Occam did not easily support recursion. Transputer at the start also did not have standard libraries of code then like C had from Unix. And also transputers were expensive (as was the software development kit) and also they were not easy to get in the USA with various supply chain issues and delays. Occam was mind-expanding in its own way. I had previously networked a couple of Commodore VICs and a Commodore 64 for a robot project (via modems to an IBM mainframe) for my undergraduate senior project at Princeton a couple of years earlier using assembler, BASIC, and C -- so the transputers with Occam were a big step up from that conceptually. Still, practically I had gotten the Commodore equipment plus a parallel code simulator (a VM in C) I wrote for the IBM mainframe running under VMUTS to do more interesting stuff -- perhaps because I had years of experience programming in those other languages by then whereas Occam was so different and I did not spend that much time with it before leaving that job. Even without Occam and transputers, that robot lab job was the best paying job working for someone else I ever would have in many ways as far as autonomy, mastery, and purpose -- but I did not appreciate it then as it was my first real job beyond college and I figured the grass would be greener somewhere else -- not realizing that grass tends to be greener where you water it. Thanks for creating such a great working situation for me, Alain!
- fallous 7y ago
  I'm not sure that's true, at least if you were running HeliOS.
  - gnufx 7y ago
    Right, and Fortran was used for scientific work (not necessarily with Helios?). https://en.wikipedia.org/wiki/HeliOS https://en.wikipedia.org/wiki/HeliOS
    - dboreham 7y ago
      Again, I'm talking about 1986/7 or so. In that time frame the T4/T8 were performance competitive with anybody's CPU. However you could only program in Occam. Huge hygiene factor. Of course today we have golang which has much the same features as Occam and everybody thinks it is the best thing since sliced bread. And we have folks seriously re-writing dusty decks in Rust. But back then you just couldn't seriously sell a CPU that forced you to program in an unknown, fairly basic, programming language. Also, internally we still used a lot of BCPL. So the company itself didn't eat its own dogfood in the way it expected customers to.
      - gnufx 7y ago
        http://tardis.dl.ac.uk/computing_history/parallel.html http://tardis.dl.ac.uk/computing_history/parallel.html confirms my memory, but perhaps the timeframe is wrong. (I rather thought Bill Purvis wrote a compiler, but it seems that was Occam for the T machine.) Thanks for the history, anyhow.
- nerpderp82 7y ago
  Supply, cost and the 9000 being delayed. The 486 killed the Transputer basically.
  - dboreham 7y ago
    I'm speaking about a time long before the T9 was even thought of. The 386 was performance competitive with the T8 if you didn't need FP.
- ncmncm 7y ago
  A friend of mine made a C compiler for Transputer. He also made a loader that could copy a program to a whole network of transputer chips in seconds, instead of hours like theirs. They hated his C compiler, and hated him for making it, and did their best to keep anybody from knowing about it. That was easier to do, before www.
  - dboreham 7y ago
    I'm not sure who is "They" here. Well...ok I have a bit of an idea of one or two people ;) But for 90% of the transputer group at the time it was very obvious that we needed alien language support. We had to spin up a compiler group, which took time. I seem to remember we also OEM'ed some compilers from outside vendors before the internal ones were ready (memory hazy and I didn't work directly on software there). I had direct contact with many customers, specifically discussing C language support and I don't at all remember anything like what you describe where 3rd party products were deliberately not mentioned.

dboreham 7y ago

The thing that sunk the Transputer was that you couldn't (for the time it had a hardware performance advantage over competitors) program it in C.

rudolph9 7y ago
What did you program it in?
- fallous 7y ago
  Occam was the native INMOS provided programming language.
  - pdfernhout 7y ago
    I programmed in Occam for a time. It used two spaces for indentationally-significant code which I thought a great idea then -- and which is one reason I liked Python and took easily to it. https://en.wikipedia.org/wiki/Occam_(programming_language) https://en.wikipedia.org/wiki/Occam_(programming_language) For a time around 1986-1987 I had several Transputer boards in a robot lab I worked in at Princeton University. I liked the INMOS sale pitch that someday you could have a transputer at every robot joint. Something similar is relatively easily accomplished now using various serial connections between microcontrollers -- even if it might still be easier to just run cables to the joints from boards elsewhere. That combination of Transputer boards (including several loaner boards from another lab on campus which has got them related to NSA-funded signal processing stuff) for a time gave me the most powerful computer on the Princeton campus in terms of total memory and CPU cycles -- even if the IBM 308X mainframe in the computer center no doubt had more total I/O capacity. One other thing I liked about transputers was the (for the time) high speed serial links between them which could also go to special chips to read or write parallel data. I used such chips to interface a network of transputers to the teach pendant of an Hitachi A4 industrial robot so they could essentially press the buttons on the pendant to drive the robot around. Interesting how modern USB in a way is essentially just a serial transputer link. A PU undergrad student I helped used that setup for a project to use sensing whiskers to "feel" where objects were (inspired by a robotics magazine article I had seen by a group in Australia who had done that for a different robot). While transputers not supporting C was an issue early on, another issue was just that Occam did not easily support recursion. Transputer at the start also did not have standard libraries of code then like C had from Unix. And also transputers were expensive (as was the software development kit) and also they were not easy to get in the USA with various supply chain issues and delays. Occam was mind-expanding in its own way. I had previously networked a couple of Commodore VICs and a Commodore 64 for a robot project (via modems to an IBM mainframe) for my undergraduate senior project at Princeton a couple of years earlier using assembler, BASIC, and C -- so the transputers with Occam were a big step up from that conceptually. Still, practically I had gotten the Commodore equipment plus a parallel code simulator (a VM in C) I wrote for the IBM mainframe running under VMUTS to do more interesting stuff -- perhaps because I had years of experience programming in those other languages by then whereas Occam was so different and I did not spend that much time with it before leaving that job. Even without Occam and transputers, that robot lab job was the best paying job working for someone else I ever would have in many ways as far as autonomy, mastery, and purpose -- but I did not appreciate it then as it was my first real job beyond college and I figured the grass would be greener somewhere else -- not realizing that grass tends to be greener where you water it. Thanks for creating such a great working situation for me, Alain!
fallous 7y ago
I'm not sure that's true, at least if you were running HeliOS.
- gnufx 7y ago
  Right, and Fortran was used for scientific work (not necessarily with Helios?). https://en.wikipedia.org/wiki/HeliOS https://en.wikipedia.org/wiki/HeliOS
  - dboreham 7y ago
    Again, I'm talking about 1986/7 or so. In that time frame the T4/T8 were performance competitive with anybody's CPU. However you could only program in Occam. Huge hygiene factor. Of course today we have golang which has much the same features as Occam and everybody thinks it is the best thing since sliced bread. And we have folks seriously re-writing dusty decks in Rust. But back then you just couldn't seriously sell a CPU that forced you to program in an unknown, fairly basic, programming language. Also, internally we still used a lot of BCPL. So the company itself didn't eat its own dogfood in the way it expected customers to.
    - gnufx 7y ago
      http://tardis.dl.ac.uk/computing_history/parallel.html http://tardis.dl.ac.uk/computing_history/parallel.html confirms my memory, but perhaps the timeframe is wrong. (I rather thought Bill Purvis wrote a compiler, but it seems that was Occam for the T machine.) Thanks for the history, anyhow.
nerpderp82 7y ago
Supply, cost and the 9000 being delayed. The 486 killed the Transputer basically.
- dboreham 7y ago
  I'm speaking about a time long before the T9 was even thought of. The 386 was performance competitive with the T8 if you didn't need FP.
ncmncm 7y ago
A friend of mine made a C compiler for Transputer. He also made a loader that could copy a program to a whole network of transputer chips in seconds, instead of hours like theirs. They hated his C compiler, and hated him for making it, and did their best to keep anybody from knowing about it. That was easier to do, before www.
- dboreham 7y ago
  I'm not sure who is "They" here. Well...ok I have a bit of an idea of one or two people ;) But for 90% of the transputer group at the time it was very obvious that we needed alien language support. We had to spin up a compiler group, which took time. I seem to remember we also OEM'ed some compilers from outside vendors before the internal ones were ready (memory hazy and I didn't work directly on software there). I had direct contact with many customers, specifically discussing C language support and I don't at all remember anything like what you describe where 3rd party products were deliberately not mentioned.