6 ms·

>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 elabora

>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.
zozbot234 5y ago
Forth works quite well for problems that fit its stack-based model, but that's not every problem. For instance, having to manage and permute data on the stack is often more awkward than doing the same things in languages that use ordinary variables. And working with only a single stack at a time, it's not clear how such languages might express parallelism, which is otherwise a very natural expectation for a functional language. Even things like complex data types, pattern matching etc. get needlessly awkward.
- codr7 5y ago
  It's quite possible to add variables to Forth, which means you can pick the best tool. Keeping computations on the stack then feels similar to the push to keep computations out of the IO monad in Haskell.
t-3 5y ago
In concatenative languages, every nontrivial program is a DSL. The difficulty is that other people have to learn the base language and your DSL to read or modify your programs, on top of the stack-based nature of most concatenative languages hiding the dataflow between functions.

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.

zozbot234 5y ago

Forth works quite well for problems that fit its stack-based model, but that's not every problem. For instance, having to manage and permute data on the stack is often more awkward than doing the same things in languages that use ordinary variables. And working with only a single stack at a time, it's not clear how such languages might express parallelism, which is otherwise a very natural expectation for a functional language. Even things like complex data types, pattern matching etc. get needlessly awkward.

codr7 5y ago
It's quite possible to add variables to Forth, which means you can pick the best tool. Keeping computations on the stack then feels similar to the push to keep computations out of the IO monad in Haskell.

t-3 5y ago

In concatenative languages, every nontrivial program is a DSL. The difficulty is that other people have to learn the base language and your DSL to read or modify your programs, on top of the stack-based nature of most concatenative languages hiding the dataflow between functions.