Lost at C? Forth May Be the Answer

It sounds to me like what's being described here is an array of pointers to arrays. Not only is that feasible in C, it is extremely simple and common. The second argument to main() is such an array, for example.

> In C, you’re more protected. But then, you also have to do things like type casting to circumvent a patronizing compiler constantly checking up on you.

I don't consider it "patronizing" when a compiler warns me that casting the first few bytes of a string literal into a memory address might not be what I want. I consider that "helpful".

> The biggest drawback of Forth is the Catch 22 that attends any nonconformist idea. Not many people know Forth, and people won’t usually learn something unless everyone else is already using it.

The author apparently does not think much of his audience. He's basically saying that if you don't learn Forth it's because you're a conformist.

> Industry experience has shown that a Forth programmer is up to ten times more productive than a C programmer.

Now this is just silly. If this were really "industry experience", nobody would still be using C for anything except legacy applications.

After writing it, I learned a lot more about the Forth community, and how they despise my (perhaps misguided but well-intentioned) attempts to teach people about the principles of writing a Forth interpreter. Search for "JONESFORTH" in the comp.lang.forth archives for some examples.

[1] http://git.annexia.org/?p=jonesforth.git;a=summary

But first, we need to agree on the problem space.

FORTH was originally used for non-critical real time control of telescope hardware. The computation requirements were quite modest, there was limited storage available, and the audience was pretty technical. The programs did not have much dynamic state.

Generally, FORTH has been a failure outside of this envelope. While there are very whizzy specialized implementations of FORTH that are very close to equally specialized hardware, and that are capable of exceptional performance and turning really neat tricks, the usual result of bringing FORTH to bear on problems that have a large amount of state or very hard real-time requirements are: Slipped schedules, eventual cancellation of projects, and the labeling of anything dealing with the language as unhealthy fanatacism.

In the hands of a moderately skilled programmer, FORTH is good at:

- near-real-time operations involving modest amounts of computation

- rapid prototyping of same

- stuff whose consumers are very technical and can Deal With support along the lines of "comment out that line, stick this code in and try it again"

In my experience FORTH has not demonstrated success at projects that involve more than three or four engineers, projects that have extensive or complex data structures, or that require high performance (i.e., when microseconds count). This counts out video games (I've seen a lot of these attempts fail), operating systems (ditto), and commercial applications like word processors (shudder).

But if you've got a telescope to control, or a mass spectrometer, or you're doing new hardware bringup, FORTH is great stuff, and I've seen it shine.

I have to say, however, I would love to see an interpreter for FORTH which does not actually maintain a secondary stack at runtime, but compiles the code down to something equivalent, e.g. uses the LLVM Jit.

Much of what is done with the second stack is simply reordering bits of data or duplicating bits of data. This could all be done at "compile time". Each stack location would only exist at compile time. At runtime the values would be stored in ordinary variables and references. There'd be no need to duplicate data or reorder it at runtime. Instead it would just pull the data from the correct variable or memory location.

Naturally this defeats all the principals of FORTH compilers, etc, blah, blah, blah. But it would still be a fun (and easy) thing to do.

http://www.yosefk.com/blog/my-history-with-forth-stack-machi...

It was memorable because it was fast as blazes, essentially compiling routines to a sequence of JSRs, and it featured built-in wireframe 3D graphics primitives. This was exciting at a time where naively clearing the screen with line() routines took several seconds.

When is this article from?

I built my own machine AND half-arsed Forth implementation for Z80 back in '92 from a couple of library books, a dismantled broken RM380Z and a PC with DOS 3 and TASM on it. It sort of worked but was a little unreliable (it was all on stripboard, most of the bus timing was guessed and the XTAL was way too fast). I think the entire Forth impl assembled down to about 4K.

That sort of thing is just impossible with today's equipment. It's depressing. To much abstraction these days. Ironically Forth was probably the first language that supported writing DSLs :)

I'll dig it out and document it one day.