I will never forgive these people their endless hyperbole and abuse of words like "facist" until they lost all meaning, until actually honest-to-god "I think dictatorships are cool and we need extrajudicial treatment for 'undesirables' " actual facists found a voice in civil discourse. These people opened the gate for those people. Good job. The chinese and russians couldn't have orchestrated it better.
Meanwhile the leader of the far right party in my country is a lesbian who lives with her girlfriend in Switzerland, and who worked for some jewish (you can probably google it; I have nothing against jews, some of my best friends are jews - I point it out because many of her voters have a problem with them) financial institute. Must be all these traditional, conservative values I hear so much of. They fly to their degenerate parties in their private jets, and drink champagne together with their "culture war arch enemies" that costs more than what these jokels that fight and die for them in the trenches of Twitter earn a year. They're probably laughing at them together. Parasites. All of them.
I don't know whether this says more about how fearless you are about powerleveling or about how many forth nerds actually do this.
My friend, that doesn't dox me. It's like saying that, as a C programmer, I've been known to use printf at some point. It's the natural progression, you see a forth implementation, you think you can do it better with the right accomodating hardware. It's completely logical to arrive there. I'm pretty sure many people have built forth-specific FPGAs. You don't need much for Forth. By itself, it's barely a language. You can implement a forth VM on discrete logic at acceptable speed, no dedicated CPU silicone required. A programmable calculator running forth built from discrete logic parts should be something every computer scientist (and adjacent) should be able to build, in my opinion. And yes, I am painfully aware that many young people in that field nowadays probably cannot do it.
I'm personally happy that forth has had a bit of a revival with modern MCUs for a new generation. That's pretty cool, especially considering that the modern MCUs are a lot faster than the computers I used professionally to design forth related systems a long time ago. If you wanted to build a somewhat more open hard- and software stack, you'd start somewhere here, IMO.
...and that's also why I don't really believe that the vast majority of people want things in OSS to be better. I believe that many people have a vague idea that things are not optimal, but they also do not want to make the hard cut that would be necessary to execute true changes and throw off the shakles of the corpo. They want to watch their youtubes and x their twitters and they don't really care. Not really. It's all performative. For some more than for others. My opinion. Might not be the best one but there it is.
Re: Forth/Lisp, and that might sound cryptic but this is getting to long, just like with lisp it helps to get rid of the notion that data and code are two different things. They are not. code can be treated like data, and data can be executed like code. Once you internalize that, the flexibility and mutability of the system stop seeming magical - they become self-evident.
This is why Forth, just like lisp, is more of a "language kit" than a language. You don’t use Forth, you create a DSL, I think the kids call it nowadays. Your domain becomes its own language, because extending Forth is no different than writing in it.
If you think a little bit farther, and this took me an embarassing long time to figure out, the Lisp parallel is obvious: Lisp represents programs as lists, the same structure it uses for data. That’s why macros in Lisp are so powerful. You’re just writing functions that transform lists, which happen to be the very programs that will later execute. Forth is doing something similar with words and stacks: the running system doesn’t make a big deal about whether a piece of memory is "instructions" or "data." If you point EXECUTE at it, it’s code. If you manipulate it with arithmetic or store it in memory, it’s data.
This blending of roles gives both languages a kind of malleability that feels alien if you’re used to languages where code is carved in stone. You can mold the machine to fit your mental model, rather than forcing your thoughts into someone else’s rigid grammar - and here we close the circle to what I said at the beginning that your own forth implementation is the most natural evolution.
Now to what you said: in Forth, addresses are not some hidden, abstracted detail: they’re right there. You can stick them in tables, do arithmetic on them, compare them, and of course execute them. That power is exactly what makes the system so malleable, but it’s also what makes the idea of a neat, relocatable "finished product" so slippery.
That's why we forth programmers don't speak of "compiling down" to a portable artifact but think in terms of "bringing up" the system on the target. You rebuild the dictionary there, with the layout that makes sense for that environment, instead of trying to serialize and ship over the exact state of a running system. That’s also why cross-compilers and metacompilers (used to be) such an important part of serious Forth work: you generate the target image in a controlled way, instead of trying to pickle a live one. If you want to lock it down into a relocatable binary, you have to impose discipline on yourself: either avoid address sensitive tricks, or use a toolchain that knows how to patch them. This mallability I spoke of goes both ways, it gives you tons of freedom at development time but as you have noticed also means you need to be deliberate if you want to turn a living forth system into a fixed artifact.
Thanks for reading my blog.
