Relatedly, there's http://tumbleforth.hardcoded.net/, which I think looks lovely. Has anyone gone through that and would like to share their experience?
https://chipwits.com/2023/04/08/forth-programming-language-g...
I am young and stupid, but from a rear-view perspective it looks like maybe certain abstractions were chosen in the old days when there were hardware limitations, and that our current "evolutionary branch" of programming languages has a lot of abstractions that have not aged well, leading to a lot of layers of load-bearing cruft --much like any engineering project.
Collapse OS might not be practical today, but it has a "liberating" appeal. Freeing yourself from all these layers of abstraction sounds really enticing. A way to enjoy computing as it existed in the 1960s, but without the terrible developer experience. (or so I imagine)
Currently my pie-in-the-sky project would be to work through these projects, get Dusk OS building on a virtual machine, then physical machine, then write a Scheme interpreter for Dusk OS in C --and go hog-wild from there.
I have a couple of rivers to cross before I get there. I implemented a Scheme interpreter in Python in a couple of hours, then improved the scanner/Tokenizer in a couple more hours. Now I'm reading through crafting interpreters to see how I would go about implementing a Scheme interpreter in C. After that's done and I implement an interpreter in C, I'll revisit this guide and try to jump headfirst into DuskOS.
In my experience quite often writing in assembler is easier than FORTH unless you have a strategy and self discipline, which when acquired makes one a whole lot more productive than using assembler, and arguably more so than a high level language. There're no pointer arithmetics, no rudimentary type checking, not even an array type (you have cells and addresses). There is nothing that throws an error except things like stack over/under-flow checks, and if you are lucky your code will crash. If not debugging can be tricky. Stack imbalances won't be reported/checked for you, there is no bounds checking for anything (not even structs). But there are conventions/strategies to prevent these kinds of bugs from happening that one needs to either discover for themselves, or find out in books (the book Thinking Forth helps, but is not enough I would say).
Working with the stack can be more difficult than with registers, although the latter can be easily simulated with variables, which is often frowned upon. But words like CREATE ... DOES> enables meta-programming that helps with generating code with code, and makes it quite powerful, but can make your code complicated to reason about (see the concepts of compilation vs. execution vs. interpretation semantics described in ANS Forth).
In the end the appeal of FORTH for me is in its "simplicity" (but nowhere any ease of use as it requires mastery of laying out code in memory as you would do in an assembler without any help from the language itself), its overall philosophy (see Chuck Moore's A Problem Oriented Language) on focusing on the nature of the problem rather than thinking in terms of the tools/language given to you (build a "language" for the problem), and providing solutions with as minimal "cruft" as possible.
The method that it uses to interpret/compile a word varies by implementation. Subroutine call is just one of them.
I'd been making a list recently of games (old and new) that have puzzles and programming type stuff in them. It's going on the list! I could very well get on to it next after I'm finished the ketman assembly "game" (although it's not really a game, I suppose).
I hope the new ChipWits does excellently!
Yet every time I hear experienced Forth developers recommending to use more variables, and that newbies tend to eschew them, making the code much harder to read and understand than it is necessary.
You become a true Forth programmer once you go past the code golf and stack juggle phase.
Virgil's work inspired me to give Forth a bit of a go, and last year I spent some time hand decompiling SmithForth[1]. It really is remarkable how little assembler is required to bootstrap the language. I can totally see how Forth could give you a repl in embedded environments, which sounds way more fun than the typical dev cycle I hear about.
and you should post your list here.
It's rather neat.
Depends on how naive the assembler programmer is, and, I would think rarely, if ever, on modern hardware because the many subroutine calls kill branch prediction benefits. Also, on lots of old 8-bit hardware, defaulting to 16-bit integers will kill performance relative to native assembly in cases where 8-bit integers suffice.
(Of course, you can fairly easily replace hot loops by assembly or (more difficult) change the forth compiler to compile parts to native code, fuse words, etc)
I already like his style of talking.
Examples:
>Much terser than the C version right?
>This little assembler crash course gives us a better understanding of what is compiled by the C compiler, but not how it compiles it. We don't know how it's ran either. To know that, we'd have to dig through software that weighs millions of lines of code. Maybe you'd have the patience to do it, I don't, so let's continue tumbling down the rabbit hole. We'll go bare metal and then build an operating system of our own, with a C compiler of our own. It's simpler this way.
>What’s a linker? Aw, forget about it, it’s another piece of overcomplicated software that has convinced the world that it’s essential. We won’t need one in what’s coming.
:)
My personal inclination is to make the longer jump, and go straight for a deeply rudimentary Lisp. There's a trick where you start off with Lisp macros that expand to assembly, and I once knew someone who got it working for new hardware during a 10-hour plane flight. It's a slightly longer climb than Forth, but even a primitive Lisp is nice.
However, the deciding factor here really is the 6502 and 65C02 microprocessers. You really want at least 4 general-purpose registers for a primitive Lisp dialect, and that's pushing it. And the 65C02 basically has 1, or 3 if you clap your hands and believe. Even C is a serious challenge on a 65C02.
But Forth thrives in that enviroment. You only need a stack pointer and enough registers to do exactly 1 canned operation. So: victory to Forth.
And wow, I wish I had seen Chipwits back in the day. I was a massive fan of the Rocky's Boots logic game, but Chipwits never showed up in our neck of the woods. Thank you for open sourcing it!