121–130 of 172 posts
Meanwhile, you can't compile rustc on a 32-bit system because it runs out of address space...
this might be a dumb question but can someone briefly explain why Forth is more suitable over C or other languages in general on post-apocalyptic OS?
- It's tiny and dead simple to implement - It sits very close to assembly - It allows high-level programming like in C - The concept of pushing/popping things onto/off the stack is a relatively straightforward programming model when done consistently One of the old competitors to the likes of UEFI and uBoot is OpenFirmware (also known as OpenBoot), for which the primary UI is a Forth shell; OpenFirmware was the BIOS…
The big problem with Forth is software reliability: ad-hoc Forth code is hard to reason about in any generality. Languages like Factor show that dialects of Forth can be much better in this regard.
Earlier quoted context omitted.
Technology isn't a complete panacea, but humans in general are highly adaptable. History seems to indicate that innovation is the most common outcome of Malthusian catastrophes, so it seems more than reasonable to me to ask that anyone arguing for a Malthusian catastrophe needs to also argue why innovation is not going to again be the outcome.
But looking back at our history, one should also keep in mind that it did take hundreds of years for Europe to recover from the fall of the Roman Empire. 'Innovation will fix things eventually' is cold comfort for the generations of people living in the interim.
edit: I mean, look at what is happening now. All sorts of disruptions because of some sneezery (regardless of real or imagined danger, it's the policy that matters). Now imagine further disruptions by volcanic ash particles and gases in the atmosphere. So F-ed!
Earlier quoted context omitted.
Seems like an IR would make sense here. Perhaps a stack-based one. If you need a compact program representation, that doesn't mean you have to use FORTH as your source language.
it doesn't mean you have to, but forth is awesome.
If I had to put my finger on why Forth is hard for most programmers, it's like this: the structured program theorem suggests using sequence, selection, and iteration to control program logic. Assembly code on hardware architectures will assign all meaning sequence-relative, late-binding the selection and iteration. Forth doubles down on this sequence-first approach through a more versatile assignment mode(the stack)…
For me, the main problem with forth is a lack of names -- most languages (functional or imperative or even declarative) assign names to things -- things like function parameters, temporary values and so on. Even Prolog, which is as far from traditional structural program as one can go, usually has descriptive names for unbound variables. Compared to this, Forth is very name-terse. You get "function names" at best, an…
Earlier quoted context omitted.
Why should they think that? The gutenberg press was used in the real world. There are lots of OS being used in the real world for real work. So why should someone in 500 years think this is more relevant, than for example Linux? And if there is a real collapse, then I also do not really believe everyone makes a run for collapseOS. There are other options: all the ones, tinkerers and hackers use already today.
We don't know how history will pan out. Just wanted to share the weird feeling I sometimes have about current events. For all we know, post-collapse technology could be based off QMX reverse-engineered from luxury vehicles. It's just fun to think about how events can have that unexpected butterfly effect. I sometimes catch myself with the implicit belief that we are "late" in the story of history. But given the possi…
If I had to put my finger on why Forth is hard for most programmers, it's like this: the structured program theorem suggests using sequence, selection, and iteration to control program logic. Assembly code on hardware architectures will assign all meaning sequence-relative, late-binding the selection and iteration. Forth doubles down on this sequence-first approach through a more versatile assignment mode(the stack)…
For me, the main problem with forth is a lack of names -- most languages (functional or imperative or even declarative) assign names to things -- things like function parameters, temporary values and so on. Even Prolog, which is as far from traditional structural program as one can go, usually has descriptive names for unbound variables. Compared to this, Forth is very name-terse. You get "function names" at best, an…
I want to learn forth now. Where can I find a modern usable forth that works well on windows to make real programs? Does such a thing even exist?
You can do just fine with the free versions of SwiftForth and VFX Forth as long as you don't mind that they are 32bit only. If you end up liking it and want 64bit, you can buy iForth for 100 EUR. It's what I use. These are all amazing optimizing compilers. If you care about OSS: Don't waste your time with GForth. If you want something simple that you can hack yourself, take a look at pforth.
If this gets you interested in z80 hardware, I would recommend building an RC2014: https://rc2014.co.uk/ I built an RC2014 after CollapseOS was posted last year, and thoroughly enjoyed it. I ended up adding a front panel, complete with switches and lights, to allow toggling in and executing code without a ROM, and also wrote a HTTP/1.0 server for CP/M (which was an enormous headache for lots of different reasons). Ne…
I love this project, and check in on it every few months. I particularly like the idea of scavenging hardware: > With a copy of this project, a capable and creative person should be able to manage to build and install Collapse OS without external resources (i.e. internet) on a machine of her design, built from scavenged parts with low-tech tools. I'd be interested in trying to build my own proof-of-concept, but my ha…