3 ms·

You can write a Forth-like in a few lines of a modern language and then keep expanding it. There are Forths for the smallest systems and challenges of minimal i

You can write a Forth-like in a few lines of a modern language and then keep expanding it. There are Forths for the smallest systems and challenges of minimal instruction set Forth, like [0]. The article [0] explains what people (and myself) are really happy about having this around: > Let's pretend I've wired the 68HC11 so that port A pin 01 controls an LED. I can't remember whether a 0 or a 1 turns it on and I'm not sure whether it works. I look in the data book and find that address zero is the port A data address. Although the LED only uses a single bit of port A I don't have anything else connected so I'll just set the whole byte on or off and see what happens. Without that, embedded work is far more annoying. And I do like the way it works; every so many years, I start implementing my own to figure out if it's really not possible to make something modern [1] (written to play around with Xamarin apps and ASP.NET servers without having to wait 9 hours for the compile & deploy to finish, so in the spirit of Forth indeed) with it which always falls over on stack manipulation, which gets incredibly annoying when programs grow; you waste so many instructions just to line up the stack correctly to execute a some more complicated word. We currently have a hybrid language (hopefully released this year) with datatypes, stack, (reactive) variables etc, but that is getting rather huge (for a Forth) and, because of other features we have, it's more like a Frankenlanguage, marrying Forth & Lisp... That works well but not anything usable in embedded or in the spirit of the original Forth, besides spelonking/scripting systems. [0] https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html https://pages.cs.wisc.edu/~bolo/shipyard/3ins4th.html [1] https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d5c6a https://gist.github.com/tluyben/16ee2645c4c8aed813005d51488d...

syntheweave 4y ago
Forth semantics work nicely as unstructured glue, I've found. As you start getting into the weeds of algorithm design it becomes more of a puzzle. But that also makes sense, in a Forther context. The most Forth-like thing to do is not to start abstracting and imposing structure so that you can have a configurable algorithm, but to define down the problem to a table of static results, and thus complete the circle of "code is data". I believe Chuck Moore said something to the effect of Forth being in the workflow and mindset: once you have a problem defined to need that much complexity of automation, it's not a problem solved by Forth-the-language. Of course, Moore also has done some algorithmically complex things with Forth-the-language, so I might be off-base in that assessment.

syntheweave 4y ago

Forth semantics work nicely as unstructured glue, I've found. As you start getting into the weeds of algorithm design it becomes more of a puzzle. But that also makes sense, in a Forther context. The most Forth-like thing to do is not to start abstracting and imposing structure so that you can have a configurable algorithm, but to define down the problem to a table of static results, and thus complete the circle of "code is data". I believe Chuck Moore said something to the effect of Forth being in the workflow and mindset: once you have a problem defined to need that much complexity of automation, it's not a problem solved by Forth-the-language. Of course, Moore also has done some algorithmically complex things with Forth-the-language, so I might be off-base in that assessment.