5 ms·

Very interesting, though I have to wonder if this wouldn’t become incredibly hard to read. You sort of always put the horse before the cart. Especially the if i

by toxik 5y ago

Very interesting, though I have to wonder if this wouldn’t become incredibly hard to read. You sort of always put the horse before the cart. Especially the if is incredibly difficult to parse, as the condition is already on the stack, AND the two branches. This is quite the reverse of what imperative languages do, which mimics natural language: if x then y else z.

lupire 5y ago
Stack/RPN languages are nice because they are easy to evaluate left to right, because you collect the arguments before you call the function. The stack is reduced as soon as possible, so max execution stack size is equal to the essential complexity of the calculus, for eager-evaluation languages. "Traditional" Verb-Object order is tricky because you have to save the whole stack of functions before you can start reducing anything. But it's nice if you have partial/lazy evaluation and might discard argument/function calls without evaluating them. For human UI, it's trivial to view/edit a program displayed in reverse, and add some redundant parentheses, for an applicative syntax, if you like.
- agumonkey 5y ago
  To me stack language helped my brain forget about intermediate couplings, where in imperative language you have to imagine and manage data structures with operation around. When all you have is a stack, it's one variable less to worry about, you focus your energy on primitive ops.
- potiuper 5y ago
  Verb-Object order is not traditional as English is SVO, and Latin by "tradition" puts it at the end; nor does the whole stack of functions have to be saved before reduction can start see the sum or product operators or "verbs".
  - lupire 5y ago
    English instructions (programs) are Verb-Object with no Subject.
    - potiuper 5y ago
      English commands are still SVO, but the subject may be omitted when it is able to be inferred. Some verbs do not allow inference, i.e. fetch or get. "Get water" may mean "[you] get [me or us] water", or it could mean you get yourself water. The subject is also not able to be parsed as a subject by putting it [the subject] as the first word of the object as "[you] get 'you' water" would mean the command to get water for yourself instead of "you get [me or us] water". Additionally, the uniform function call syntax does not apply to English: "Get(Water,[context])" is not the same as "Water.Get([context])", which is even more ambiguous that could mean "Get water" - see above - or that the water absorbed something like "Water get [it/salt/fire]". Also, to clarify Latin by "tradition" puts the verb at the end of the sentence.
carapace 5y ago
You get used to it. Like Forth, the "killer app" of this RPN syntax is the ability to factor and refactor your code, along with the simple stack-based execution model this allows the code to pretty closely reflect the essential mental model of the problem you're trying to solve. There is a very precise mathematical model for this in Category Theory but I'm not a good enough mathematician to attempt to elucidate it. If you're "doing it right" your code is evolving towards something like the Kolmogorov complexity of the domain/problem. Chuck Moore pointed out that Forth programs can often be smaller than the equivalent program written in ASM. Anyway, the result is that you have a lot of small definitions, but each one captures a single coherent thought about your program, so it's easy to read. Plus you get used to the RPN and stack themselves, which makes it easier.
- Banana699 5y ago
  >If you're "doing it right" your code is evolving towards something like the Kolmogorov complexity of the domain/problem. Any pointers to where this is elaborated on more precisely? Specifically, I'm skeptical about the universality of the claim, Forth allows you to approximate the essential complexity of _any_ problem ? I'm not an enemy of Forth but every language must surely make some things awkward right?
  - carapace 5y ago
    > Any pointers to where this is elaborated on more precisely? No, not off the top of my head. There is "Thinking Forth" by Leo Brodie (it's a whole book but worth the read. You can get official free PDFs here: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ ) It's a natural consequence from the ease of refactoring. Boilerplate and repetitious stuff gets refactored, leaving just the actual gnarly bits to take up most of the LoC. > every language must surely make some things awkward right? I think there's some theorem to that effect, no? (I want to say Rice's Theorem but that's not it.) Forth is typically implemented in such a way as to give easy access to the underlying hardware, so in theory (and often in practice too) if there's some faculty you're missing from some other language or execution model you can implement it in Forth. People have made, e.g. object models and logic engines in Forth.
astrobe_ 5y ago
In my opinion, some concatenative go one or two steps too. Forth is more pragmatic and less academic, and let you do things the (almost) normal way: : min 2dup < if drop else nip then ; If you want to write programs that solve your daily problems you use normal Forth. If you want to write a PhD or play, you use the fancy stuff.
codr7 5y ago
It's a kind of puzzle, much like the shift register memories of old, by keeping track of the order of your data you get rid of the requirement for addressing. So yes, from my experience, it will take more effort to process mentally; simply because you're doing more work.

by toxik 5y ago

lupire 5y ago

Stack/RPN languages are nice because they are easy to evaluate left to right, because you collect the arguments before you call the function. The stack is reduced as soon as possible, so max execution stack size is equal to the essential complexity of the calculus, for eager-evaluation languages. "Traditional" Verb-Object order is tricky because you have to save the whole stack of functions before you can start reducing anything. But it's nice if you have partial/lazy evaluation and might discard argument/function calls without evaluating them. For human UI, it's trivial to view/edit a program displayed in reverse, and add some redundant parentheses, for an applicative syntax, if you like.

agumonkey 5y ago
To me stack language helped my brain forget about intermediate couplings, where in imperative language you have to imagine and manage data structures with operation around. When all you have is a stack, it's one variable less to worry about, you focus your energy on primitive ops.
potiuper 5y ago
Verb-Object order is not traditional as English is SVO, and Latin by "tradition" puts it at the end; nor does the whole stack of functions have to be saved before reduction can start see the sum or product operators or "verbs".
- lupire 5y ago
  English instructions (programs) are Verb-Object with no Subject.
  - potiuper 5y ago
    English commands are still SVO, but the subject may be omitted when it is able to be inferred. Some verbs do not allow inference, i.e. fetch or get. "Get water" may mean "[you] get [me or us] water", or it could mean you get yourself water. The subject is also not able to be parsed as a subject by putting it [the subject] as the first word of the object as "[you] get 'you' water" would mean the command to get water for yourself instead of "you get [me or us] water". Additionally, the uniform function call syntax does not apply to English: "Get(Water,[context])" is not the same as "Water.Get([context])", which is even more ambiguous that could mean "Get water" - see above - or that the water absorbed something like "Water get [it/salt/fire]". Also, to clarify Latin by "tradition" puts the verb at the end of the sentence.

carapace 5y ago

You get used to it. Like Forth, the "killer app" of this RPN syntax is the ability to factor and refactor your code, along with the simple stack-based execution model this allows the code to pretty closely reflect the essential mental model of the problem you're trying to solve. There is a very precise mathematical model for this in Category Theory but I'm not a good enough mathematician to attempt to elucidate it. If you're "doing it right" your code is evolving towards something like the Kolmogorov complexity of the domain/problem. Chuck Moore pointed out that Forth programs can often be smaller than the equivalent program written in ASM. Anyway, the result is that you have a lot of small definitions, but each one captures a single coherent thought about your program, so it's easy to read. Plus you get used to the RPN and stack themselves, which makes it easier.

Banana699 5y ago
>If you're "doing it right" your code is evolving towards something like the Kolmogorov complexity of the domain/problem. Any pointers to where this is elaborated on more precisely? Specifically, I'm skeptical about the universality of the claim, Forth allows you to approximate the essential complexity of _any_ problem ? I'm not an enemy of Forth but every language must surely make some things awkward right?
- carapace 5y ago
  > Any pointers to where this is elaborated on more precisely? No, not off the top of my head. There is "Thinking Forth" by Leo Brodie (it's a whole book but worth the read. You can get official free PDFs here: http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ ) It's a natural consequence from the ease of refactoring. Boilerplate and repetitious stuff gets refactored, leaving just the actual gnarly bits to take up most of the LoC. > every language must surely make some things awkward right? I think there's some theorem to that effect, no? (I want to say Rice's Theorem but that's not it.) Forth is typically implemented in such a way as to give easy access to the underlying hardware, so in theory (and often in practice too) if there's some faculty you're missing from some other language or execution model you can implement it in Forth. People have made, e.g. object models and logic engines in Forth.

astrobe_ 5y ago

In my opinion, some concatenative go one or two steps too. Forth is more pragmatic and less academic, and let you do things the (almost) normal way: : min 2dup < if drop else nip then ; If you want to write programs that solve your daily problems you use normal Forth. If you want to write a PhD or play, you use the fancy stuff.

codr7 5y ago

It's a kind of puzzle, much like the shift register memories of old, by keeping track of the order of your data you get rid of the requirement for addressing. So yes, from my experience, it will take more effort to process mentally; simply because you're doing more work.