[white-flame]

I would still point out that that article focuses on bringing everything into the small. Redefine problems so you're not tackling large monstrosities, but simplified versions. Make it so that it neatly fits in little bits of code that directly computes simple things.

That's all well and good, but some people are building web browsers, or distributed AI databases, or even large chip development suites that do things that certainly wouldn't fit in 500 lines of Forth. Forth is a great expression evaluator, and has actual compile-time metaprogramming features, which is nice. But it doesn't solve actual large problems for you. It asks you if you can solve a non-large problem, and if you can, you're happy with Forth.

It's sort of like retro programming. You can work in a small (architecturally conceptual) scope that handles a few things elegantly, and implement some cool project within those constraints and building blocks. But it's still building a little cathedral per project.

[astrobe_]

For "large" projects you do as every other language does: you link/FFI to the C library that does the heavy lifting for you. It's kind of unfair to say "forth can't do browsers" when all browsers are implemented in C/C++ at the core.

[white-flame]

You link to C when you need speed, and that's not even usually necessary anymore in languages like JavaScript or Lisp. Linking to C doesn't let your code somehow abstract higher, to deal with larger projects and larger architectural scopes.

[alexdowad]

It may allow you to take advantage of existing libraries, however.