4 ms·
For me, the lack of readability isn't necessarily about the terseness, per se. It's about trying to keep track of the stack in my head at all times, and the "u
by groovy2shoes 10y ago
For me, the lack of readability isn't necessarily about the terseness, per se. It's about trying to keep track of the stack in my head at all times, and the "unnatural" order that the "keywords" appear in.
<condition> IF <consequent> ELSE <alternative> THEN
is something I still struggle with, even after studying forth (via Leo Brodie's "Starting Forth" and "Thinking Forth") for about 3 months. Something like this I have no trouble with:
IF <condition> THEN <consequent> ELSE <alternative>
but the addition of the (optional) local variables helps me to keep track of the stack more easily (if you could even consider it the stack at that point).
In general, I don't have much trouble with RPN, but a few of the constructs in forth have eluded me...
- deleted 10y ago[deleted]
- dragonwriter 10y agoYeah, I think the choice of keywords in that case isn't great for the structural order that they have to appear in <condition> THEN <consequent> ELSE <alternative> IF would probably be a better order, in the same structure, keeping the same keywords.
- groovy2shoes 10y agoThat's surprisingly much easier for me. I don't know why, but the other order just throws me for a loop every time, and I find myself carefully re-reading the same code multiple times. However, given the kind of metaprogramming power you get in Forth, I don't see why a more straightforward production couldn't be used in this case.
- DonHopkins 10y agoFORTH ?KNOW IF HONK! ELSE FORTH LEARN! THEN