FORTH LOVE IF HONK THEN !
The ForthLanguage is not widely used in the software industry, but does occupy a niche. Like the users of other niche languages, Forth users use it because they really like it, not because it's the hot new thing or because it is what everyone else is using.
And, like users of other niche languages, they think they are right and everyone else is wrong, and anyone who doesn't recognize that is an idiot.
There are some striking differences between what members of the Forth community like about Forth. Unlike some other niche languages, Forth is a very general-purpose language, and can support any kind of programming activity, so Forth users have a variety of opinions about what the "true nature" of Forth is.
Some of the factions of the Forth community are described here. This is not exhaustive, nor are the groups mutually exclusive:
It's hard to figure out exactly where the center of the Forth community is, but the comp.lang.forth newsgroup is a good place to start.
news:comp.lang.forth -- and the ForthLanguage in general -- attracts a lot of hobbyist minimalists, people who treat the language as a standalone thing of beauty, yet don't actually solve real problems with it. A decade of reading comp.lang.forth has supported this. An unusually large number of newcomers to the language immediately jump into writing their own Forth systems, or least jump into the planning stages of doing so. This is something I've never seen with another language. Who reads a book about C and then decides to write their own C compiler before actually writing a real program in C?
At the same time, the people who use Forth professionally stay out of these discussions. The dichotomy is striking. Yes, Forth is used in mission critical applications, but there's almost no discussion of such. This makes it difficult to understand how Forth is actually used.
The reason that folks prefer to write their own Forth is to further educate themselves on how this ThingOfBeauty? works -- it is the reason artists have strived hard for photo-realism, musicians have strived hard for the perfect composition, for why architects strive for the perfect balance of space and non-space. Everyone, even those who only "use" the language, goes through this phase. Everyone.
Those who have written their own Forth systems will often, having acquired what they sought, revert to using a more professionally engineered implementation of the language, and will be productive coders. Those who don't, well, don't.
That being said, a core philosophy of Forth is YAGNI: the more minimal the Forth, the more the Forth system won't meet your needs. Remember, Forth is as much a runtime library as it is a MetaLanguage, so the primitives offered by RetroForth will unquestionably differ from those offered by GForth, which differs yet again from those of ColorForth. Therefore, you might well find out that re-writing may well be cheaper than hacking what already exists.
The Forth community believes in re-usable software in the form of concepts. Take, for example, that phrase, "re-invent the wheel." We constantly complain about people re-inventing the wheel. Yet, the wheel is re-invented all the time! Proof: a wheel designed for a Hummer H2 is not likely going to make a good fit for a children's wagon, while a typical wagon wheel will offer very poor performance as a load bearing (which is just a special kind of wheel, when you think about it!). Each kind of wheel is unique, with no shared manufacturing technology; yet, we clearly identify all of them as (kinds of) wheels.
So it is with Forth; we accept that there are re-usable concepts: B-trees, linked lists, menuing systems, etc. But their implementations are usually home- (or at least custom-)grown to address just those needs the programmer has to satisfy. The ForthDictionary?'s database is almost never used for other tasks because it's not at all optimized for the other tasks. And, writing a new one is typically only a handful of Forth definitions anyway, which compiles to, maybe, hundreds of bytes at best. The overhead of "re-inventing the wheel" is very often substantially less than the overhead incurred with, say, supporting dynamic linking. Supposing DL is supported, what then? The library you link to will undoubtedly be so large (particularly as libraries tend to accrete functionality over time) that its size and resource consumption will dwarf the home-brew solution.
Hopefully this provides a rationale behind at least some of the things most non-Forth-coders find so bizarre about us.
--SamuelFalvo?
See RapidFile for what some consider the best database application written for Dos.