Forth was my first programming language for work from 1999-2004 at FedEx, developing the software used by the courier scanning device the Enhanced SuperTracker (EST) -- which was used in production between 1987 and 2007... 20 years! I still look back fondly on it for battle-hardening me on recursion and the function stack. I still marvel at the ability of the language to "fold in" on itself when compiled, resulting in a miniscule binary footprint. Also, since you define your own "words" (or functions), it supports a DSL approach to coding... no syntax to learn, you write your own!

One of my favorite descriptions of Forth:

"There is no syntax, no redundancy, no typing. There are no errors that can be detected. Forth uses postfix, there are no parentheses. No indentation. Comments are deferred to the documentation. No hooks, no compatibility. Words are never hyphenated. There's no heirarchy. No files. No operating system."

http://www.colorforth.com/1percent.html

EDIT: I survived and currently work at a YC company and do not have a neck-beard.

FORTH is a glorious little language. You can get a bunch done in a very small amount of code. You can get a running FORTH system working, from scratch, very very quickly (on bare metal, maybe a couple of days).

That said, I've seen very few projects successfully in FORTH. There are a few, but not many.

Additionally, historically the language has been a lightning rod for kooks and bad engineering practices. All of the experience I have of FORTH in the video game industry was watching people serially fail (they would typically get twisted up in their FORTH environment, get obsesssed with the FORTHness of this and that, and forgot to ship a title; more mature users would run into intractable organizational and performance problems that forced them to ditch the language).

But it's still a great language, and a worthwhile thing for software practitioners to know and play with.

How about a puzzle game about Forth, written in Forth, running on a Forth machine? https://github.com/JohnEarnest/Mako/tree/master/games/Warrio...

Obligatory Javascript implementation of said Forth VM: http://johnearnest.github.io/Mako.js/?rom=Warrior

BYTE issue "The Forth language" contains an article by Chuck Moore "The evolution of Forth, an Unusual Language":

https://archive.org/stream/byte-magazine-1980-08/1980_08_BYT...

previous discussion from 766 days ago ago:

https://news.ycombinator.com/item?id=6103793

Today, what is the typical software one would build with Forth? What are the libraries like?

I write Forth code for tiny microcontrollers that are embedded in ASICs. They are ROM-based, and have to work first time. Size is a few hundred bytes, so C is out of question.

firmware, boot loader, 1980's text editors.

As for libraries: Usually that boils to "No."

To quote: "The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine. I say that you should write your own subroutines." (http://www.forth.com/resources/evolution/evolve_1.html)

I've heard good things about Factor - another stack-based language, which is more high-level than Forth, but I've never used it.

I wrote the OS for my Raspberry Pi in Forth (which necessarily meant writing the interpreter).

I think that's an important thing: anybody who's seriously doing Forth work has written his or her own interpreter to do it with. Which may be as it should be.

Any chance that you've put the code out there somewhere? I'd love to see it.

Interestingly, Bitcoin and similar systems use a Forth-like stack language as script.

For instance, a typical transaction goes like this:

[scriptSig] [scriptPubKey]

Where scriptSig is: __signature__ __public_key__

and scriptPubkey is: OP_DUP OP_HASH160 __some_hash__ OP_EQUALVERIFY OP_CHECKSIG

In rough terms:

OP_DUP works like classic Forth DUP, duplicates the immediate stack element. OP_HASH160 replaces the stack element with its hash160. OP_EQUALVERIFY performs a "fail if not equal" and OP_CHECKSIG takes two elements from the stack and verifies they're a pubkey and its signature.

So basically that's how the system verifies that a transaction is signed by the owner of the input address to go to the owner of the output address.

The bootloader for Sparc systems @ Sun is still OpenBoot, written in Forth: https://en.wikipedia.org/wiki/Open_Firmware

I worked on it a bit, though it doesn't change much beyond bug fixes these days.

Peripheral vendors still routinely provide FCode drivers in the server space.

I wouldn't say this was it's "typical" usage, but the only time I personally have written Forth was when editing FreeBSD bootloader:

https://www.freebsd.org/cgi/man.cgi?query=loader%288%29

Embedded systems. Forth makes for a pretty sweet environment for interactive driver development.

You can write pretty much anything you want. The problem is that the standard Forth has very few libraries, and most libraries around depend on a particular implementation. To see what is possible, check Win32Forth for example.

You could write videogames: https://github.com/JohnEarnest/Mako

which programming language had a hooded unibomber-type guy in glasses on the home page? I thought it was forth but can't find that page anymore.

I used Forth from 1983 to 1987, on the Atari 400. It was an awesome language.

I used it for about the same period on the Commodore 64. On a 64K 1Mhz machine, it compiled faster than any tool I use today does on a 3Ghz machine. The resulting code was compact enough to make 64K seem like a lot of memory and drastically faster than using the built-in BASIC.