8 ms·

The thing that's wrong with Forth is it promotes eschewing verbal identification of variables for the sake of positional. This is promoted as good mental exerci

The thing that's wrong with Forth is it promotes eschewing verbal identification of variables for the sake of positional. This is promoted as good mental exercise, but is just bad language design. As Rich Hickey said, we humans prefer to identify things in terms of keywords, not positions. For any method with more than a couple parameters, kwargs are more convenient than positional arguments or, worse, implicit args on the stack. This is why concatenative languages are doomed to be just a forgotten cul-de-sac off the highway of the history of programming languages.

andybak 7y ago
Maybe the only problem here is that Forth only really properly supports integers (and floats on a separate stack). If your language didn't come bundled with Vector support you can bet that adding two vectors wouldn't be terribly pretty either. Or at least it wouldn't merely be "+" One can imagine "Forth with a typed Stack" where this would be as simple as "+". Also - Forth can do named identifiers. It's just not the goto technique.
- lebuffon 7y ago
  That's why OForth was invented. http://www.oforth.com/ http://www.oforth.com/
ken 7y ago
I frequently see arguments of the form "X is good; Y doesn't have X; therefore all typeof(Y) are doomed". I don't understand. Didn't you just give a criterion for success? Why can't we make a new Y2 that has X? In this case, it doesn't even seem difficult. I've seen multiple stack-based systems that allow items labels. They don't use them for arg-passing (AFAIR), but I don't see why they couldn't. I'm not even convinced that positional arguments are fatal for language design. Most popular languages today lack named arguments. They're usually only named on the callee side. I'm sure we've all run across a C function call that looked like foo(a, b, c, d, e, f, g, h), and cursed the author under our breath, and then counted out to the argument number we wanted to change. Languages succeed or fail for many reasons, but I don't think I've ever seen "calling convention" be the deciding factor (no pun intended). In the more general sense of concatenative (not necessarily stack-based) languages, Unix pipelines are a common example, and they don't seem to be doomed.
- deleted 7y ago
  [deleted]
carapace 7y ago
> concatenative languages are doomed to be just a forgotten cul-de-sac off the highway of the history of programming languages. I gotta disagree. I've been working with Joy the last couple of years and I think it's possibly a "silver bullet". Interestingly, it sidesteps a lot of the problems with stack manipulation by means of flexible combinators that permit various kinds of higher-order stack/expression manipulation. - - - - Also, see "Compiling to Categories" wherein Haskell is converted to a kind of point-free form very similar to Joy... https://conal.net/papers/compiling-to-categories/ https://conal.net/papers/compiling-to-categories/
dwheeler 7y ago
Many Forth developers do not like using named parameters AKA local variables. That said, they certainly exist, so if that is your only objection to Forth then there are easy ways to solve it. See, for example, http://zedcode.blogspot.com/2011/02/forth-parameter-stack-named-parameters.html http://zedcode.blogspot.com/2011/02/forth-parameter-stack-na...
- dwheeler 7y ago
  I've since discovered that the latest Forth standard, Forth-2012, includes an optional set of Forth words to support local variables. Gory details here (warning, spec-ese): http://forth-standard.org/standard/locals http://forth-standard.org/standard/locals I don't know how widely these are supported in Forth implementations.
  - kragen 7y ago
    All variables in Forth are local variables. They're just, traditionally, statically allocated, like a static variable in a C program. Their scope extends from their declaration to wherever the wordlist they're defined in stops being visible, or until another variable of the same name is defined, which means their scope usually does not extend to the end of your program. I think the spec's choice to term stack-allocated variables "locals" (for what we call "automatic" variables in C) is a bad choice, because it confuses the issue further. When we refer to "local" or "global" variables, normally we are referring to scope, which is a question of over what part of a program a name maps to a particular location (or, in functional languages, sometimes a value). But what we're talking about here is extent or lifetime: during what period of time is a particular location allocated. These are clearly not unrelated concerns, since a name cannot usefully map to an unallocated location, and the same static occurrence of a name can map to multiple different locations when that name is bound on different binding contours, which cannot happen when the name is bound in the global scope; but these two concerns are also not identical, and I think it is important to distinguish them. In Scheme, for example, the scoping rules are the same block-scoping rules we're familiar with from Pascal and C; but the extent of all Scheme values is unlimited — they can continue to exist until the end of the program, regardless of which subroutines have returned. This is also true in the ML family (OCaml, Haskell) and the abundant crop of modern Scheme-descended languages, including JS, Perl5, Python, Lua, and Ruby, but not in C++ or Rust. (Most, though, don't follow Scheme's mind-bending lead in having first-class continuations with unlimited extent, though Ruby does.) So, what the Forth-2012 locals word set provides is names with dynamic or automatic extent: they refer to values that exist during a particular activation of a particular function. It also provides local scoping for names for them, but this is a much less significant change.

andybak 7y ago

Maybe the only problem here is that Forth only really properly supports integers (and floats on a separate stack). If your language didn't come bundled with Vector support you can bet that adding two vectors wouldn't be terribly pretty either. Or at least it wouldn't merely be "+" One can imagine "Forth with a typed Stack" where this would be as simple as "+". Also - Forth can do named identifiers. It's just not the goto technique.

lebuffon 7y ago
That's why OForth was invented. http://www.oforth.com/ http://www.oforth.com/

ken 7y ago

I frequently see arguments of the form "X is good; Y doesn't have X; therefore all typeof(Y) are doomed". I don't understand. Didn't you just give a criterion for success? Why can't we make a new Y2 that has X? In this case, it doesn't even seem difficult. I've seen multiple stack-based systems that allow items labels. They don't use them for arg-passing (AFAIR), but I don't see why they couldn't. I'm not even convinced that positional arguments are fatal for language design. Most popular languages today lack named arguments. They're usually only named on the callee side. I'm sure we've all run across a C function call that looked like foo(a, b, c, d, e, f, g, h), and cursed the author under our breath, and then counted out to the argument number we wanted to change. Languages succeed or fail for many reasons, but I don't think I've ever seen "calling convention" be the deciding factor (no pun intended). In the more general sense of concatenative (not necessarily stack-based) languages, Unix pipelines are a common example, and they don't seem to be doomed.

deleted 7y ago
[deleted]

carapace 7y ago

> concatenative languages are doomed to be just a forgotten cul-de-sac off the highway of the history of programming languages. I gotta disagree. I've been working with Joy the last couple of years and I think it's possibly a "silver bullet". Interestingly, it sidesteps a lot of the problems with stack manipulation by means of flexible combinators that permit various kinds of higher-order stack/expression manipulation. - - - - Also, see "Compiling to Categories" wherein Haskell is converted to a kind of point-free form very similar to Joy... https://conal.net/papers/compiling-to-categories/ https://conal.net/papers/compiling-to-categories/

dwheeler 7y ago

Many Forth developers do not like using named parameters AKA local variables. That said, they certainly exist, so if that is your only objection to Forth then there are easy ways to solve it. See, for example, http://zedcode.blogspot.com/2011/02/forth-parameter-stack-named-parameters.html http://zedcode.blogspot.com/2011/02/forth-parameter-stack-na...

dwheeler 7y ago
I've since discovered that the latest Forth standard, Forth-2012, includes an optional set of Forth words to support local variables. Gory details here (warning, spec-ese): http://forth-standard.org/standard/locals http://forth-standard.org/standard/locals I don't know how widely these are supported in Forth implementations.
- kragen 7y ago
  All variables in Forth are local variables. They're just, traditionally, statically allocated, like a static variable in a C program. Their scope extends from their declaration to wherever the wordlist they're defined in stops being visible, or until another variable of the same name is defined, which means their scope usually does not extend to the end of your program. I think the spec's choice to term stack-allocated variables "locals" (for what we call "automatic" variables in C) is a bad choice, because it confuses the issue further. When we refer to "local" or "global" variables, normally we are referring to scope, which is a question of over what part of a program a name maps to a particular location (or, in functional languages, sometimes a value). But what we're talking about here is extent or lifetime: during what period of time is a particular location allocated. These are clearly not unrelated concerns, since a name cannot usefully map to an unallocated location, and the same static occurrence of a name can map to multiple different locations when that name is bound on different binding contours, which cannot happen when the name is bound in the global scope; but these two concerns are also not identical, and I think it is important to distinguish them. In Scheme, for example, the scoping rules are the same block-scoping rules we're familiar with from Pascal and C; but the extent of all Scheme values is unlimited — they can continue to exist until the end of the program, regardless of which subroutines have returned. This is also true in the ML family (OCaml, Haskell) and the abundant crop of modern Scheme-descended languages, including JS, Perl5, Python, Lua, and Ruby, but not in C++ or Rust. (Most, though, don't follow Scheme's mind-bending lead in having first-class continuations with unlimited extent, though Ruby does.) So, what the Forth-2012 locals word set provides is names with dynamic or automatic extent: they refer to values that exist during a particular activation of a particular function. It also provides local scoping for names for them, but this is a much less significant change.