I had to lookup "opinionated" to make sure I understand this statement correctly...
Forth is on the contrary very opinionated. When you want to implement something in Forth, you have to take into account it's very limited ability to support complexity. Which forces you to think about the problem until you can code a simple enough solution for Forth.
It's a severe limitation, but it's one of the rare cases where a limitation is actually a feature. Forth forces its opinion about simplicity on you and that's a good thing in my opinion, because people tend to underestimate the exponential nature of complexity growth: adding a parameter to a procedure at least doubles the amount of unit tests you have to perform on it; add three parameters and that's a 8x the tests.
But it also makes Forth far less fit for task where handling nightmarish complexities is the main topic. If you can't cut the Gordian knot, you lose.
In the sense that there are no types (or only one, depending on how you look at it), that its inventor eschews standardization, that there are literally no keywords and that the basic premise of the language is that it, the interpreter, the application and the compiler are the same thing, it's not at all opinionated.
You make an interesting point, but what you describe is about the only sense in which I'd respect calling Forth opinionated. In every other sense, walking into a new Forth application is potentially like walking into a new language.
As a good example of how unopinionated it is, here are the jonesforth implementations of the IF and THEN words:
: IF IMMEDIATE ' 0BRANCH , HERE @ 0 , ;
: THEN IMMEDIATE DUP HERE @ SWAP - SWAP ! ;
Don't need those words? Don't implement them and make your own branching abstraction. Feel like you spend too much time juggling the stack? Implement named parameters and local variables. Need records or structs? Do it. Need an object system? Go for it.
> walking into a new Forth application is potentially like walking into a new language
This is how walking into an application in any language (but yes especially Forth and Lisp(s)) is supposed to be but most are doing it wrong by repeating a lot of boilerplate.
If you have a boilerplate in your Forth, you are doing it wrong, it seems.
> Forth is not the language. Forth the language captures nothing, it's a moving target. Chuck Moore constantly tweaks the language and largely dismisses the ANS standard as rooted in the past and bloated. Forth is the approach to engineering aiming to produce as small, simple and optimal system as possible, by shaving off as many requirements of every imaginable kind as you can.
> That's why its metaprogramming is so amazingly compact. It's similar to Lisp's metaprogramming in much the same way bacterial genetic code is similar to that of humans – both reproduce. Humans also do many other things that bacteria can't (…No compatibility. No files. No operating system). And have a ton of useless junk in their DNA, their bodies and their habitat.
> Bacteria have no junk in their DNA. Junk slows down the copying of the DNA which creates a reproduction bottleneck so junk mutations can't compete. If it can be eliminated, it should. Bacteria are small, simple, optimal systems, with as many requirements shaved off as possible.
VLSI design is pretty complex, yet Chuck Moore figured it out in mere 500 lines of Forth and successfully manufactured chips designed with his own tools: https://colorforth.github.io/vlsi.html
> But it also makes Forth far less fit for task where handling nightmarish complexities is the main topic. If you can't cut the Gordian knot, you lose.
Maybe in a monolithic program. But I could see successfully tackling some very complex problems with a swarm of Forth programs that are individually very clean and simple.
That sort of approach is presumably one of the basic ideas behind Green Arrays.
Forth is on the contrary very opinionated. When you want to implement something in Forth, you have to take into account it's very limited ability to support complexity. Which forces you to think about the problem until you can code a simple enough solution for Forth.
It's a severe limitation, but it's one of the rare cases where a limitation is actually a feature. Forth forces its opinion about simplicity on you and that's a good thing in my opinion, because people tend to underestimate the exponential nature of complexity growth: adding a parameter to a procedure at least doubles the amount of unit tests you have to perform on it; add three parameters and that's a 8x the tests.
But it also makes Forth far less fit for task where handling nightmarish complexities is the main topic. If you can't cut the Gordian knot, you lose.