127 karma · joined July 4, 2022
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 mean, in general, for the hardware that already exists, that's what the HAL (Hardware Abstraction Layer) of the operating system tries to do.
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.
* TinyBasic (1975) was specified (and sometimes implemented) as a VM https://en.wikipedia.org/wiki/Tiny_BASIC
* Apple Pascal (1979) was a UCSD Pascal system. https://en.wikipedia.org/wiki/Apple_Pascal
* The COSMAC VIP computer/console's (1977) games were programmed in CHIP-8, a VM. https://en.wikipedia.org/wiki/CHIP-8
* Scott Adams' text adventures (1978+) used an application-specific VM. https://en.wikipedia.org/wiki/Adventure_International
* Wozniak's SWEET16 contained in Apple II Integer Basic (1977) https://en.wikipedia.org/wiki/SWEET16
* If you count Forth as a VM, it was pretty common. https://en.wikipedia.org/wiki/Forth_(programming_language)
[0]: https://learn.microsoft.com/en-us/sysinternals/resources/win...
[1]https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
[0] https://en.wikipedia.org/wiki/Mercury_(programming_language)
Apart from Occam, there where C, C++ and Fortran compilers. Targeting the transputer is not more difficult than any other stack machine (like the JVM, the .Net CLR, CPython or Pascal p-code).
The weird/interesting thing about the transputer is that it is also an operating system: two task queues (high/low priority), preemptive scheduling and communication through channels (that can be one of the 4 serial ports or memory based).
Structured Analysis and System Specification, Tom DeMarco, 1978.
[1] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
[2] https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf
But yes, I've been in environments where automated checks and communication during the previous steps nearly completely replaced the need for PRs. The "learning opportunities" happened, but almost always outside a formal code review. 3 devs + PO, competent, limited scope, same room, whiteboards.
Nothing magical behind that "etc.". Formatter, linter, unit tests, integration tests and code coverage in CI to keep you honest. Load tests launched manually to detect performance regressions, memory leaks and race conditions. Specific tools vary by language and product. You can do much more but for most products it's probably over-killing.
For each claimed benefit there's another practice that is better suited, usually automatic, and should have been already implemented. For example, for catching regressions, a reasonably complete test suite. For formatting issues, IDEs and autoformat on commit. For latent errors, static analyzers, linters, run-time instrumentation, etc.
Things that cannot be automated, like understanding of the problem, design tradeoffs, etc. should have been discussed with the team before the PR, with or without pair programming.
Now, going back to reality, if all of the above is working, the PR should be a breeze and there wouldn't be much debate about them.
[1] https://mitpress.mit.edu/9780262691635/the-art-of-prolog/
[2] https://direct.mit.edu/books/oa-monograph/4663/Turtle-Geomet...