FORTH LOVE IF HONK THEN !
	 :	-- "256byteram", on a comment on Digg.com, as seen at http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html

----
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:

	AnsForth supporters:	people who think that the 1994 ANS Forth standard brought an end to pointless incompatibilities and provides a stable standard for moving forward with increased cooperation between users
	AnsForth detractors:	people who think the ANS Forth standard has frozen Forth as it was twenty years ago, thus stifling innovation, and has made Forth too complicated by requiring that it provide compatibility between too-wide a variety of hardware platforms and implementation techniques
	Object-oriented Forth users:	people who are working with ForthObjects
	Hardware hackers:	people who value Forth for its low-level hardware control
	High-level programmers:	people who value Forth's capability as a high-level programming language, with unbounded support for abstractions and compiler extensions
	Machine-level programmers:	people who use or design processors that implement Forth primitives directly in silicon
	Old-timers:	people who have been around Forth for decades
	Newbies:	people who are getting into Forth for the new wave of HandHeld computers and wireless devices
	ChuckMoore and friends:	the inventor of the ForthLanguage, now working with ColorForth (which many of the old-timers and ANS Forth supporters don't like)
	Forth implementers:	people who have written their own Forth (which is pretty easy to do, relative to other languages, so there are a lot of these people)
	Purists:	those for whom Forth satisfies all their needs
	Pragmatists:	those who seek to integrate Forth with other programming languages, operating systems, and environments
	AI programmers:	those who think that referential transparency is a given, and who see Forth as the minimum needed substrate that has introspecting capabilities. 

And of course, there are also the Microsoft-haters, flamewar mongers, arrogant know-it-alls, and other negative personalities that infect other software development communities.

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. 
----
CategoryForth