ssrc

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.

I remember the books on undocumented functionality like

https://archive.org/details/Undocumented_DOS

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...

What's remarkable about Infocom's z-machine is the level of sophistication and polish vs the intended application, maybe unsurprising coming from MIT graduates with access to a PDP-10 as a development platform. Otherwise the use of virtual machines was, maybe not common, but not unusual.

* 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)

"Well, Steve [Jobs], I think there's more than one way of looking at it. I think it's more like we both had this rich neighbor named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it." - Bill Gates

https://folklore.org/A_Rich_Neighbor_Named_Xerox.html

Yep, if you have in one hand "Inside Windows NT" by Helen Custer (or one of its successors, "Windows Internals"[0]) and on the other "VMS Internals and Data Structures"[1]...

[0] https://learn.microsoft.com/en-us/sysinternals/resources/win...

[1] https://bitsavers.org/pdf/dec/vax/vms/training/

Like any other discussion of this kind[1] I think this one will go nowhere because 1) the question doesn't have a black and white answer, it's a sliding scale. 2) almost no one is giving examples of what they mean; if they were, they could find that they agree with the person they are replying to. And 3) most people will discard the experiences of people they disagree with "you didn't even try! maybe the problem is you!", and this is easy because this is the internet and the other person can be (is probably?) making it up.

[1]https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...

The most similar thing to a "static" Prolog would be Mercury[0] or Turbo Prolog[1]. OTOH, if you want an embed-able logic programming library there is the mini/microKanren family[2].

[0] https://en.wikipedia.org/wiki/Mercury_(programming_language)

[1] https://en.wikipedia.org/wiki/Visual_Prolog

[2] https://en.wikipedia.org/wiki/MiniKanren

VxWorks, LynxOS or RTEMS. RTEMS is open source.

I mean, it's fun and interesting bullshit that cheats a lot. I'm sure that you could emulate a MIPS using a one-bit processor like the MC14500[0] with enough supporting hardware, real or virtual. Looking forward to it, Dimitry.

[0] https://en.wikipedia.org/wiki/Motorola_MC14500B

Months ago I found this presentation on youtube, "Re-architecting SWIS for X86-64"[0], about how VMS was ported from VAX to Alpha to Itanium to x86 that did not have the same AST behaviour.

[0] https://www.youtube.com/watch?v=U8kcfvJ1Iec

I remember reading those books (ok, it was the 4.3 BSD edition instead of 4.4) alongside Bach's "The Design of the Unix Operating System" and Uresh Vahalia's "UNIX internals: the new frontiers" (1996). I recommend "UNIX internals". It's very good and not as well known as the others.

And then we send them to Jupiter.

https://en.wikipedia.org/wiki/Victory_Unintentional

Occam looks like a concurrent Pascal, not like a Forth. The transputer had a 3-element hardware stack but it was used more like a cache for the workspace (kind of the memory stack). You can still find around the manual "Transputer Instruction Set - a compiler writer's guide" that explains how you would do that (section 5.3 Expression Evaluation).

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).

Just for the moment, consider the idea of implementing the requirements shown in the figure using a network of connected microcomputers, one microcomputer per bubble.

Structured Analysis and System Specification, Tom DeMarco, 1978.

You are right, but in this case I have some sympathy for the argument. If all the technical terms in one methodology (scrum, sprint, velocity, commitment, ...) look like they were chosen not in good faith, well...

No, that would be just a component of this system. It looks more like "Distributed OSGi done right" or CORBA's endgame as prophesied by Grady Booch in the 90s. Historically these kind of systems have not worked very well[1][2] but who knows.

[1] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

[2] https://scholar.harvard.edu/files/waldo/files/waldo-94.pdf

Depending on the meaning of "small-scale kafka", both RabbitMQ and redis do support streams.

For the tooling part, I suppose it's something like a "golden path"[1] where you have predefined templates from which the developers may choose the most appropriate for their problem.

[1] https://cloud.redhat.com/blog/designing-golden-paths

I have no strong feelings about PRs (usually). I was acting as devil's advocate to try to answer supremekurt question in a positive way (others have pointed out the negative ways) and I ended up writing almost exactly what the article says in "Code reviews. Isn't it the past?".

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.

Devil's advocate: PRs are unnecessary and insufficient (this is the article's introduction).

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.

I think it's monorepo vs multi-repo, and since Linux maintainers update the drivers (I believe) when internal APIs change, and the internal APIs are not stable, monorepo seems more practical.

It seems they don't have all the books that are on MIT open access. I can't find "The Art of Prolog"[1], for example. But maybe they are downloading only the ones with the "free" tag like "Turtle Geometry"[2] (Last time I looked at this one it was one pdf for each chapter).

[1] https://mitpress.mit.edu/9780262691635/the-art-of-prolog/

[2] https://direct.mit.edu/books/oa-monograph/4663/Turtle-Geomet...

Logo would be the most obvious one.

Well, there's the relatively recent Schön scandal.

https://en.wikipedia.org/wiki/Sch%C3%B6n_scandal