Here is a Forth you can use on Linux and Windows
http://web.archive.org/web/20080828064920/http://ronware.org...
Collapse OS – Why Forth?
101–110 of 172 posts
Re: Collapse OS – Why Forth?
#102The weird thing about history is that it only makes sense backwards. Someone 500 years in the future might think of this as the Gutenberg printing press. It is often difficult to appreciate the magnitude of actions in the present.
Re: Collapse OS – Why Forth?
#103I 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?
Re: Collapse OS – Why Forth?
#104Earlier quoted context omitted.
> technology won’t save us because... I hope I’m not uncharitably interpreting your comment, but are you saying that technology will be some sort of panacea?
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.
> Technology isn't a complete panacea, but humans in general are highly adaptable. History seems to indicate...
The most critical processes for human success - population growth - is an exponential process. Pretty much all of it happened in the age of fossil fuels. We have 200 years (out of 200,000 of human history according to Wikipedia) of experience with global populations >1 billion and we are currently cruising at about 8 billion souls on the planet. All of that 200 years is in the context of freely available and rapidly growing utilisation of fossil fuels to power the logistics networks enabling the growth.
History doesn't show us being adaptable, history shows if something happens to the solid/liquid carbon supply around 7/8 of us are expected to die. And we can statistically all-but guarantee something will sooner or later over a long period.
Our major reason to be hopeful is our history isn't a guide and that something other than oil really makes strides. Maybe nuclear, maybe renewables.
Re: Collapse OS – Why Forth?
#105Earlier quoted context omitted.
> technology won’t save us because... I hope I’m not uncharitably interpreting your comment, but are you saying that technology will be some sort of panacea?
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.
Re: Collapse OS – Why Forth?
#106There seems to be a common conception that Forth is always interpreted by some kind of virtual machine. But it's quite possible to compile Forth all the way down to native machine instructions with no loss of interactivity and without losing the rapid bootstrap capability the author describes. Such a Forth runs almost as fast as C ( almost because modern out-of-order and other processor optimizations probably don't w…
> local variables I believe most modern forths will have these, gnuforth does for example. > down-to-the-metal compiling I think there are some that do this, but back in the day, the opinion of lots of forth programmers was that threaded code was good for the 90% of the program where performance didn't matter, and added an inline assembler for areas where it did.
And of course, you can always add support for local variables yourself. For an example, see http://turboforth.net/resources/locals.html, which takes 808 bytes to implement. That’s hefty, for some systems where one would use Forth, but, FTA, “Placing key values in locals will actually both increase peformance, and make your code smaller”, so you can earn that back if you use the facility enough)
Re: Collapse OS – Why Forth?
#107The weird thing about history is that it only makes sense backwards. Someone 500 years in the future might think of this as the Gutenberg printing press. It is often difficult to appreciate the magnitude of actions in the present.
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.
Re: Collapse OS – Why Forth?
#108If 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…
The ANS Forth standard supports named local variables. Unfortunately Forth dialects vary quite a bit in their implementation and prefered use of local variables, and the semantics of local variables are a bit hairy.
Cf. https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/ANS...
Re: Collapse OS – Why Forth?
#109If 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…
Note that Forth also supports locals. These will consume and remove N members from the stack so you can summon them as needed prior to calling the words.
But as someone that really got into Forth this year, I can assure that it does get better once you get more familiar with the language. I used to write commenting the stack effects on each line and now I barely need them as I write words in one sitting without that much effort.
Other developers are doing tacit programming in J or Haskell, pipe forward operators in F# or OCaml and threading macros on Lisp dialects and they seem to do fine.
Re: Collapse OS – Why Forth?
#110I think I've had my own moment of clarity that spans both Forth(s) and Lisp(s) and explains why neither is as common as other languages. In most common languages, there is a complicated base spec that covers many cases and defines a broad range of affordances, plus libraries and libraries that expand on an already fleshed out collection of tools and etc. Forths and Lisps give you the core of an environment, and let/e…
You are giving technical merits way too much credit.
People will put up with whatever bullshit as long as there is demand and helps them get a job.
The thing is, UNIX was a massive success, and it happened to be written in C. Since then, all successful languages had to have a familiar syntax with the host language.
It was UNIX that killed the Lisp Machine (by being given away for free). Programming languages never got to play a role.