[kazinator]

> Depends on how you write and comment.

Unless working in assembly or something of that sort, tend to I comment only on noteworthy matters pertaining to specific logic, not recurring units of basic program structure and their routine connections.

[astrobe_]

The only "extraneous" comments related to the point-free style of Forth are the "stack diagrams" showing the inputs and outputs of a definition/function, when it's not obvious from the code (it very often is when you write one-line definitions).

This is no different from what people do with Doxygen. Nobody prevents anyone from using a Doxygen-like tool with Forth. Or even literate programming if that's your thing.

Inside definitions, if you have to insert a comment to remind yourself what the state of the stack is at that point, very often it means you have failed in some way. Some refactoring or rethinking is needed.

[kazinator]

> Nobody prevents anyone from using a Doxygen-like tool with Forth.

Nobody prevents anyone from writing a perfect solo project from scratch in which their idea of best practices is assiduously adhered to. Then there are projects where other people don't follow one's favorite practices, and projects one inherits that had previous maintainers which didn't follow those practices.

[astrobe_]

Yes, sure. That's why you have VBA, Java, Perl, C, Newlisp, Fortran, Python projects that are maintenance nightmare. Forth is nothing special with regard to this concern. Code quality has a lot more to do with the skills of the writer than the peculiarities of the language.

Except perhaps that you are more concerned with code quality when you know that it will be hard to read a couple of months later if you are sloppy.

Forth is unforgiving in many ways like an old master. There are people who call him a bad teacher, and there are people who listen to him. This is the difference between good students and bad students.

Anyway, the fact that Forth, Inc., has been in business for forty years and is still taking new commercial projects [1] is enough of a proof that Forth is more than just the code written by hobbyists you see on GitHub.

[1] https://wiki.forth-ev.de/doku.php/events:ef2018:forth-in-tha...

[kazinator]

> Forth is nothing special with regard to this concern

When we look at a clump of Forth code that's supposed to be a function, unless there is commentary, we don't know how many arguments it takes or how many values it leaves on the stack.

We don't have this problem with VBA, Java, Perl, C, Newlisp, Fortran or Python.

Forth is an assembly language for a pretty low level stack-based virtual machine. (And such machines are very popular, though rarely programmed by hand.)

It's not a good VM for compiling dynamic languages; it provides no run-time check on mismatched function arguments, and generating code to do that would be inefficient and incompatible with regular Forth function calls. (E.g. we can have a calling convention whereby we push the argument count that the callee will pop and check.)

Forth could be a good target for a static language where function calls are checked at compile time against declarations.

> Forth is unforgiving in many ways like an old master.

Forth is completely forgiving, like an old buffoon. Pass four arguments to a three-argument function? All is forgiven.

[astrobe_]

> Forth is an assembly language for a pretty low level stack-based virtual machine. (And such machines are very popular, though rarely programmed by hand.)

Forth is indeed an assembly language for Forth processors, but Forth was never intended as some sort of intermediate language. It is a programming language for humans since 1970.

It's interesting to note that, unlike Lisp machines and other language-X-processors who are now rusting in museums, "Forth processors" are still being launched in space [1].

So, to anticipated about what you say later, it must be a cosmic buffoon. Better than dying from a slightly cold winter I guess.

> It's not a good VM for compiling dynamic languages

Off topic, but why would you do that anyway? At some point, register-based VMs outperformed stack-based VMs due to the evolution of processors (cache, branch prediction, large register banks) and progresses in compilation techniques.

Forth doesn't need to be "recycled" as a target language. It is useful enough for those who've practiced it long enough to understand its value proposition.

> Forth is completely forgiving, like an old buffoon. Pass four arguments to a three-argument function? All is forgiven.

Lua and Newlisp (and probably other Lisp variants) let you pass more arguments or less arguments to a function; you won't get any warning while the compiler/interpreter silently ignores the extra parameters or fills the missing parameters with nil.

In Forth there are some ways to detect argument mismatches, but really nobody cares about those training wheels. The problem is solved in a different way.

Also, many dynamic languages had to add a "strict mode" because letting people not declare identifiers is not so "user-friendly" after all...

I'll trade any day a language that breaks on stupid typos for a language that breaks because I forgot to push a result. Actually, that's why I did.

[1] https://en.wikipedia.org/wiki/RTX2010

[kazinator]

Using NewLisp as representative of Lisps is a strawman argument. It's a garbage project that is despised by anyone who is serious about Lisp.

ANSI Common Lisp and Scheme do not allow too many or too few arguments to be passed to a function.

Let's try CLISP:

  [1]> (defun test () (cons 1 2 3))
  TEST
  [2]> (compile 'test)
  WARNING: in TEST : CONS was called with 3 arguments, but it requires 2
           arguments.

Or:

  [3]> (defun test (x))
  TEST
  [4]> (compile 'test)
  WARNING: in TEST : variable X is not used.
           Misspelled or missing IGNORE declaration

Unbound vars:

  [5]> (defun test (x) (+ x y))
  TEST
  [6]> (compile 'test)
  WARNING: in TEST : Y is neither declared nor bound,
           it will be treated as if it were declared SPECIAL.

> nobody cares about those training wheels.

Error checking is for lesser programmers: very effective advocacy!

> The problem is solved in a different way

Exhaustive testing? The problem is that there isn't even a reliable dynamic check. A misuse of the data stack in one place can affect code elsewhere. Just because you step on the bug doesn't mean that the machine will halt with a diagnostic, let alone one that pinpoints the cause.