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

Well, your opinion about it has changed quite a bit... I still like it probably because I am less interested in "serious about Lisp" than in pragmatic solutions. The other day I shipped a small networking utility as two files: the standard newlisp.exe and a newlisp script. I used Newlisp instead of my equivalent written in Forth because the user may have needed to hack it a little bit. The instruction I had to give was "just copy that on your desktop and drag the script file to the exe file". Job: done. I count it as Lisp being useful in 2019.

Anyway, there's still dozens of scripting languages that won't move an eyebrow about bad arity.

>> nobody cares about those training wheels.

> Error checking is for lesser programmers: very effective advocacy!

Beginners are not lesser programmers, they are less skilled programmers. It's a temporary condition.

Also, I'm not advocating Forth. It hasn't caught in 40 years, so it is obviously not for everyone. I'm just clearing what I think is misunderstandings. Just like I would defend a show when I think some reviewer totally misunderstood it.

> Exhaustive testing?

Yes, this is one of the ways. Whether you use static, dynamic, or no type-checking that's something you do anyway when things get serious. Because none of them catch all bugs.

> The problem is that there isn't even a reliable dynamic check

Stack imbalances in practice catch half of the programming errors. It's a bit like in Haskell: if it compiles, it has good chances to be right. In Forth, it translates into: if the depth of the stack doesn't change in your main loop, the program is probably right.

> A misuse of the data stack in one place can affect code elsewhere.

Most often the program just segfaults right away, because you're manipulating pointers quite often. That's another 25% of errors caught.

> doesn't mean that the machine will halt with a diagnostic, let alone one that pinpoints the cause

Relying on stack dumps and debuggers is a terrible habit. Looking for the simplest way to solve a problem is far more effective globally.

I know this sounds insane. I was there decades ago. I built a Forth that couldn't possibly crash and was disappointed by the result. I built Forth debuggers and was also disappointed. I built support debugging primitives in VMs and I was disappointed. That's because I was trying to cure the symptoms instead of the illness. Then I started to throw away and rewrite when a piece of code was buggy. That helped a lot.

For one thing you get rid quickly of the "lets try this to see if it works" mentality, which is a recipe for bugs and half-baked code. "Do. Or do not. There is no try".

If debugging is the process of removing software bugs, then programming must be the process of putting them in.
-- Edsger Dijkstra

This guy was right. Studies have shown that the amount of bugs is proportional to the LOC count. The message is "Program less, think more", and this is also what Forth says:

You factor. You factor, you factor, you factor and you throw away everything that isn't being used, that isn't justified.
-- Chuck Moore, 1x Forth [1]

Basically that's "The simplest thing that can possibly work" [2] approach taken to the extreme. The thing is, being extreme is not easy. You can pick a low-hanging fruit or two by being audacious sometimes, but being extreme means climbing the tree to the top.

[1] http://www.ultratechnology.com/1xforth.htm
[2] http://www.agilenutshell.com/simplest_thing