4 ms·
> Obviously this program [in C] contains a lot of things that deal with the computer and not the problem of calculating a sum. Stack based languages replace "d
by jdmichal 7y ago
> Obviously this program [in C] contains a lot of things that deal with the computer and not the problem of calculating a sum.
Stack based languages replace "dealing with the computer" with "dealing with the stack". Except the stack is always invisible, because it's a runtime artifact and not a code artifact. Their front-page example neatly dodges this, but their examples on the about page make this much more visible. For instance, here's their prime finder:
: prime_list
1 - iota 2 + dup dup dup
'* outer swap in not select
;
100 prime_list .
- eequah9L 7y agoStack is cool as long as it's the top element or two that you care about. Anything more complex, and you want (well, I do) some sort of a binding syntax, so that it is possible to refer to the value symbolically. I find all those swaps and dups impossible to reason about.
- codr7 7y agoDup and Swap are all about the two top values though. Otherwise I strongly agree, I like to use bindings for anything non-obvious. In my own designs [0] I tend to add named arguments [1] as well, which helps a lot. [0] https://github.com/codr7/gfoo https://github.com/codr7/gfoo [1] https://github.com/codr7/gfoo#methods https://github.com/codr7/gfoo#methods
- yumaikas 7y agoI've found that there can be some cool stack combinators (like Factor's dip), but binding in stack based languages is nice in that it lets you effectively turn off having to think about the stack in depth, which frees up mental resources for thinking about the problem at hand.