4 ms·

English is not native to me so I'm not sure it is me that misunderstanding you or the reverse. By "no clear line", I mean something like building the OS on top

English is not native to me so I'm not sure it is me that misunderstanding you or the reverse. By "no clear line", I mean something like building the OS on top of some of the language modules. Just like what biscuit did, the runtime and some other packages were integrated as a part of the OS. Such an approach brings inevitable impact to the project, because there will be no longer any easy way to keep up with the new features/progress in the language. On the other hand, you stated > I think using a language with most features implemented outside of the core language implementation, but rather in libraries, helps a lot here. I don't see how your experience contradicts with my previous statement. Would you clarify more? Also, I don't know Forth before. Thanks for enlarging my view.

pjmlp 6y ago
See Oberon, Smalltalk, Interlisp-D, Lisp Machines, Mesa/Cedar as well.
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.

pjmlp 6y ago

See Oberon, Smalltalk, Interlisp-D, Lisp Machines, Mesa/Cedar as well.

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.