I independently figured a lot of this stuff out around 1995 while writing shareware games in college (limited by absurdly slow 30 MHz memory busses and single-threaded execution before video cards) and 2005 at a job where I used MATLAB. Basically that computers ran many thousands of times slower than they should have, which today translates to many millions of times slower for the transistor counts. We perceive computers as fast today, but that's just the video card doing most of the work, at enormous programmer expense due to having to use separate languages and paradigms separate from the host OS.
The article jumps the shark at chapter 5 Transputer Languages on page 63, so I'd recommend skipping that. It's fun to learn about stuff like Occam, but it's kind of the assembly language of Erlang or Go (if Go had full process isolation) so is probably too low-level for large programs to be understandable by humans. They didn't really understand process isolation like we do today, so got lost in the weeds with libraries/intrinsics/threads, rather than having a language self-parallelize all code like something like Julia (from what I understand, I haven't fully learned it yet).
I'd largely skip Chapter 6 Software Environments on page 88 as well, which covers various environments for transputers, which are fun for their historical significance. But again, I wouldn't use any of them today, since we have much simpler approaches with stuff like containerization now.
Chapter 7 Transputer Family Hardware on page 101 is quaint. The principles are good, but break down with the memory and network speeds available today and the fact that we work at higher levels of abstraction.
I didn't know there was an Atari Transputer Workstation (ATW) in 1988, wow!
I've written extensively about multicore processing in my comments here for over a decade, with no meaningful progress in industry from what I can tell. Personal hardware got abandoned for stuff like elastic compute on AWS.
That said, it's pretty obvious what a transputer today would look like. I'd suggest a 1 GHz processor with at least 1 GB of onboard ram and at least 256 cores for under $100. It should have gigabit ethernet and use something like content-addressable memory to allow the chips to self-organize with LRU caching for data locality. It would use web metaphors so that the location of a core or memory doesn't matter, even running across a warehouse or over the internet. So 4 of these would look like a single desktop computer with a kilocore (kC, like IBM's from 2006) and easily scale to probably 64kC or even 1 MC without too much extra work. It would be the software equivalent of something like BitTorrent vs FTP. And largely buildable with FPGAs, had they continued to evolve instead of getting hamstrung by their GPU competition.
It would be programmed with existing C-style languages and a self-parallelizing compiler that uses techniques from compiler optimization to detect for-loops on immutable data and spread the workload over any number of processes. Programs would be inverted to identify mutability and treat it as unsafe code that can't be statically analyzed or evaluated lazily. So synchronous blocking higher-order methods on immutable data would be highly encouraged. Stuff like shader memory layout optimizations would largely go away due to the use of content-addressable memory and the avoidance of hardware caching other than what's needed to make the distributed memory appear as a single address space.
It's all so easy and obvious to me that I've all but given up on it ever happening. Writing this out for the umpteenth time makes me feel tired. To the point that I struggle to program in my daily life, because it feels like I'm having to do everything the hard way with async approaches (today's GOTO) and highly-specialized shaders that break constantly because I just can't see what I'm doing or debug them properly so it feels like all I ever get is a blank screen.
I wish so badly that a startup would jump on this and bring us real computers with real power so that we could play around with stuff like genetic algorithms and running machine learning in simulation so that we could evolve our own AI digital assistants. Instead of having to rely on closed/proprietary/cookie-cutter solutions that are pay-to-play or have other artificial limitations to prevent terrorism or whatever.
It's the same old story, I'm thrilled to see stuff like DALL-E 2 bring the predictions of sci-fi to life, but saddened that it happened decades later than it should have due to poor hardware architecture choices. It's like having to watch electric cars go mainstream 20-30 years after the lithium ion battery was invented, because the fossil fuel industry prevented that from happening every step of the way.