I wanted Dall-E 2 to show me what a Transputer might look like, so I entered the following as prompt for Dall-E 2, based on the text from the preface and the intrpoduction of the linked PDF:
> The software and hardware implementation of transputer parallel processing systems. Why do we need all this computing power, and how are we going to be provided with it? Modern developments have shown that good software should be intuitive. If the user has learned one program package then the next package, albeit from a different software house, should behave in a similar fashion.
The T414 was the first useful but affordable Transputer.
It was 32 bit but lacked the floating point hardware of the more expensive T8xx series. Later on there were even cheaper T4xx chips, which were relatively easy to get on a PC expansion card with slightly crippled tool chains for occam.
I still have a couple of T414 boards. I mostly run Helios on them: a parallel universe version of Plan9.
Yes, that Wikipedia link is the one I mean. It was sold independently but was also the native OS of the Atari Transputer Workstation.
Like Plan9, Helios has servers that export a namespace into a common tree. The Helios server protocol is very similar to 9p. They appear to have evolved independently though.
Plan9 allows each user to manage their own namespace by mounting stuff into it. In Helios, there’s a shared global tree that spans all the Transputers in the system.
Both are Unix-like, although Helios probably tried harder to maintain a POSIX-like API.
I have this book, still sitting in my bookshelf, from back in the day. I never got to use a Transputer for real which is a shame as I would have loved to try them out, but the book was still excellent and worth the read.
Mainframes had significantly powerful IO processors, meanwhile modern PCs contain many processors linked by effectively an internal network. With the right network hardware you can DMA to another system too. So I guess the lines have always been a little blurry between systems!
The company I worked for in the early 90s decided to use Transputers for their custom embedded systems, so I had the privilege of working with them in development and production environments for a few years.
They were an absolute joy to work with. You would structure your code into tasks that could be performed in parallel, with a simple queue for inter-task communication. You could then debug the code on a single transputer (residing on an I/O card plugged into your computer).
The production board typically contained several transputers, all connected through serial links, and with one off-board link connector. To upload your code to production, you connected a link from the transputer on your dev card to the production board, placed the board in "boot from link" mode and downloaded the code to the target. A "placement" file directed where the various tasks should run, so the tasks which ran on a single processor in dev, were loaded into the specified processors on the target. I.e. going from single processor to multiprocessor execution without even requiring a re-compile.
The T800 was the fastest floating-point processor available at the time and blew our previous generation processors out of the water. Everyone was sad when INMOS /SGS Thompson faltered with the development of the T9000 and lost their performance edge, eventually resulting in the demise of the platform.
Occam-2 was definitely not my most favorite language, but an interesting experience. Thanks for the link; I only had the original manuals and Pio2 at the time. Using http://any2djvu.djvu.org/ I was able to generate a fast, compact version of the referenced PDF.
I did a lot of work with transputers and occam in the 1980s and wrote an OS for a machine that used them. The exposure to the CSP way of thinking was a blessing. occam-2 on the other hand was a little too primitive.
I remember when Inmos marketing came up with "We wanted to make occam the FORTRAN of parallel processing". My response was "You have." (a reference to occam-2 having only static arrays and no concept of a record/struct)
> occam-2 having only static arrays and no concept of a record/struct
Which is remarkable since Tony Hoare is actually also the inventor of the records concept. In the corresponding publication in the Algol Bulletin 21 from 1965 there is even a quote by Occam ;-)
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 ...
How much of what we do on current-era machines is IO-bound? Not a great deal. And when it is, it's usually a network and not a local hardware limitation.
How much would UX improve? Not a great deal, most usage is CRUD/web/vid.
Would new applications become available? Sure. But what are they?
Is the value proposition vs. total addressable market compelling?
If you can convincingly answer the above you can definitely go get funding and do it.
In the 80ś-90ś I thought of software as prototyping. If we keep a healthy separation of [shall we say] mission critical application and entertainment, today, as far as normal users are concerned, a good 99% is pretty well defined. We are now developing stuff users don't want, rent seeking schemes and prisons therefore.
Not sure if it was my failure to predict or the industries but I thought the most obvious requirements in the obvious applications would find their way into the high level language abstractions (in increasingly large chunks) and gradually migrate to lower language features and so on closer to the metal until the email client is just an array of similar email processors that can be powered on with some basic query. Have a mailto with params, a new mail notification with some custom sounds entirely separate from other audio, some way to export the attachments and the database i/o preferably with a mechanical switch that completely rules out any other process accessing the mailbox unless the user specifically enables it. Yeah, it should probably beep loudly for as long as remote reading or writing is enabled with a red led blinking above the tumbler switch.
That way no one has to ponder how to ruin the protocol, add emoji's, data mine the user, insert ads or otherwise turn email into a first person shooter MMO next level email experience. Regardless what fantastic thing email could grow into it would just not be possible. After all, we've already turned the fantastic document distribution network (www) into a fantastic application platform. Ideally such things should not be possible but it was and we did and the result is ofc wonderful... except that documents are now multi GB advertisement machines that make 500+ requests. (I cant even view the images in this topic because this laptop cant do such websites) Email has the potential to be a superior application platform much superior to the www but I really hope(ed) we could glue its components into place. (toasters that cant run doom)
The next chunk of hardware can do news groups, one for IRC, one for torrents, one for word processing, one for tabular data, one with maps, one with a web browser, a real terminal(!) and eventually we can have a hardware implementation of HN.
Each such application can have its own signal from the keyboard and mouse and its own video output. Some other chip to combine the pictures into windows with some title validation so that one cant mimic hardware implementations without the user knowing it.
I was completely wrong or was I?
That wonderful pdf in the topic makes an analogy replacing a single supper fast bar tender with multiple bar tenders but this seems a poor fit.
The general purpose stuff is like a college degree. It is some college! Its product is state of the art and it is improving all the time.
But if you want to develop, manufacture and finance the development of the next level drink dispenser you cant keep throwing [however excellent] college graduates at it and expect it to scale.
Our college is to produce the finest surgeons who are also the finest pilots, the best mathematicians, greatest artists and stand up comedians.
That hardware outlook would have been rational in those days. The popularization of computing was a double-edged sword and commerce corrupted efficiency. It's no good selling people reliable PCs with easily replaceable parts if you want to make money on hardware and software. Today in a triumph of marketing and needless consumption people buy laptops for no apparent reason plus phones more powerful than their old laptops and PCs are becoming edge-cases. Each OS release refuses to work on older hardware. Even Linux drops support. On PCs you can plug in extra processors but only your modern-day prototypers/prototypists (software developers), oddballs like film post processing houses, scientists and gamers tend to bother. It's reaching the point even screens can barely be purchased without corrupting advertisements, internet connections and spyware.
Can't say I follow your whole line of reasoning but I agree the faddishness of, say, frontend environments does favor a, say, LISP implementation with code generation to exploit the next app-market with rejigs of yesteryears' algorithms. Classic games, utilities, etc. Just a new target layer and profit. Let the deployment environment evolve and invest in something abstract enough for inherent stability.
Some of the better facets of today's environment are popular enthusiasm for technology, easy and fast connectivity, and nominal availability of funding. I agree that systems thinking tends to be learned through implementation and maintenance, not taught.
Speaking of drinks, I need a drink: for tomorrow I am scaling a drink dispenser.
Oh I see what you're saying. It's analogous to the old Beowulf cluster jokes.
That's basically the computer I want: 64 thousand cores with high speed interconnect appearing as a single address space (ideally on a single chip) so I can finally get real work done on embarrassingly parallel workloads that currently require me to switch to a different level of abstraction with shaders or Python math frameworks or whatever. I just want to be able to do ordinary C-style shell programming, piping immutable data around, without having to worry whether the data's on the video card or anywhere else. Which currently isn't possible at scale affordably.
What use would the typical user have for such a thing? Not much. I'm probably looking too far ahead to solve problems which people don't know exist yet.
For example, I wanted this computer to evolve something like GitHub Copilot back around 2005 after reading Genetic Programming III by John Koza. It would basically fill in the code automagically for TDD. Which would liberate programmers from the minutia that even then had swallowed all of their time.
Now we have these new tools making that possible, albeit in a roundabout way that took many thousands of developers many years of concerted effort to achieve. My heart's not in that kind of approach. I wanted to keep things simple and generic and have computers do most of the work via better compilers, using existing languages with no special intrinsics or libraries. So we'd write ordinary for-loops in C for our own blitters, not have to deal with the additional mental workload of learning and dealing with the idiosyncrasies of OpenCL or CUDA.
And that goes for everything. I don't want React, I want a DOM that isn't slow. I want all databases to emit events like Supabase and Firebase. I want all data structures to be immutable unless marked mutable, in order to avoid promises and monads. I want pattern matching, and avoiding the use of null in data structures. I want duck typing, not inheritance. I wish that the "final" and "sealed" keywords were illegal. I wish that we could hook into and/or override any getter and setter, to allow for more reactivity in our programs. I want doubly-linked references or some way to detect what's watching my state variables. I wish that all languages had aspect-oriented programming. Heck, I wish that more languages had macros. What we thought was "simpler" ended up just being "easier", which stranded us on the local maximums we're on today.
Just on and on and on. I feel like I'm on a different programming branch than the rest of the world is. Probably because I'm looking at solving problems outside of the profit motive. Which makes me feel crazy some days, or at the very least beat down and exhausted. It's been going on so long that I feel used up. Like even if someone gave me the tools I need, I don't know if I can summon the wherewithal to make use of them anymore. I mostly think about stuff like switching careers and running away. Maybe it's up to the next generation now.
Edit: that was a bit negative, I'm sorry. I've been trying to be more like Riva on Star Trek TNG and turn a disadvantage into an advantage:
I tend to perceive the negative due to my years as a software developer, so I've become risk-adverse. With so much bad news on social media, I perceive the world as ending on a daily basis. So I've been trying to seek the positive and stay in an upward spiral. Like how you suggested with getting funding. I just don't know where to begin with something like that, or who to talk to.
Absolutely frontend stuff will burn you out as an individual, it's too high churn and low ROI. Most DBs have triggers now, generally implemented in ways which can generate a text-stream to be easily parsed. While introspection suffers in a heterogeneous environment, modern Unix does give you free event generation by subsystem (eg. inotify), lists of subscribers (lsof), configurable kernel-level instrumentation if you need more, etc. so it's not all bad. IMHO much of the local maxima are artifacts of too much low-level programming and not enough higher-level codebases. Programmers eschewing the positive aspects of higher level languages and sticking their head in the sand about C-grade portability and nominal efficiency, at least in part. For funds, begin as suggested: define the problem, make a case either in market or in losses, and start pitching.
Hey you're right, I agree about problems coming from focusing on the wrong level of abstraction, and thanks for your clarity.
I was working on a project and had to install a file watcher for Node.js because the process inside Docker wasn't seeing the file changes from the IDE on the host for some reason, or using too much CPU, can't quite remember. I think it was called Watchman:
They use inotify when possible, but fall back to other methods, including full scan (recursive? bisect? can't remember the term) of the directory and file timestamps.
I hadn't put it together that it could be used to implement reactive programming. But I have made toy workflows with folder watchers using AppleScript on macOS.
For funding, maybe I could try Reddit or something. I'm realizing that many of my problems come from spending too much time in my own head and not keeping up with trends.
In the early 80’s, optical signal processing was the next big thing in array processing. Multiply-accumulates we’re done in optics and on the camera detector, and it was super fast, but the dynamic range was limited to less than 12 bits. By 1990, optical signal processing was dying and parallel array processing was the “next big thing” in array processing. Systolic arrays and transputers were going to be array processing engines of the future. The problem was to optimally fit the algorithm into the computing architecture—-compilers were complicated. By 1995-2000, general purpose processors, operating systems and MATLAB were fast enough to put most of that to bed except for graphics cards and special effects. GPU’s continue to be the latest in the history of array processing hardware solutions. But I believe their days are also numbered with the advent of quantum computing systems and other technologies.
Wtf... I was just talking about transputers with a coworker yesterday. The ST20 was a popular core in early settop boxes(i.e DirecTV) and was based on a lot of transputer concepts.
Just a guess, but before everybody adopted ARM the ST20 that was inherited from Inmos was ST's high end microprocessor, though they had a bunch of other families with 8 bits and such.
Not sure. It's been too long (20 years... Damn). I forget if they needed the horsepower for video decompression or if they had dedicated hw for that. It was definitely before ARM took over that space. ARM was still competing against MIPS, SuperH, Power, etc.
There are a few reasons. I'll talk about two. One is technical in that Inmos had a signal processing business and was strongly staffed in that area. This offered the potential to eventually make a SoC solution that had CPU and MPEG in hardware. The other is that there were some smart people in marketing at Inmos who at some point decided that they would pick a small set of target applications that they expected to be growth areas, and where we had some existing experience, then devote serious dedicated resources to each of those areas. Two of the areas were STB and GPS. The serious resources devoted included engineers who would be pretty much full time available to the OEMs, and were dedicated to their target application. I think it was Richard Onyett who had the STB brief. He spent years working on those design in projects.
Also fwiw, Inmos people always considered the CPUs to be general purpose.
Current day descendent of the transputer is the (AI themed) IPU from Graphcore.
I think they're approximately publically accessible now in ssh to someone's server fashion with a proprietary toolchain. Some talks by the CTO online and some machine documentation on their GitHub.
29 comments
[ 3.7 ms ] story [ 78.4 ms ] thread> The software and hardware implementation of transputer parallel processing systems. Why do we need all this computing power, and how are we going to be provided with it? Modern developments have shown that good software should be intuitive. If the user has learned one program package then the next package, albeit from a different software house, should behave in a similar fashion.
Results:
* https://i.imgur.com/koOGgFI.png
* https://i.imgur.com/BuU8YrX.png
* https://i.imgur.com/7fZplFV.png
* https://i.imgur.com/mrMUHEp.png
The generated images are very stock photo looking. And unfortunately also not very informative..
Prompt:
> A photo in the style of a still from the 1995 science fiction movie Johnny Mnemonic, showing a man sitting in front of a Transputer.
Results:
* https://i.imgur.com/5ESVag2.png
* https://i.imgur.com/8APGO8b.png
* https://i.imgur.com/n38em4Q.png
* https://i.imgur.com/rM4bDit.png
I like these more. Still not sure the output is in any way influenced by the word "transputer" though, as these look like pretty regular computers.
Guess I am left with no choice but to read the PDF itself. And hope that it's worth it :p
That's parallel processing for you...
It was 32 bit but lacked the floating point hardware of the more expensive T8xx series. Later on there were even cheaper T4xx chips, which were relatively easy to get on a PC expansion card with slightly crippled tool chains for occam.
I still have a couple of T414 boards. I mostly run Helios on them: a parallel universe version of Plan9.
> a parallel universe version of Plan9
I've enjoyed learning about Plan9, how would you say they compare as systems?
Like Plan9, Helios has servers that export a namespace into a common tree. The Helios server protocol is very similar to 9p. They appear to have evolved independently though.
Plan9 allows each user to manage their own namespace by mounting stuff into it. In Helios, there’s a shared global tree that spans all the Transputers in the system.
Both are Unix-like, although Helios probably tried harder to maintain a POSIX-like API.
I don't know how practical the tech would have been to scale but I wonder how different computing could have been.
A conceptually somewhat related system (in the sense of a computer as a network of smart-ish components) was the (research prototype) Desk Area Network https://www.cl.cam.ac.uk/research/srg/netos/projects/archive...
Mainframes had significantly powerful IO processors, meanwhile modern PCs contain many processors linked by effectively an internal network. With the right network hardware you can DMA to another system too. So I guess the lines have always been a little blurry between systems!
They were an absolute joy to work with. You would structure your code into tasks that could be performed in parallel, with a simple queue for inter-task communication. You could then debug the code on a single transputer (residing on an I/O card plugged into your computer).
The production board typically contained several transputers, all connected through serial links, and with one off-board link connector. To upload your code to production, you connected a link from the transputer on your dev card to the production board, placed the board in "boot from link" mode and downloaded the code to the target. A "placement" file directed where the various tasks should run, so the tasks which ran on a single processor in dev, were loaded into the specified processors on the target. I.e. going from single processor to multiprocessor execution without even requiring a re-compile.
The T800 was the fastest floating-point processor available at the time and blew our previous generation processors out of the water. Everyone was sad when INMOS /SGS Thompson faltered with the development of the T9000 and lost their performance edge, eventually resulting in the demise of the platform.
Btw. Pio2 can be accessed from here: http://www.cs.ox.ac.uk/people/geraint.jones/publications/boo...
I remember when Inmos marketing came up with "We wanted to make occam the FORTRAN of parallel processing". My response was "You have." (a reference to occam-2 having only static arrays and no concept of a record/struct)
Which is remarkable since Tony Hoare is actually also the inventor of the records concept. In the corresponding publication in the Algol Bulletin 21 from 1965 there is even a quote by Occam ;-)
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 ...
How much of what we do on current-era machines is IO-bound? Not a great deal. And when it is, it's usually a network and not a local hardware limitation.
How much would UX improve? Not a great deal, most usage is CRUD/web/vid.
Would new applications become available? Sure. But what are they?
Is the value proposition vs. total addressable market compelling?
If you can convincingly answer the above you can definitely go get funding and do it.
In the 80ś-90ś I thought of software as prototyping. If we keep a healthy separation of [shall we say] mission critical application and entertainment, today, as far as normal users are concerned, a good 99% is pretty well defined. We are now developing stuff users don't want, rent seeking schemes and prisons therefore.
Not sure if it was my failure to predict or the industries but I thought the most obvious requirements in the obvious applications would find their way into the high level language abstractions (in increasingly large chunks) and gradually migrate to lower language features and so on closer to the metal until the email client is just an array of similar email processors that can be powered on with some basic query. Have a mailto with params, a new mail notification with some custom sounds entirely separate from other audio, some way to export the attachments and the database i/o preferably with a mechanical switch that completely rules out any other process accessing the mailbox unless the user specifically enables it. Yeah, it should probably beep loudly for as long as remote reading or writing is enabled with a red led blinking above the tumbler switch.
That way no one has to ponder how to ruin the protocol, add emoji's, data mine the user, insert ads or otherwise turn email into a first person shooter MMO next level email experience. Regardless what fantastic thing email could grow into it would just not be possible. After all, we've already turned the fantastic document distribution network (www) into a fantastic application platform. Ideally such things should not be possible but it was and we did and the result is ofc wonderful... except that documents are now multi GB advertisement machines that make 500+ requests. (I cant even view the images in this topic because this laptop cant do such websites) Email has the potential to be a superior application platform much superior to the www but I really hope(ed) we could glue its components into place. (toasters that cant run doom)
The next chunk of hardware can do news groups, one for IRC, one for torrents, one for word processing, one for tabular data, one with maps, one with a web browser, a real terminal(!) and eventually we can have a hardware implementation of HN.
Each such application can have its own signal from the keyboard and mouse and its own video output. Some other chip to combine the pictures into windows with some title validation so that one cant mimic hardware implementations without the user knowing it.
I was completely wrong or was I?
That wonderful pdf in the topic makes an analogy replacing a single supper fast bar tender with multiple bar tenders but this seems a poor fit.
The general purpose stuff is like a college degree. It is some college! Its product is state of the art and it is improving all the time.
But if you want to develop, manufacture and finance the development of the next level drink dispenser you cant keep throwing [however excellent] college graduates at it and expect it to scale.
Our college is to produce the finest surgeons who are also the finest pilots, the best mathematicians, greatest artists and stand up comedians.
Good luck with that?
Can't say I follow your whole line of reasoning but I agree the faddishness of, say, frontend environments does favor a, say, LISP implementation with code generation to exploit the next app-market with rejigs of yesteryears' algorithms. Classic games, utilities, etc. Just a new target layer and profit. Let the deployment environment evolve and invest in something abstract enough for inherent stability.
Some of the better facets of today's environment are popular enthusiasm for technology, easy and fast connectivity, and nominal availability of funding. I agree that systems thinking tends to be learned through implementation and maintenance, not taught.
Speaking of drinks, I need a drink: for tomorrow I am scaling a drink dispenser.
That's basically the computer I want: 64 thousand cores with high speed interconnect appearing as a single address space (ideally on a single chip) so I can finally get real work done on embarrassingly parallel workloads that currently require me to switch to a different level of abstraction with shaders or Python math frameworks or whatever. I just want to be able to do ordinary C-style shell programming, piping immutable data around, without having to worry whether the data's on the video card or anywhere else. Which currently isn't possible at scale affordably.
What use would the typical user have for such a thing? Not much. I'm probably looking too far ahead to solve problems which people don't know exist yet.
For example, I wanted this computer to evolve something like GitHub Copilot back around 2005 after reading Genetic Programming III by John Koza. It would basically fill in the code automagically for TDD. Which would liberate programmers from the minutia that even then had swallowed all of their time.
Now we have these new tools making that possible, albeit in a roundabout way that took many thousands of developers many years of concerted effort to achieve. My heart's not in that kind of approach. I wanted to keep things simple and generic and have computers do most of the work via better compilers, using existing languages with no special intrinsics or libraries. So we'd write ordinary for-loops in C for our own blitters, not have to deal with the additional mental workload of learning and dealing with the idiosyncrasies of OpenCL or CUDA.
And that goes for everything. I don't want React, I want a DOM that isn't slow. I want all databases to emit events like Supabase and Firebase. I want all data structures to be immutable unless marked mutable, in order to avoid promises and monads. I want pattern matching, and avoiding the use of null in data structures. I want duck typing, not inheritance. I wish that the "final" and "sealed" keywords were illegal. I wish that we could hook into and/or override any getter and setter, to allow for more reactivity in our programs. I want doubly-linked references or some way to detect what's watching my state variables. I wish that all languages had aspect-oriented programming. Heck, I wish that more languages had macros. What we thought was "simpler" ended up just being "easier", which stranded us on the local maximums we're on today.
Just on and on and on. I feel like I'm on a different programming branch than the rest of the world is. Probably because I'm looking at solving problems outside of the profit motive. Which makes me feel crazy some days, or at the very least beat down and exhausted. It's been going on so long that I feel used up. Like even if someone gave me the tools I need, I don't know if I can summon the wherewithal to make use of them anymore. I mostly think about stuff like switching careers and running away. Maybe it's up to the next generation now.
Edit: that was a bit negative, I'm sorry. I've been trying to be more like Riva on Star Trek TNG and turn a disadvantage into an advantage:
https://www.youtube.com/watch?v=fA6ijml7rUw
I tend to perceive the negative due to my years as a software developer, so I've become risk-adverse. With so much bad news on social media, I perceive the world as ending on a daily basis. So I've been trying to seek the positive and stay in an upward spiral. Like how you suggested with getting funding. I just don't know where to begin with something like that, or who to talk to.
I was working on a project and had to install a file watcher for Node.js because the process inside Docker wasn't seeing the file changes from the IDE on the host for some reason, or using too much CPU, can't quite remember. I think it was called Watchman:
https://facebook.github.io/watchman/
There are others:
https://stackoverflow.com/questions/13695046/watch-a-folder-...
They use inotify when possible, but fall back to other methods, including full scan (recursive? bisect? can't remember the term) of the directory and file timestamps.
I hadn't put it together that it could be used to implement reactive programming. But I have made toy workflows with folder watchers using AppleScript on macOS.
For funding, maybe I could try Reddit or something. I'm realizing that many of my problems come from spending too much time in my own head and not keeping up with trends.
Also fwiw, Inmos people always considered the CPUs to be general purpose.
I think they're approximately publically accessible now in ssh to someone's server fashion with a proprietary toolchain. Some talks by the CTO online and some machine documentation on their GitHub.