> all the parentheses are unnecessary too

That's not quite true. In Forth it is impossible to tell syntactically where the function calls are.

> it is the closest thing to Lisp machines experience you can get today.

I think Clozure Common Lisp running on a Mac (i.e. with the IDE) is pretty close as well.

But I don't begrudge anyone their Smalltalk. It's just not a good impedance match to my brain.

> It's just not a good impedance match to my brain.

I think that's the answer to every language war ever. "To my brain." If you claim "X is easier to understand", you get a war. But if you claim "for my brain, X is easier to understand", that's a lot harder to have a war about. All someone can reply is "well, my brain is different", which... OK, your brain is different. Fine. (Or someone could claim that nobody could actually have a brain such that X is easy to understand, at which point it's pretty clear who the unreasonable zealot is.)

In fact, I think this is also the answer to the editor wars. It may even be the answer to the political wars.

Well, not quite. Some languages are by design good impedance matches to brains that don't know very much. BASIC is the canonical example. It's really easy to learn, which makes it attractive to beginners, but it has some pretty serious limitations that you only become aware of after discharging a certain amount of ignorance. IMHO this makes BASIC objectively worse than other languages.

To me, Lisp makes every other language I know feel like BASIC in the sense that the distinguishing features of the language feel to me like they are designed to appeal to ignorance rather than to empower.

> IMHO this makes BASIC objectively worse than other languages.

"IMHO" and "objectively" are in fairly stark opposition.

Not really. All quality metrics are subjective. But if you accept a particular quality metric, then you can objectively assess things against it. For example, C is objectively better than Brainfuck if your goal is to write software easily. If your goal is something else, like challenging yourself to overcome adversity, then Brainfuck might be objectively better than C.

> But if you accept a particular quality metric, then you can objectively assess things against it.

I agree, but the scope of your assessments will be very limited, and also you end up writing tautologies (if your objective quality metric is A, then you've redefined "better" to mean exactly A). In particular, the scope of your assessments will be far more limited than the example you give (words such as "easy," "simple," etc. are unlikely to enter the statement without some rigorous definition, but therefore also highly restrictive, underlying it).

> For example, C is objectively better than Brainfuck if your goal is to write software easily.

I would not take a bet, that if you presented Brainfuck and C to all > 7 billion living humans, there would not be at least one person who found it easier to write software in Brainfuck than in C. Certainly I could imagine a hypothetical human for which it would not be true.

> In Forth it is impossible to tell syntactically where the function calls are.

To be fair, this is true of Common Lisp as well, macros aren't functions.

Forth doesn't really have functions, it has words, they're broadly useful like functions but are a differently-literal sort of memory object from a lisp function defined with cons cells.

So you can't know where the function calls are, there is no such animal, but you do know where the word boundaries are, it's the whitespace, and in Forth that's what you care about.

> macros aren't functions

That's true, and it is arguable that Lisp could be improved by making macro invocations have a distinguished syntax.

But in practice it's usually pretty clear what is a macro and what is a function because of naming conventions, and because macros commonly admit syntax that would be illegal in a function call e.g. (let ((x 1)) ...) But however bad this problem is in Lisp, it's much worse in Forth.

> Forth doesn't really have functions

That is debatable. If I write 1 2 + 3 * then I think of the + and the * as function invocations that take their arguments off the stack and leave their results on the stack. It's true that this is not exactly the same as a function call in Lisp, but it's similar. In any case, if I write:

a b c d e f g h i j

there is absolutely no way to tell what that is going to do without knowing what every letter means. By way of contrast, if I write:

(a (b c d) (e f) (g h (i j)))

then it's a pretty good bet that a is a function that takes three arguments, b and g are functions that takes two arguments, e and i are functions that take one argument, and c d f h and j are variables.

What you don't get in FORTH is arity information from the syntax, because everything is simply treated as a function from stack to stack. Unfortunately it's not feasible to keep the cleanliness of the FORTH syntax while providing that info (one would need a 2D view for that, where multiple arguments to the same function can be seen in parallel) so a parens-based syntax is arguably the next best choice.

The other thing you can't do (straightforwardly at least) is push a word onto a stack or apply it against some kind of compound structure.

That's what I mean by Forth words not really being functions, they're subroutines for sure, and you can do some surprisingly powerful metaprogramming given that what you have is a glorified linked list, something a little more powerful than GOSUB, and two stacks, but functions?

When you compare it with a visually similar concatenative language like Factor or Joy, which inarguably have functions, Forth words look pretty different.

  a b c d e f g h i j

and

  (a (b c d) (e f) (g h (i j)))

are about as meaningless as each other to me with just letters, in Forth you build a sort of minimal vocabulary for the problem at hand and so you have a better idea of what words are doing. Proper documentation (or at least very good naming) is needed in lisp and forth IMHO.

Of course you actually have to know what the words mean. But it's harder in Forth than in Lisp or conventional C-like languages because Forth takes away all of the visual cues that help you figure out what is going on.

> That's true, and it is arguable that Lisp could be improved by making macro invocations have a distinguished syntax.

Agreed.

You must have run Clozure a while back, I went to the App Store and the version of CCL there hasn't run properly since Sierra, according to reviews. I myself can't run it on Mojave or Catalina.

Yes, the app store version hasn't been updated in a long time but if you build from source it will run on Catalina. Maybe later too, I haven't tried it.