>>5183 I read programming in forth ages ago when that antiquated nonsense wasn't that antiquated yet but I never got too deep into it. Because of this discussion, as practice I spent the last few days implementing a driver for a SPI RTC for my Z180 board in Forth. I can finally use a clock. It wasn't that difficult that it took days, I got mostly stuck because I didn't pay close enough attention to the boards' schematic and didn't realize a particular input was active low. (and wondered why the RTC chip wouldn't talk to me) Then I had to put in a few delay loops because the Z180 was talking too fast.
Anyways, it's a perfect example for a thing that you can write well in forth. Z80/180 have a weird I/O Port output thing and talking to the RTC via SPI basically means the toggling of two bits at a specified address. As there are only really two states you want (0 and 1) you can put all that "hardcoded" into two words, on and off. Then out of these words you can easily put together other words defining the commands the RTC understands, basically a series of bit toggles. Then out of these words you can put words together that read and print the hours and minutes, and so on, you see where I'm going here. I was searching for examples of other people's work because of my aforementioned earlier problems and what was striking to me was that my forth program is much shorter than the examples in C and such I found, there was a lot of (necessary) repetition in these.
What was always fascinating for me regarding forth was how usually the words at the very bottom who are sometimes the "hardest" to come up with conceptually, but once put together, are usually completely error free because they're so simple and you basically never have to look at them again and can do everything else on a higher level. I always felt it's really hard to screw up in forth or end up with hard to understand bugs because of that. Functional languages like Lisp etc. advertise with this too but I never really found them that practical to be honest. (and I tried)
I saw a very ancient AMD FPU from the late 70s and I was thinking it would be really easy in forth to just replace the math signs with other words that'd do I/O to send off the math directly to that chip, completely transparent to the programmer. (If this was actually faster in reality than doing all the math locally, eh, my guess is actually not, forth on the Z*-series of CPUs is not that fast and there's a reason FPUs aren't dedicated chips anymore, the latency costs such I/O stuff causes are immense)
What's even more interesting though is that you could easily define IO that'd give you the ability to send new forth words off to a forth interpreter on another CPU that wouldn't need to know them but could interpret them on the fly for custom functionality. I can't really think of another language where that would be that easy and could be implemented in a very transparent fashion, at least in theory.
Forth OS would definitively be a single user system and do away with a lot of the modern layers of absraction. You could build new words on the fly for whatever functionality you need and if you went with the forth style, your highest level words would amount to functionality that when stringed together would in the end result amount to pipes. Including my aforementioned example, you could even have words that instruct other interconnected forth-machines/cores/vms to do things for you and send the results back to you. A lot of forth implementations (even like, really old ones for the C64) also have schemes for multitasking which are interesting. I kinda have still a problem wrapping my mind around how to do big forth problems though, I might have to read thinking in forth.