The Zen of Forth

We have megahertz and gigabytes and "embedded" systems with MMUs and filesystems at our disposal, so I'm guessing the time when forth was a solution has long since past.

Most corporate software development uses languages like Java, C#, Ruby, and Python that are all very similar to one another. Sure, some of them use different punctuation, but the basic tools you use to solve problems all involve putting pretty much the same words in pretty much the same order. It's easy for someone with one language to quickly pick up another.

Forth's syntax immediately pushes it into the "weird languages" category because almost all of the words are in a different order. "1 + 1" is now "1 1 +". That sets it far enough apart from Python/Ruby/Java/etc that a tech company isn't going to use it unless they feel really strongly about it. (AFAIK there isn't any big corporate push for Forth like there is for Go and Rust and stuff.)

The main audience for Forth is therefore hobbyists. I think the main reason why you see lots of handmade Forth implementations is because Forth is really easy to implement. It's a fun hobby project. And because Forth is simple, its community biases towards people who like writing simple software. If you want to write complex software in a weird language, you'll probably gravitate towards a complex language like Haskell or something.

And not all research is done by university researchers. And not all of HN is solely industry practitioners. You just can't make huge assumptions about tech based on what you see on HN, basically. :)

With that said, PostScript is a stack language, x86 can be treated pretty similarly to a stack language, FreeBSD's bootloader used to be in Forth (may not be anymore, I don't know). And I hear it's used in constrained/embedded environments. So I don't mean to suggest it's not a practical language either.

Out of the box, out of the standard, there no real structured data type ala records, there's no strings, there's no modular coding construct. All of those can be added, but that's the trick. They have to be added. You also start getting into implementation specific stuff that, potentially, makes that kind of infrastructure not portable across implementations.

Not that portability is a huge concern, but it's a factor if you want to import someone else's implementation.

All of that can be overcome, but that they have to be overcome is part of the problem. Original scheme suffered from this as well, but look how far it's come over time. To the point that all "usable" schemes aren't really the 50 page R5RS versions anymore.

It also doesn't help that Forth niched its way into controllers and smaller systems. Forth had all of the availability advantages early on, perhaps even more so, than C, Pascal, etc. But, organically, Forth never caught on.

It's fair to say that Lisp suffered "not enough computer" issues early on to hinder adoption, but that's long past. But Lisp still suffers adoption, when pretty much every complaint about it is long buried -- save its syntax.

And I just think folks, again, organically, "wisdom of the crowds" don't like S-Exprs for code. They just don't like it. It's off-putting enough that folks look elsewhere.

Forth, in the end, suffers similarly. All of these demos and mini DSL examples look great. But they're contrived. Take a look at any Forth code you can find and see if you can make sense of it. Especially "modern" code, where we "know better" and aren't constrained by file size, or line size, or "screens" or "blocks".

Take a look at that Zen's github.

And try to make sense of it.

This is all barrier to entry, and most aren't willing to climb over it.

The big difference for me was that I couldn't even read my own Forth code after I had been away from it for a year; I had to first re-teach my brain to think like a stack machine. That was never a problem with Lisp. I can look at 10-year-old code I wrote in Lisp and re-understand it quickly (especially with the tools built in to Emacs that are quite helpful for Lisp code exploration).

"Zen" is a good way of describing Forth. Charles Moore often says things that seem like zen riddles in themselves, like Operating Systems are obsolete, you don't need local variables, you don't need structures, and a whole host of other things. It's very difficult to know what he's talking about without context, or why he thinks what he says.

I've toyed around with his colorforth, and given up. I doubt I'm the only one. It has cool stuff like you being able to change the fonts on the fly. It has a keyboard consisting of 25 keys (because 25 keys should be enough for anyone, apparently), which don't map onto a Qwerty keyboard (maybe Dvorak?) and has different modes based on colour. So I'm like "how the living fuck am I supposed to use this thing"? It's like trying to figure out the controls of some alien spacecraft.

It clearly works perfectly for Charles. He's clearly on some whole different level than the rest of us.

Forth is really fun to play with; before going back to using something that is a bit more practical. It has macro-like facilities. I find them very difficult to reason about. Forth seems like Lisp in terms of power, but at the opposite end of the spectrum in terms of size. Lisp is a complete language. Forth gives you a boxful of atoms that you assemble yourself.

I wrote a barebones Forth. Little plug: https://gitlab.com/mcturra2000/cerbo/-/tree/master/forth/v3 I haven't touched it for a year or two, though.

It incorporates the notion of a token type. The idea is that you could write a recursive-descent compiler using it, although I hadn't pursued the idea much.

To give you an idea of the malleability of Forth: I got bored with creating variables one-by-one, so I defined a word called "vars:". Now I can create several variables at once, e.g.: vars: foo bar baz

Here's an implementation (that works in my forth): : VARS: begin parse-word dup while $create 0 , repeat drop ;

I simplified the implementation and made the idea more composable: : VARS: line( $create 0 , )line ;

Done right, Forth looks like haikus. I'm not at that level, though.

Perhaps they are culturally associated?

Imagine a Forth bootstrap moving quickly on to C ABI and dynamic linking, to libpython and python ast vocabulary, and to numpy etc. Or a "parse all the languages" GLR/mixfix-expr/regex-token sandwich parser and some LLVM vocabulary. But ... that's not "doing Forth". Culturally.

Lisps could read `a[i] = 3` as sugar for `(setf (aref a i) 3)`, but don't. And for overlapping reasons, an organization for weeks struggles to even build its big CommonLisp thing (reader symbol conflict hell).

When a community doesn't much go somewhere, the path is unlikely to be smooth. And so a non-technical cultural challenge becomes something more.

Minimal syntax has value and power. Non-minimal syntax has value. So if there's one, but not the other, that seems notable, and perhaps a symptom of other issues around tooling up for complexity?

I think it all boils down to specificity vs generality. Moore is specific. He solves one problem, not many. If he has a different problem, then he uses a different solution. By being tightly focussed on his one specific problem, there's many things he doesn't need. Like, he doesn't need a file system. He just stores data and code in blocks in the disk. You end up with a system that is small, tight, minimalist, does what it needs, and then stops.

That approach doesn't work if you want to make something more general-purpose, like a Linux kernel. It's not like Linus Torvalds is a nincompoop that somehow didn't realise that 90% of the code was unnecessary. Linux is popular because it solves a broad range of problems to a broad range of people.

Forth systems are unpopular because they solve the problem of one man. Not only that, that one man must have a mental model of how his whole system works. The upside is that the system is much simpler than a general-purpose one.

One could say that Forth is not just a language, but a whole philosophy as to how and what programs should be constructed.

   > "what software do you build in Forth?" they say "Forths"

Those that ask of purpose of FORTH, is same as those that ask purpose of above mentioned things.

Like others I indeed started with making my own Forth dialect (actually more than one try; and yes one of them could compile itself), but now it is my go-to scripting language. My latest script for instance was about converting some flat files format into an SQlite database. I also use it to prototype and test things, and I have a program that run and works for me 24/7. Can't really say more because it is partly work-related.

> Specifically, managing a dynamically changing list was basically a nightmare

So don't do it. Or do as everyone else does: use some C library/do it in C. You don't have to do everything in pure Forth, there's no law about that and being able (or not) to do anything in pure X doesn't prove anything.

Or just allocate 1Mb for your todolist file (or limit the number of entries) and accept that if you need more, you'll have to edit one constant in your program. I don't see anything wrong with that. Some of my scripts have hard-coded parameters and I can imagine a user would be reluctant to edit something in alien incantations, but I can also imagine using the flexibility of Forth to create a more familiar "syntax" and make it so that those parameters are in a separate script, so that it looks more-or-less like a configuration file to the profane.

You have no idea how we actually are narrow-minded, not creative and driven by habits about how things should be done. Forth won't get you a job, but at least it can open your mind and this reportedly is a portable (to other languages) quality.

Also, avoid "what if" - especially with practice programs you don't plan to actually use. "what if" is the FUD device by excellence.

> When I asked a group of Forth programmers why it is so difficult they just said "Forth is not suited for that problem"

The whole point of Forth is that it is, in essence, a recipe for a language you can make yourself. If your Forth is not suited to the problem, then adapt it. Forth is not a dogma.

So, is the book ‘Wizard’s Bane’ actually focused on using Forth (or some ersatz programming language concept) to do magic? If so, that basically describes a huge part of an hypothetical RPG I’ve been designing on paper since college. Also, would you recommend the book to a fan of genre fiction?