Comment by dexwiz
11 hours ago
I believe the author writes code as an artistic outlet. They use the word beauty/beautiful 12 times, the word love 8 times, and little (in a cute diminutive way) 10 times. The expresses a relationship with coding that most people don't have. It would be like an author expressing love for a pencil. Some may agree, but many would say "its just a pencil, the words are what matter." In a similar way programmers may say "its just a language, the features are what matter." Even then, Forth is chosen in the end for completely stylistic reasons.
Even the nostalgia factor for choosing a Forth is contrived. There are plenty of portable, modern languages that will likely be runnable for decades. Lua is embeddable and will likely be put into new systems for decades, and can run on low power hardware. But Forth is ancient. Its like learning calligraphy. Either you are in a niche, or you just love doing it. But no one uses it for the daily correspondences, they have messaging apps now.
I do agree that everything being connected to the cloud definitely excludes people and places. And that place may be anytime in the future. But you can combat this with more modern solutions.
> There are plenty of portable, modern languages that will likely be runnable for decades
I'm actually not sure this is true. There are certainly a few quite venerable languages that will be around unchanged for decades (i.e. Java).
I wouldn't however take the bet, that, say, Go or Rust will be able to compile code written now, on whatever the current compiler version is in 2035. I certainly wouldn't take the bet that you will still be able to download the correct dependency versions from a package manager after 10 years...
Reading about the `left-pad` incident (almost 10 years ago itself!) gave me an incredibly strong aversion to dependencies in my own projects. I suppose that like the author, I care a lot about understanding the foundations and ensuring that whatever I build can stand on its own, as much as that may be. I think this philosophy has helped me learn a lot more than if I had just focused on “build as fast as possible”, but definitely limited the “amount” of projects I’ve completed.
I love writing in C because a) it’s simple and I can understand everything that’s going on and b) I feel confident that it’ll compile just fine years from now, because that’s how that particular ecosystem has worked and likely will continue to work.
Recently, I’ve been writing new projects in Rust, which has far better ergonomics but is far more complicated and causes me to cede control to the whims of the community and the compiler. I’m sure there are simple ways to ensure that I can use the same compiler for all new platforms that will support it, but just like everything in the modern day (for both better and worse), is implicitly and explicitly designed to always be updated.
Rust has become much more stable in the past few years, but you’re right to expect breaking changes in the next ten years. I love using the language, it’s been fun to learn and I (hope) it’s helped me write far more robust code, but I’m sure in the future there will be many times where I’ll miss C.
I think my general approach to Rust (and to C++ before that) in this type of scenario, is to treat it as a "better C", and take the absolute minimum of dependencies I can get away with
You can't even get Rust of Go to run easily on a slightly older machine (e.g. try it on a OS X Yosemite machine) because all the compatibility issues. That's not even getting to all the "online" dependencies. This are two of the worst language ecosystems in this regard (I don't know anything that would be worse actually.)
No such problems with complex C compiler packages.
Hopefully the gcc Rust project can mitigate some of the issues for Rust (since everyone wants to rust-ify long standing projects these days and hence breaking backwards compatibility of the respective packages just to be "hip & trendy")
But that's going to be true of any package manager. You're betting on Maven existing over the same timeframe as Go.
But a go-vendored repository is buildable indefinitely, and the compiler itself is easy to bootstrap.
> You're betting on Maven existing over the same timeframe as Go.
Maven is already of legal drinking age in the USA. I'm willing to take those odds ;)
Choosing Forth isn't simply an affectation, it has some desirable technical properties:
> Forth is, to my knowledge, the most compact language allowing high level constructs. It is so compact that Collapse OS' Forth implementation achieves self-hosting with about the same amount of resources than its assembler counterpart!
https://news.ycombinator.com/item?id=23450287