> it only brings you down the abstractions ladder. Ironically I'd say you're both right and wrong at the same time because of the somewhat paradoxical nature o

> it only brings you down the abstractions ladder. Ironically I'd say you're both right and wrong at the same time because of the somewhat paradoxical nature of concatenative languages: you're closer to the metal (especially with Forth) but at the same time working with Forth is an exercise in abstracting everything away. The strength/weakness is that it has only one hammer to do so: defining Forth words to manipulate the stack ("words" == Forth lingo for functions, more or less). It has a Lisp-like minimalism (you can almost think of it as postfix-Lisp in some sense). The Fun class you describe misses the point entirely of the minimalism of Forth or Joy - the complete lack of syntax is a feature that makes concatenative language inherently composable in ways that other languages can only dream of. In a language like Python, you could compose three function calls like so: y = foo(x) z = bar(y) w = baz(z) In a language like Joy (or Forth, or Factor) you would write: x foo bar baz .. where the x is only included if we assume it is a stored value that has to be put on the stack first. Ok, sure. But here is the thing: imagine that I wish to refactor calls to foo and bar into their own function (this particular example is childishly simple of course, but I think it gets the conceptual point across). Compare the Python and the Joy ways of doing that: def bla(x): return bar(foo(x)) DEFINE bla == foo bar The difference is small but significant. Because the concatenative languages have no function application, refactoring is often a simple cut/paste operation, followed by one big find/replace. You can literally split (almost) any piece of code into parts at any point, define those parts as new words, and the result would be valid code. Precisely because of the brutal minimalism at play here. The trade-off is an upfront cost of having to structure the entire program around stack operations, and thinking in a postfix way of doing operations. I'm not saying that makes them better - I like my type checking very much, and in the right amounts a bit of boilerplate makes code a lot more self-documenting. But I also think that learning how to solve problems the "Forth" way is a good programming exercise.