3 ms·

Forth is an interesting case. It's really unproductive to build complex systems with. If you try, you will probably be frustrated. Instead it forces you to try

by lukego 5y ago

Forth is an interesting case. It's really unproductive to build complex systems with. If you try, you will probably be frustrated. Instead it forces you to try really hard to find a cheating short-cut to solve the problem as few moving parts as possible. Just one simple example. The 'struct' language feature is 1500 LOC in Lisp but only 10 LOC in FORTH (see below.) Are they equivalent? No, the Lisp one has lots of bells and whistles, while the FORTH one is minimalist in the extreme. If you tried to write the feature-complete Lisp version in FORTH you would probably find it very difficult and unproductive. So you wouldn't do that. And this to me is what FORTH's peculiar brand of efficiency is all about. If FORTH were a bar the only drink on the menu would be tap water. That bar would be extremely efficient to run. Lisp: https://github.com/sbcl/sbcl/blob/master/src/code/defstruct.lisp https://github.com/sbcl/sbcl/blob/master/src/code/defstruct.... FORTH: https://github.com/openbios/openfirmware/blob/master/forth/lib/struct.fth https://github.com/openbios/openfirmware/blob/master/forth/l...

ipnon 5y ago
Elixir and Erlang, in my estimation, similarly force simplicity by the nature of its own constraints, in this case massively concurrent processes designed to fail. The difference is constraining the OS interface instead of the bare metal interface. The antithesis is maybe the object orientated model where interfaces are mutable and state is unreliable.
carapace 5y ago
Chuck Moore used to carry around a 3D wireframe CAD program on a deck of punchcards that fit in his shirt pocket.
fouric 5y ago
I think you've identified one of the essential parts of the design of Forth: it makes it very easy to implement simple systems, and very difficult to implement complex systems. In other words, polynomial O(n^a) complexity, where "a" is large, but the hidden constant k is small. Making good use of Forth seems to be contingent on identifying situations where you want to implement a very small and simple system (embedded systems, firmware, OS bootloaders, tiny IoT devices?), and using Forth there - and avoiding it like the plague in all other cases. I very much doubt that implementing a VLSI CAD program, where you want as many features to help your design as possible (features which necessarily incur a complexity cost), is a good use of Forth, for example.

by lukego 5y ago

ipnon 5y ago

Elixir and Erlang, in my estimation, similarly force simplicity by the nature of its own constraints, in this case massively concurrent processes designed to fail. The difference is constraining the OS interface instead of the bare metal interface. The antithesis is maybe the object orientated model where interfaces are mutable and state is unreliable.

carapace 5y ago

Chuck Moore used to carry around a 3D wireframe CAD program on a deck of punchcards that fit in his shirt pocket.

fouric 5y ago

I think you've identified one of the essential parts of the design of Forth: it makes it very easy to implement simple systems, and very difficult to implement complex systems. In other words, polynomial O(n^a) complexity, where "a" is large, but the hidden constant k is small. Making good use of Forth seems to be contingent on identifying situations where you want to implement a very small and simple system (embedded systems, firmware, OS bootloaders, tiny IoT devices?), and using Forth there - and avoiding it like the plague in all other cases. I very much doubt that implementing a VLSI CAD program, where you want as many features to help your design as possible (features which necessarily incur a complexity cost), is a good use of Forth, for example.