[pointfree]

https://www.youtube.com/watch?v=NK0NwqF8F0k

"Chuck Moore, the inventor of Forth and ColorForth programming languages, gives a presentation on writing "1x software," or how to avoid common sources of bloat in software. Topics covered include: what it means to be Forth (as distinct from other languages), how ColorForth is simpler still than Forth, how common system services such as files, windows, and even local variables, complexify (complect) the software, the impact of bloat, maintenance on that bloat, etc. And, as is usual for Chuck, deeply philosophical thoughts as well."

[otoburb]

Chuck Moore also founded GreenArrays Inc.[1], building on his work at IntellaSys (the previous chip company he founded) and the resultant lawsuits.

[1] http://www.greenarraychips.com/

[white-flame]

Basically, you can build a cathedral per project. It will be elegant, all parts will be purely sufficient and focused on getting the pieces of that particular project working.

But when the project changes in certain ways, that bespoke foundation no longer suffices. Time to take the wrecking ball to it and start building a new cathedral.

It is technically true that you can reduce the sheer amount of code involved with a running program, but I for one would not wish to. I would rather inherit the problem-solving, optimization insights, and compatibility tackling of others inherent in OS modules and libraries (along with their "bloat" and complexity), than carry all the weight of non-project-specific development from bare metal. This is a statement of scope and time as well of that of surface of opportunity for bugs and weaknesses.

[to3m]

I think the point is more that you don't build a cathedral at all.

Another article, more interesting in my view than this one, about the apparent mindset: http://yosefk.com/blog/my-history-with-forth-stack-machines....

[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.