I appreciate Charles Moore for being opinionated and for inventing and evolving Forth, but IMHO there's no way that any low-level stack oriented language will ever be popular. The reason: it's just far too difficult for the majority of programmers to grasp the concept of stacks or to factor their code in a way so it only needs a small stack. It's the single most difficult concept to deal with, and patently not superior to registers and other normal techniques, as I found when I wrote JONESFORTH.
I don't think reverse polish notation is all that difficult, the difficulty lies rather in that Forth is best done as an actual low-level stack oriented language, not as a general purpose "does mostly everything at least okayish" language such as C++, Java, or Python. Few programmers work at such a low-level. There's usually an operating system in the way of your program and the machine, or at least a complex kernel that does more than strictly necessary, and in general there are just quite a few layers of indirection to get at the "actual" hardware. Even a lot of assembly programmers don't work low enough unless they happen to be doing small "kernel"-less (or "kernels" they made themselves) embedded systems. Verilog/VHDL/MyHDL programmers are probably in the same camp as Forth programmers, as long as they aren't just working on top of some big IP core they don't understand (like Java programmers writing on top of the JVM on top of the OS). Forth wants to talk to actual hardware, mainstream programming is about getting as far away from hardware as possible and leveraging other people's code whenever possible instead of doing it yourself. (This isn't to say the mainstream view is always wrong, it's often good that programmers work far away from the hardware, but for those sorts of problems I don't think Forth is really a good fit.)
This Washing Machine example isn't hard to understand: ": WASHER ( -- ) WASH SPIN RINSE SPIN ;" http://www.forth.com/embedded/swiftx-embedded-systems-7.html provides the rest of the implementation, which is also not hard to understand, and is at least as easy to understand as a corresponding assembly (or C) version would be. But it requires knowledge of the washing machine, which requires reading data sheets and maybe even doing some manual voltage tests, and it requires knowing (or choosing) which pins (or memory addresses) on the program host connect with the washing machine. There's a minimal kernel involved. You have to know what accomplishment it is you even want to achieve (as the Forth program begins with designing the high-level behavior I quoted, then continues by implementing bottom-up from the compiler primitives to meet the design).
I think Forth will be at most as popular as HDL languages are popular. That is, not very. And in both cases the allure of using C (whether compiled to what the embedded system's processor understands or compiled to the primitives of an IP core implementing a whole processor) will be strong, for there are lots of C programmers and C is more-or-less useful in any domain.
What does that have to do with _anything_ said by either Chuck Moore or the person to whom you replied? I get that programmers (and I'm no exception) have a mental defect where they try to show how smart they are by compulsively interjecting at every opportunity. But for that to have a chance of scoring you geek points you need to have some claim to relevancy, however pedantic and tangential.
I'll spell it out for you: the JVM is the most widely deployed stack machine in use today. The fact that you don't normally program it directly using a stack-machine like interface does not diminish the fact that the concept of the stack machine is very successful. Yes, there are some warts and issues but on the whole it works quite well and it never ceases to amaze me how fast it can be made to work using JIT and other technologies that weren't even around when Chuck did most of his work. The stack machine has been one of the most enduring concepts in programming.
If you haven't programmed the JVM directly then I would invite you to do so, it's lots of fun and you can pull tricks that would be hard to replicate using java.
Now that clojure and other source level languages have been added to the mix there is even more life in the ecosystem.
In short - and to make the point again - stack machines don't need to be the source language to be effective, but if you really want then you can use them that way.
I'm not sure if factor is running reliably on the JVM yet (there were some attempts in that direction) but that would be a fantastic way to unlock the stack languages true potential, a forth like language on a virtual machine with enormous deployment. That could do for the forth family of languages what clojure is doing for the lisp family.
edit: I simply love being downvoted for a gracious reply to a bunch of insults.
Moore's talk touched on the advantages of stack machines, one of which is portability. Hey, guess what is a particularly important and portable stack machine.
But I get that programmers have a mental defect where they try to show how smart they are by compulsively insulting people at every opportunity. But for that to have a chance of scoring you geek points your comments need to be not completely useless.
I have the same love/hate relationship with Factor: I'd love to use it more, the implementation is great, but the shuffling is hard to write and harder to read.
Canonical Factor prefers the use of locals rather than stack shuffles to avoid stack shuffling mental overhead. Thus, one hopes that you're just left with the 'love' part of your Factor relationship.
