You seem to be presuming here that wanting FORTH to be popular even crossed the minds of the 1201 FORTH developers in question. :')

At least this author wrote the following:

> So, the question is, how to encourage today's world of C programmers to take a look at Forth. How do we convince them that Forth can be 10 times more productive?

So they are clearly interested in getting people to view FORTH as a productive choice.

I’ll amend my first comment to say 1200, then.

> but if you actually want the language to become popular why not look at things every other popular language has?

Because that is completely missing the point of what Forth is.

It's meant to be a simple high-level language that stays quite close to the underlying machine and can be implemented in a few dozen lines of assembler to solve a specific problem you have.

It doesn't need to be some massive bloated ball of mud and straw like ultra-high level languages such as C, where every aspect of the underlying machine is abstracted away in library after library.

The whole context of this article is "how can we get C programmers to understand that they would be more productive in FORTH". My thesis is that maybe the attitude of "you should be writing everything from scratch, including (often) the FORTH environment itself" might just possibly have something to do with why people aren't jumping on the FORTH productivity bandwagon.

The number of C programmers whose use case is "I need to bring up this CPU with a never-before-seen instruction set" is a rounding error. The number who need to fit their complex logic into 1K of memory is small and dwindling every year. I can buy an ESP32 for less than a dollar.

Moreover, there's no technical reason why FORTH programmers can't write, share, and use libraries (except maybe the aforesaid plethora of incompatible language implementations). FORTH is great for creating neat little DSLs that solve a specific problem. Stacking these can be powerful, but if you personally don't want to use them, or it doesn't fit your use case, that's fine.

> "how can we get C programmers to understand that they would be more productive in FORTH"

It could also be that they wouldn’t be more productive (given the kinds of software the typical C programmer writes).

It could also be that that is the wrong question.

The reason C beats Forth is code-sharing. Forth is a better language and system on its own, but it's difficult to standardize for reasons both technical and cultural. So if you write some really wonderful code in Forth to, say, decompress a bytestream, another Forth programmer is unlikely to be able to use that code without substantial modification. So Forth becomes either a single-person or a small-team system at best. Larger teams can't grow (in part because onboarding to your particular Forth system is a non-standard process), and especially cross-pollination between teams and companies is not possible.

> The whole context of this article is "how can we get C programmers to understand that they would be more productive in FORTH".

They absolutely would not be more productive in Forth. If they're writing in an ultra-high-level language like C, they're unlikely to be targetting something where Forth would make sense.

You need ridiculously powerful processors to run a C compiler, and your code is likely targeting some massive processor with possibly hundreds of kilobytes of code space.

Forth and C inhabit entirely different conceptual spaces.

> Moreover, there's no technical reason why FORTH programmers can't write, share, and use libraries

None of the libraries you write will be of any use to me, and vice-versa.

> ultra-high-level language like C

LOL, thanks for the reminder that most of my career has been spent up in the stratosphere, towers upon towers of abstractions. Started re-learning C during pandemia for embedded systems and microcontrollers, feeling freer as I go deeper down the stack. Got into Lisp interpreter, then compiler and assembler. Had a chance to study eForth in this post, and it can get real close to the metal.

> need ridiculously powerful processors to run a C compiler

That's one thing I noticed while getting familiar with C, that it's a huge effort to write a compiler in itself. Whereas Lisp and Forth even more, creating a variant/subset of the language from scratch is an exercise for every student. These languages are hidden gems, even though they play such important roles in the history of computer science. They are relevant, perhaps now more than ever when people are losing touch with the ground, the basics of code and computation.

> You need ridiculously powerful processors to run a C compiler

It's not 1982 anymore. I can compile C just fine on SoC that costs $5. Of course it's true that these things are ridiculously powerful, but that doesn't really matter. The amount of silicon used is roughly the same as an 8051 from 20 years ago.

I'm all about cool projects like building your own CPU out of 7400 logic gates or writing your own OS in assembler or whatever. But I personally feel that FORTH doesn't need to be limited to these kinds of toy projects where you're intentionally making things harder on yourself. However when I see discussions related to FORTH it seems like most projects fit into this category and there is little diversity.

Forth is pretty lowlevel, i don't think it can compete with the highlevel languages. Postfix notation and stack juggling is just boring.

C is pretty low level… and yet.

Disagree, there is no types in Forth, only cells. User is acting as a compiler. Comparing to C, imagine that every keyword like for/while/break is implemented as a macros using setjmp/longjmp. And this is a strong part of the language, flexibility but without any guarantees.

That's what I would call the "Forth challenge", that is to grow out of stack juggling.

When you look at the Forth code of a beginner, yes it's full of stack juggling, of "@" and of "!". When you look at code from more experienced Forth programmers, there's much less of it.

The challenge is to build your way out. There's no fixed way to do this, because the best path to do so is generally dependent on the task at hand.

Needless to say, most programmers fail this challenge.

You are definitely not making it sound attractive for real projects where the outcome matters.

Sounds like a fun game maybe.

This challenge comes with rewards. Forth has superpowers that can't be found elsewhere.

But its definitely not for everyone. I'd say that the status quo of Forth being an obscur niche is fine, just fine. If you need convincing, if you aren't spontaneously curious about Forth, then it's likely not for you.

I'm in favor of everyone having fun however they want, and you have piqued my interest a bit that it might be fun.

But if even the proponents of the language say that ("needless to say"!) most programmers will be incapable of the challenge of writing good code in it... definitely doesn't sound like anything I'd want in anything I wanted to be maintainable or long-lasting. If this is the outcome you desire, then your, uh, anti-evangelism is working!

I've never written Forth as part of a team. I suppose it's difficult with an average team. But then I try to imagine what a small team of good Forth programmers could do and I'm thinking it would be a quite powerful team.

If I piqued your interest, might I interest you in the introductory series I wrote: https://tumbleforth.hardcoded.net/

Factoring is good way to reduce the complexity but writing math is painfull experience. To be fair, the infix version of Forth exists as an extension library.

The power of FORTH is that creating a variation tailored to your specific problem is almost effortless.

In most languages, building a compiler or interpreter is a major project. With FORTH, if you’re the only user, you can have something working in minutes.

I’ve lost count of how many times I’ve thrown together a simple stack-based interpreter. Whenever I need to encode non-trivial behavior in an app, I know I can spin up a quick FORTH and get it done.

Let's imagine for the sake of argument that I don't need to write a compiler or interpreter. What else is FORTH well suited for?

It's often used in bootloader/firmware type stuff (or was) because it can be a bit higher level than assembly and not subject to the same types of vulnerabilities and crashes... but written in a few KB and even easily hand written in assembly. And often run pretty fast, depending on the architecture.