3 ms·

What's up with the aversion to filesystems in forth languages?

by geon 3y ago

crc_ 3y ago
Filesystems introduce complexity that may not be needed, especially on smaller targets. I'm personally not averse to file systems. I've implemented (but not yet published) a couple for testing purposes. It's probable that one or more of these will eventually be included in Konilo. But that won't happen until I write a program that needs this and have an implementation that I'm happy with.
throwaway81523 3y ago
That was more of a thing in earlier days (before my time) when Forth typically ran on the bare hardware, replacing the OS. Later, blocks vs files became a big debate in the Forth world, but with Forth now usually hosted under a conventional OS, files have mostly won out except among some die hards. The ROM code for the Green Arrays processor though is still written using blocks. You can download it as a nicely formatted HTML file from greenarrays.com. Here's a Usenet post from 2003 that discusses blocks: The central thing Forth depends on is KISS. We've consistently rejected complicated solutions when simpler solutions work. The result is fewer co-adaptations, where you can't change one thing because it's built into a bunch of other things. We do have some of that but not very many. Giving up blocks removed a lot of them. Blocks gave an integrated editor, and fast integrated compiling, and a sort of paged virtual memory, and something you could easily turn into a somewhat inferior database, etc. It wasn't the best solution for very much but it gave an easy adequate solution for a whole lot. I read that using blocks was a fundamental cause of the Valdocs failure so many years ago. They started out with blocks and then ran into limits and instead of throwing them out and starting over they tried to design around them and ran out of time. Now we use blocks when the problem demands them instead of wherever they look good enough. It takes longer and we probably get better solutions. -- Jonah Thomas, [[https://groups.google.com/d/msg/comp.lang.forth/7gWtjMoQXk8/Wr0yBdbZMWsJ][comp.lang.forth 2003-07-18]]

What's up with the aversion to filesystems in forth languages?

by geon 3y ago

What's up with the aversion to filesystems in forth languages?

crc_ 3y ago

Filesystems introduce complexity that may not be needed, especially on smaller targets. I'm personally not averse to file systems. I've implemented (but not yet published) a couple for testing purposes. It's probable that one or more of these will eventually be included in Konilo. But that won't happen until I write a program that needs this and have an implementation that I'm happy with.

throwaway81523 3y ago

That was more of a thing in earlier days (before my time) when Forth typically ran on the bare hardware, replacing the OS. Later, blocks vs files became a big debate in the Forth world, but with Forth now usually hosted under a conventional OS, files have mostly won out except among some die hards. The ROM code for the Green Arrays processor though is still written using blocks. You can download it as a nicely formatted HTML file from greenarrays.com. Here's a Usenet post from 2003 that discusses blocks: The central thing Forth depends on is KISS. We've consistently rejected complicated solutions when simpler solutions work. The result is fewer co-adaptations, where you can't change one thing because it's built into a bunch of other things. We do have some of that but not very many. Giving up blocks removed a lot of them. Blocks gave an integrated editor, and fast integrated compiling, and a sort of paged virtual memory, and something you could easily turn into a somewhat inferior database, etc. It wasn't the best solution for very much but it gave an easy adequate solution for a whole lot. I read that using blocks was a fundamental cause of the Valdocs failure so many years ago. They started out with blocks and then ran into limits and instead of throwing them out and starting over they tried to design around them and ran out of time. Now we use blocks when the problem demands them instead of wherever they look good enough. It takes longer and we probably get better solutions. -- Jonah Thomas, [[https://groups.google.com/d/msg/comp.lang.forth/7gWtjMoQXk8/Wr0yBdbZMWsJ][comp.lang.forth 2003-07-18]]