Ignore the occasional statements in forum threads about how Forth is so powerful.
Forth is not powerful. It is ugly, stupid and mean.
Because of this, you simplify, simplify and simplify again, up to the project's specs if you can.
Ignore the occasional statements in forum threads about how Forth is so powerful.
Forth is not powerful. It is ugly, stupid and mean.
Because of this, you simplify, simplify and simplify again, up to the project's specs if you can.
That's a statement of someone who doesn't understand Forth. Of course, one can write ugly code easily. Any language with raw power (Asm, C, Forth, Ada) needs a disciplined developer to get beautiful and maintainable code. Forth code can be really beautiful if the vocabulary is well thought out.
I consider Forth the best choice for tiny iOT devices, Firmware, and other essential things which can be kept simple and stupid, following the KISS principle which works very well in many cases.
Our vastly proliferated software security problems come from complexity which developed by despising the KISS principle. Many developers didn't choose the simplest way, they chose the most convenient way. Now, we realize that keeping things simple and stupid is not that bad after all.
"ugly, stupid and mean" is actually intended to the beginners or to those who want to try it. That's what most systems are out-of-the box, especially for the minimal ones (bigger systems like gForth might be a bit better).
That's their starting point. R> and R> are hideous so at one point they'll want to replace them with "pop" and "push". Stack juggling looks bad so they'll have to learn to minimize them. And they'll have to get used to RPN. There's no GC and not even heap allocation (unless ANSI-Forth added it as an extension since the last time I checked?), so they'll have to deal with the lack of memory management that are in every other high-level language. There's neither static nor dynamic type checking so they won't get any warning if they dereference a character. Instead, it will crash again and again without any stack trace.
So they'll have to deal with all this ugliness, stupidity and hostility that they won't expect "enough" because Forth fans praise it often without a warning about the fact that it takes a really long time to fully tame such a rabid language.
Why did I stick with Forth for so long? I made it progressively more beautiful for me; I learned to fight complexity and factor, which indirectly prevents mistakes; I implemented warnings in my system for mistakes that are hard to find (e.g. a redefinition) and are easy to check for.
When I encountered Forth first (6502 figForth) I felt it quite convenient. At that time there were only two other options - Basic and Assembler. Maybe that most developers today are too pampared by all the available IDEs for other languages. It's the same attitude why so many people stick with Windows instead of learning OSX or Linux, despite all the flaws of the Windows ecosystem.
> lack of memory management that are in every other high-level language
As already mentioned, I consider Forth suitable for tiny systems, iOT, Firmware etc. I would never use Forth for big software. I would not use even C++ for that. In that area Ada, Rust or Nim works much better for me.