Forth Portability

Forth has several advantages that make it more portable than some of the alternatives.

Forth makes it very easy to abstract away the differences between architectures. You can define a word on two platforms that behaves the same way on either platform, even though the definitions of the word on the different platforms may be quite different. Define a small vocabulary of such words, and you have the foundation for all the portable code you want.
It used to be that whenever a new processor came out, Forth was one of the first languages to be implemented on it. Forth is small, and simple to implement, and can itself be used to hide the differences between machines.
Forth, being close to the machine like C, is subject to some of the same portability concerns as C, such as the "size of an int" problem. If it has to communicate with system libraries then it also becomes dependent on those libraries, just like C.
Forth doesn't lie to you about your machine's architecture as much as some other languages; instead of making your platform look the same as every other platform (while doing a lot of work behind the scenes to create that illusion), it lets you see what you are really dealing with, so you can make intelligent trade-off decisions and wring the maximum performance out of your hardware.

Of course, Forth is usually used in environments where the only viable alternative is AssemblyLanguage -- environments where there isn't room for a C runtime library, where there certainly isn't room for the complete Java class library, and where there isn't time for BASIC interpretation. Forth is a good deal more portable than assembly language in such places.

It should be noted that freestanding C implementations are possible (and compliant with the C standard); such implementations need not have a copy of the C runtime library (or can only include those functions that are needed for the application). C can be made quite small if you need to. The place where C implementations run into some difficulty is on architectures with bizarre memory models or very small register sizes - C on an Intel 8051, for example, is a major pain.

Various standardization efforts (1977, 1979, 1983, AnsForth in 1994 and possibly amended in 2005) have resulted in mostly compatible definitions.

Discussion

If you follow ChuckMoore philosophy you don't port but you rewrite for the real target at hand. ForthReusability is probably an oxymoron, except within a single project where the factorize, then factorize and re-factorize again mantra leads to highly hierarchical code which some point out as a GoodThing.

To be fair, Forth is probably the sole computer language which has more homegrown freestanding complete implementations (including the compiler) than actually useful applications. As a corollary, the Forth meme seems to live well, and spreads quite well into intellectual, esoteric versed enquiring minds, looking for the Tao of Mankind.

Forth standards are bloated. Forth is not bloated. Forth users smack their heads in frustration. Forth users buck standards. Forth standards aren't used.

You start saying: Forth has several advantages that make it more portable than some of the alternatives. and at the end, the only thing you finally claim is Forth is a good deal more portable than assembly language in such places. If assembly is the only kind of language less portable than Forth, then Forth is not what I call a portable language.

Even the arguments you use are flawed. The first one is true for any language (just replace word with procedure or function). The second just says that the language is simple to implement, which is about the language implementation, and has nothing to do with portability of programs written in Forth (which requires that all these implementations are compatible between them). Finally, the last two are clearly saying that it is not portable. Calling portability 'lying about the machine's architecture' doesn't change anything. You can argue that portability is not always a good thing to look for when one needs performance above all, and I would agree with you, but it doesn't change the point of this page.'

From what I've seen, this page has no point. Portability is a myth. Look at most any non-trivial C program and count the #ifdefs in it. Anybody who believes they're writing "portable" C code is living in a dream. When 16-bit machines were all the rage, everyone thought C was portable until 32-bit machines hit the market. I won't even begin to go into what it was like on the PC platform, even between vendors of "standard C." Anyway, each C #ifdef that you find is equivalent to one word that would be factored out in a Forth program; one word which can very easily be changed to suit the new target environment/hardware.

Portability simply doesn't exist. It's best to accept that. When you do, you'll suddenly start to find yourself writing more portable software. Funny how that works.

Instead of saying portability simply doesn't exist it is more accurate to say that portability doesn't simply exist. In other words, one can (and many do) write Forth code which runs unmodified on several different kinds of machines. A program I wrote a while ago on the Palm using QuartusForth, worked perfectly on my desktop machine running Linux and on a Windows based laptop running yet another variant of Forth. It's not impossible or even particularly difficult, but it does require a little bit of thought. Then again, so does every other worthwhile creative activity...

Forth portability isn't about interchangeable parts. It's about being able to move an application from one platform to another (PlatformPortability). I moved an entire Forth environment from one platform to another (preserving the applications) by addressing only the lowest level of code.

Like saying that fiberglass isn't a generally useful construction material because you can't buy pre-measured pieces and bolt or nail them together. Shocking. Can't even been welded. Disgraceful. I mean, hell, when have you ever seen a fiberglass yard? Ha ha ha. Clearly, fiberglass is dead. Who ever heard of a fiberglass tycoon? Like, hey, go to HomeDepot? and try to buy a fiberglass-working tool set.

Yup. But I can make you just about anything you want from fiberglass. No, silly, you wouldn't make a balsa wood screwdriver either. You can shape things in fiberglass that exactly fit the application. No, I didn't say "perfect" and I'm not going to follow you there. This is an analogy.

Forth can model things in ways that give other languages a headache. What do I use at work? C, mostly. Some assembly language. Some SQL. A little xBase now and then, when the boss isn't looking. Forth is something I do as time allows. It keeps my mind from calcifying.

Portability isn't free. You don't get it from the language alone. Portability is deliberate. It's by design. It's something you do, not something you have. If you "know" it's never gonna run on any other platform, you can kiss off portability and go for performance. If you hope to move it, you'd better build that into what you write.

Forth makes that possible in a way that few other languages can.

Contributors: GarryHamilton ... and whoever started this page ... and those other guys ...

WritingPortableApplications, ForthLanguage, ForthReadability, ForthIsDead, ForthReusability, ForthPessimism