> But Forth is also like a high-wire act; if C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code. You can do horrible things like redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?) You can easily jump off into bad sections of memory and crash the system. You will develop a good mental model of what data is on the stack at any given time, or you will suffer. If you want a compiler to worry about code safety for you, go see Rust, Ada, or Java. You will not find it here. Forth is about simplicity and flexibility.
When it comes to working on a large project in a team, I suspect Forth doesn't scale.
Think of why Go works so well for Google: it's designed for code bases that are maintained by many people. And almost every design decision that was made for that goes against the spirit of Forth.
It's too flexible; you can change anything about the system so any Forth code ends up deeply personal, and specific to the current task. It's a language for individual artisans, which is another reason why it works well in the embedded space. But it's not hard to see how it all goes up in flames when you're in a large team.
> Think of why Go works so well for Google: it's designed for code bases that are maintained by many people.
There's another dimension of this that works for Google, though, and it's one that people particularly here should take note of.
As far as I can tell, Go is a language where the solution to a given expressive problem is usually "write more code." There's nothing subtle or clever to leverage into a multiplier, like there is with Forth or LISP. You don't write a DSL. You don't factor out largely common implementation details. You may well not create composable subcomponents for some intermediate level. Instead, you put in the time, turn the crank, and create whatever straightforward code solves your concrete problem at the level it's written, straightforward if verbose. It's similar to how MJD describes working in Java (http://blog.plover.com/prog/Java.html ), except you're missing some of Java's expressive power and you have some of Pascal's to make up for it.
There's a degree of simplicity to it.
An organization like Google is not lacking in any way resources to have developers produce more code. Or understand it, if any issues with expressivity to volume ratio ever makes a given codebase difficult to grok.
Does your organization have those resources?
Do you?
The answer to that question (along with who you're competing with) might tell you whether you should be using a Google language or a hacker language.
...And Forth's DSL's are worse than most, by virtue of having minimal syntax, and being bound by the stack. So it's not just the Lisp problem again: it's actually worse.
> When it comes to working on a large project in a team, I suspect Forth doesn't scale. [...] It's too flexible
If, in any language, flexibility is a problem for a larger team, fire the lead developer. The article does a good joint pointing out that using that flexibility is usually a sign of code smell.
People on reddit seems to hint at the fact that Forth people stay under the radar because it allow them to design and solve problems in better ways.
I wonder how true it is ..