ssrc

Lisp machines come to mind, like the Symbolics 3600.

Arguably this started in the mainframe world in 1969, with IBM "unbundling" software and services from hardware sales, after the US government launched an antitrust suit against them.

Some patterns in the GoF book only apply to C++/Java as they were in 1994, but I don't see any reason why other languages would have no useful patterns. The Linux kernel (C) is full of patterns for example.

Funny thing, Peter Norvig also has this position, that patterns only apply to languages like Java, but his book on Lisp and the Python course he had on Udemy (?) are super-pattern-y.

If you are ok with the performance you can obtain from an FPGA, you could do it now. Look at FPGA hardware-software co-design and related stuff.

If you mean, in general, for the hardware that already exists, that's what the HAL (Hardware Abstraction Layer) of the operating system tries to do.

And the FPGA is a modern day equivalent to an ULA. If they could have put all of the chips in a single programmable one, they would.

I'm old enough to have seen the "written in lisp", "written in ruby", "written in javascript" eras, among others. It's natural.

For me, the "human-readable" part is key. It's not just that the output is e.g. javascript, but that it is more or less human-readable with about the same organization as the original code.

If you implement SKI combinators, or three-address instructions, as functions in javascript, and that's the output of your compiler, I would not call that a transpiler.

'Was' is more likely. The list is from 2003, and if FORTH Inc, the (only? biggest?) remaining forth company hasn't updated it...

VxWorks, LynxOS or RTEMS. RTEMS is open source.