4 ms·
Ah, I think I was seeing a slightly different problem; the problem I saw was that when the OS and compiler start to be tied together tightly enough that changes
by remexre 6y ago
Ah, I think I was seeing a slightly different problem; the problem I saw was that when the OS and compiler start to be tied together tightly enough that changes to one make it necessary to change the other, so anyone working on them needs both skillsets. Forth helps here since the parts of the language that are "baked into" the implementation (i.e. not just standard library code) are extremely minimal; in most of the Forths I implement, even function definition is itself defined in the standard library.
Needing to avoid diverging from an upstream compiler is also somewhat alleviated by (most dialects of) Forth being suitable for OS development out of the box, so patching the compiler isn't often necessary.
Additionally, it's not ridiculous to implement a custom Forth for each project, depending on its needs, which makes tracking an upstream a non-issue. A Forth implementation is far less code than an implementation of C, Go, etc., so it's not very time-consuming, and the way Forth user code is typically written makes it easy to port code between implementations.