An Attempt at a Compelling Articulation of Forth's Practical Strengths and Eternal Usefulness
36 points by LenFalken
36 points by LenFalken
I've tried to learn about Forth, and every time I do, I feel like the people who write about Forth have become pod people who have lost the ability to communicate with regular humans. But the other Forth fans seem excited about Forth posts, so I just ignore the Forth stuff and go about my business.
This article claims to be about explaining Forth's usefulness to people who have never heard of Forth, so I wanted to share my perspective as a non-Forth person: this article is an ineffective approach to selling Forth to regular people.
When I start read an article about a technology I don't know, I have two questions:
If the article hasn't answered both of these questions by paragraph two, I give up and assume the article either isn't for me or the author doesn't know how to communicate to me effectively.
I stuck with this article for 12 paragraphs and it still never answered either question. It looks like it starts to answer the question of "why forth" somewhere around paragraph 20, but I still don't understand what it's talking about:
Forth is a pancake stacking machine with superpowers... In Forth you can make your own super special fork and knife, maybe they shoot lasers, but you can also make robots that help you.
I'm a developer, and that makes absolutely no sense to me. What's the problem Forth solves? Why is Forth more interesting than other languages that solve the same problem?
I will try for an elevator pitch version :) Thanks for the feedback. Your take is a bit off the scale if I'm being honest: I had a bunch of non-Forthers peer review this to make sure I was on the rails. Regardless there will be a class of people with similar taste in text, so I'll try for a different take!
Very awkward to read on mobile and my browser’s Reader Mode couldn’t fix it either. Edit: Instapaper at least sorted out line wrapping.
Yes. I tested on mobile and there was no reasonable way to layout 80 column text unless you're in landscape mode. In landscape, it looks very good. Sorry! But the textual graphs and layout would completely break otherwise.
FYI:
I don't like Forth as a language, but the bootstrapping argument is quite interesting.
It isn't fair to say that the Zig project doesn't care about the heaviness of LLVM as a dependency. They are getting close to eliminating it from the Zig core (replaced by a compiler completely written in Zig), and the reason is that they care about bootstrapping, specifically the time required to build the Zig compiler from scratch, including its dependencies.
Forth development was started in 1968, and Forth was first shared with other programmers in 1970. If you look at other programming languages from the same time period, you can find other minimalist languages that are about as small and easy to bootstrap as Forth. I'm saying Forth isn't unique in this aspect. Unix Second Edition was the first Unix release to have a C compiler, which was written in a little over 3000 lines of C, so 1/3 the size of chibicc, and written in far less time than the 2+ person years that chibicc is said to have required. 2nd Edition Unix had 16KB of address space for user processes (code + data), so a larger C compiler likely would not have fit into memory. This C compiler was not created as a toy, it was used to implement the C compiler itself, as well as many of the commands (but not the kernel yet, that's still assembly language). For source code, follow the link in here: https://wiki.tuhs.org/doku.php?id=systems:2nd_edition
I never said either language cared about their heavy dependencies. When I wrote the section around LLVM, I knew well about Zig's long discussions and efforts around wanting to remove it (https://github.com/ziglang/zig/issues/16270).
I've updated the piece to mention Zig's attempt at escaping LLVM as a good faith gesture :) It is not really a point that there are efforts but more their origins, but I suppose it's an interesting aspect.
There is evidence from Charles' book that Forth started even earlier than that. Other minimal languages (probably BASIC is the biggest one) do not share the same power.
If the C compiler in UNIX 2nd Ed. is not based off B source code then that's great and is a data point I should bring up, but from my understanding, it puts it into the multi-year development bin.
Edit: I extracted the tar archive at the link provided. That's a C compiler in 3000 lines of ... C, like you said. So all work that came before is not accounted for.
I'm not sure how else to convey that a C compiler takes a non-trivial amount of energy after showing examples, and a Forth doesn't. I guess the comment is more about the "Forth is not unique in this aspect" of low-cost. You're right, but it's unique in that it's low-cost and powerful!
Back in college, I became obsessed with Forth (bought hard copies of Starting Forth (first and second editions) and Thinking Forth) and implemented my own Forth-like language. In C. Why? Because at that time, I was programming computers based off x86, 68000, MIPS and SPARC, and I just didn't feel like writing four separate implementations of the same language in assembly (and I like assembly!). As for the C compilers, I paid for the x86 (Mix C for MS-DOS) and 68000 (SAS C for the Amiga); the MIPS came with the SGI I was working on for my job [1], and the SPARC came with the Sun machines the CS department used. Even had I used assembly, I don't know what MASM was written in, but the 68000 assembler I used at the time was itself written in C (because I could run the same program on MS-DOS, Amiga, IRIX (the MIPS system) and SunOS (the SPARC system). And I'm sure that the assemblers on IRIX and SunOS were also written in C. I even used my Forth-like language for both work and a class project, but as I found out, while I like the idea of Forth, I actually hate programming in it.
Despite not liking Forth, I was still weirdly drawn to it, and for years I kept trying to understand how one forth word, DOES>, actually worked. Last year I decided to do a deep dive on it, and I ended up writing an ANS Forth system for the 6809, I used an assembler I wrote in C. It is much more capable than any assembler I ever used on the 6809 system I used to use [2].
I would not have been able to assemble the code on a 6809 itself as the source is 267,528 bytes long (it's one source file of 11,505 lines of code). It wouldn't even fit on a floppy for the only 6809 system I have (161,280 bytes per disk). It would have been a long and painful process if I had to do it on the target system itself. It took the better part of a month, maybe a bit longer, to implement it and get it to pass both my tests, and the ANS Forth test suite. I do hope you aren't the the type to say I missed the memo on the Forth Way by implementing to a standard [3], but I do have to wonder why you think implementing in C is "missing the point" of Forth. The C compilers, have, in effect, been paid for.
[1] I programmed and ran the computer systems for a neuroscientist and was paid out of the Math Department of the university I attended for undergrad studies in Computer Science. I didn't fully understand why a neuroscientist was working out of the Math Department, but I also didn't question it. It was my favorite job I've ever had.
[2] I can even test the code during assembly. There's only one other assembler I've heard of that has that capability, and when I heard about it, I stole the idea. The 6809 emulator itself is written in C.
[3] Which did happen to me, by the way, by adherents to the Church of Moore.
C compiler ... 3000 lines of C
But in way less Forth, besides threaded interpreter you get a full development environment with tooling and library stuff...
Just a slight nitpick. GHC's testsuite runs and coordinates tests written in Haskell via python. GHC itself has no dependencies on python
Forth is definitely a cool idea, especially for bootstrapping from nothing, but most of us are somewhat tied to existing operating systems and would like our code to be portable. This is exactly why C is so hard to get rid of.