At high levels (meaning you've built up some nice Forth words), I disagree. The main difference is that most Lisps and Schemes have a GC, so you're not in charge of allocating/freeing memory like you would in Forth. That doesn't stop Forth words from implicitly referring to a variable that actually contains memory allocation addresses and hiding the actual underlying details of the allocation.

I think Forth certainly starts you out at a level of abstraction only somewhat more rich than an assembler while a Lisp runtime certainly abstracts more away from you, but once a Forth has been built-up, they become similar. Gforth gets a lot of flack in the Forth community for not being minimal, but it's a good example of a feature-rich Forth with support for things like exceptions, filesystems, sockets, and more. The Forth community itself is split into broadly two camps. The minimalist camp, (where Chuck Moore likes to live) which believes in bringing up custom Forths for custom platforms, creates small Forths that try to limit abstraction. The more featureful ANS Forth community tries to focus on a more batteries-included experience and these have more in common with most Common Lisp and Scheme runtimes.

Yeah I can see that but, to make a comparison, just because you can build up high level functions in assembly doesn't make it a comparable language to Python/JavaScript.

I think Forth is unique in that you actually can be both high-level and low-level productive in a single "system", but I can also see the perspective that high-level Forth is more of just a concatenative language than a high level Forth as such. Regardless I think Forth's power is that it can be both a very low level language or a high level runtime.

> My point is that Forth's general goal is to be a higher-level assembly language for embedded systems.

This is strictly speaking not true, even though that is a domain where Forth excels. It isn't rare at all to see Forth as the bootstrap language for bringing up new machines or architectures for instance. And I've seen it used for image processing applications, embedded language inside other products and so on. It's definitely not going to be your language of choice for hacking out the next CRUD app, even though there is no technical reason why you couldn't do that.

Just like Lisp is all about transforming arguments, Forth is all about transforming what's on the stack, and to a certain degree the two are equivalent even though their outward form looks at first glance very different. Forth has an easier and cleaner way to add multitasking to the core language than Lisp does (in my opinion, I'm sure others will disagree).

A more modern implementation of the concepts behind Forth can be found in Factor:

https://en.wikipedia.org/wiki/Factor_(programming_language)

Note that Forth (and other stack languages) are an acquired taste, plenty of people don't like them and a good number of those will simply never get beyond the initial turn-off provided by RPN.

> It isn't rare at all to see Forth as the bootstrap language for bringing up new machines or architectures for instance.

Oh yeah I blanked on this. As an observer I've seen Forth used here even more so than in embedded systems.

Just to confuse things further, both CL and Forth give you control over parsing (reader macros in CL, direct access to input for immediate words in Forth). So you can make a more structured language out of Forth if you really want to, and you can get rid of parentheses in Lisp if they bother you, with enough effort.

(But, of course, it's less effort to just use a different language that has it out of the box.)

I would beg to differ that that is the “goal” of forth, but I do think that there is truth to the statement in terms of niches best served when used by most programmers.

Writing in forth is a process of creating a domain specific language to solve the problem at hand, so it tends to get quite claustrophobic as you close in on the goal.

Yeah I tried to clarify. I am not an authority on their literal goal. I was trying to describe the result when you look at the systems overall in terms of implementation and use; what they make easy.