> Q. Could you define “better” in this context?
> A. Easier to read and maintain, fewer bugs, smaller, faster development.
That's fairly subjective. I find the whole "keep track of the stack in your head" thing quite irritating, to be honest. Forth is more dynamic than C, certainly, but beyond that, I find C much easier to utilize in that you mostly concentrate on what you're doing rather than dup dup swap drop roll bee bop a lop bam boom tutti frutti etc... C's big "extraneous" overhead is keeping track of memory allocation.
You can use variables in Forth. It's just scorned as non-Forth-ish. And you also have to keep track of memory allocation in Forth. (Though it's possible to write a garbage collector.)
That's their rationalization, at least. I think that for the average programmer, having to keep track of the stack is just added mental overhead that gets in the way of making their program do something useful.
Lisp was for big iron in 1975. Machines with over a megabyte of RAM and several hundred KIPS. There are several Lisps and Schemes targeting the embedded world these days.
Even Java is used in the embedded world today (luckily not my world).
Simply, C and Forth can scale down to really small MCU with few hundreds bytes of code space and some bytes of RAM (with Forth, on such small target you will probably loose REPL).
A readily available OSS Forth I really like can be used on small MSP430 where no lisp or scheme can go! (www.camelforth.com)
Regardless the merits of the language itself, the culture of Forth has some serious issues that cause me to doubt that a skilled Forth programmer truly has a development speed that is a multiple of that of a skilled C programmer. Cf. this advice from Thinking Forth:
"Some Forth practitioners advocate storing source code in variable-length, named text files, deliberately emulating the approach used in traditional compilers and text editors. This approach may become more and more common, but its usefulness is still controversial.
Sure it's nice not to have to worry about running out of room in a screen, but the hassle of writing in a restricted area is compensated for by retaining control of discrete chunks of code. In developing an application, you spend a lot more time loading and reloading screens than rearranging their contents.
"Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition."
IIRC the 2004 is simply a retyping of the 1984 edition, so all the content is nearly thirty years old (Thinking Forth Project http://thinking-forth.sourceforge.net/).
So this kind of information is a bit dated.
If you look at current forth implementations (gforth, Forth inc and MPE comes to mind) none of them is screen based; you can decide if is good or bad ;-)
There are some developers that prefer the block-oriented approach of creating Forth code. Remember that Forth is a dynamic language, so there is a tradition of viewing the system as an image (similar to Smalltalk), instead of a bunch of static files saved on a file system. They achieve this by creating small blocks of code that are dynamically loaded as necessary.
This doesn't mean you can't create Forth programs from standard text files. All modern Forths work this way, providing blocks only as an additional feature.
My main beef was with the last bit - ""Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition." This reeks of Stackholm Syndrome, where having toiled under the limitations of a system for some time and developed workarounds and jerry-rigs* to get by them, one begins to view them as strengths for no other reason than their familiarity.
If nobody thinks like this any more though, congrats on escaping what is normally a sure route to smug weenie-ism.
*Eg. later in the same section, Brodie suggests defining constants associated with block numbers as a sort of ersatz filenames
That's fairly subjective. I find the whole "keep track of the stack in your head" thing quite irritating, to be honest. Forth is more dynamic than C, certainly, but beyond that, I find C much easier to utilize in that you mostly concentrate on what you're doing rather than dup dup swap drop roll bee bop a lop bam boom tutti frutti etc... C's big "extraneous" overhead is keeping track of memory allocation.