Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Collapse OS – Why Forth?

collapseos.org

Post reply on HN
Print view View original

91–100 of 172 posts

Re: Collapse OS – Why Forth?

#91

Post by mikekchar »

c2the3rd wrote: post #89
zentiggr wrote: post #65

I 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…

Why not say "Every ~~Forth~~ program is its own DSL for accomplishing its work."? For moderately complicated programs in any language you choose, it can take a long time to grok how the literal code relates to solving the conceptual problem. No language can build in every abstraction, and no programmer has time to learn them all. I think you are close to part of an answer, but it isn't because Forth and Lisp expect o…

To be fair, it is very common for Forth programmers to redefine the interpreter as they go. You literally change the language in your program. That's a very different expectation for other kinds of languages.

Re: Collapse OS – Why Forth?

#92

Post by dreamcompiler »

There 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 work well on compiled Forth code).

I used this approach when I bootstrapped a Forth compiler on the TI 34010 graphics chip in a similar fashion as the author. It even had local variables so you didn't drive yourself mad thinking about the stack all the time.

My favorite commercial example of such a Forth was Mach 2 Forth on the early (pre-OSX) Macs. I don't know if any modern Forths do down-to-the-metal compiling or local variables, but I'd be interested to find out.

Re: Collapse OS – Why Forth?

#93

Post by monadic2 »

megameter wrote: post #47

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)…

> But, like any good language with meta expression capabilities, you can work your way up towards complex constructs in Forth, and write words that enforce whatever conceptual boundaries are needed and thus check your work and use the system as a compiler. That's what breaks Forth away from being a simple macro-assembler. But you have to write it in that direction, and design the system that makes sense for the task from the very beginning. That falls into an unacceptable trade-off really easily in our current world, where the majority of developers are relatively inexperienced consumers of innumerable dependencies.

Well expressed, I often think of the stack as the syntax of the language, not the runtime implementation, and it is quite difficult to hire for this skill without spending a lot of money.

Re: Collapse OS – Why Forth?

#94

Post by rs23296008n1 »

MaxBarraclough wrote: post #56
zentiggr wrote: post #53

Earlier quoted context omitted.

The rest of the storyline of this page covers what I think is the core concept that Chuck Moore started from, and defines Forth as its own environment: the core of the language that needs to be defined in order to write and execute Forth words is surprisingly small. Once you have the core words in place, you can layer on exactly the constructs you need. I won't claim to be a proficient Forth author, but I've used it…

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.

Forth basically is IR between high level and whatever is your concept of "low level". The nature of forth is that forth words can be written as composition of other forth code or syscalls to native code or as chunk of native code.

I say "concept" because you can run forth code on an interpreter or any number of semi-compiled or compiled approaches that get more and more closer to assembly.

Re: Collapse OS – Why Forth?

#95

Post by jcranmer »

lmohseni wrote: post #90
jcranmer wrote: post #85

Earlier quoted context omitted.

There's apparently an English translation released very recently: "How everything can collapse: A manual for our times." I haven't read either version, but piecing together the thesis from reviews, it seems to be a somewhat more evolved form of Malthusian catastrophe and Peak Oil(/Energy), with a dash of climate change alarmism [1] and Piketty-style concern over inequality. And technology won't save us because... wel…

> 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.

Re: Collapse OS – Why Forth?

#96

Post by theamk »

megameter wrote: post #47

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, and nothing else. This really makes programs much harder to understand, as it requires one to remember much more things while reading the code.

Re: Collapse OS – Why Forth?

#97

Post by chii »

megameter wrote: post #47

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)…

> That falls into an unacceptable trade-off really easily in our current world, where the majority of developers are relatively inexperienced consumers of innumerable dependencies.

aka, this is hard to do, and a difficult mental model to learn. It's the same kind of thing with LISP'y languages and functional languages (not the same model, but the same level of difficulty).

Re: Collapse OS – Why Forth?

#98

Post by redisman »

Love this project. I wonder why not make it run on smartphones? I'd imagine that's the vast majority of computers out there today. Easier to find a working smartphone than retro consoles.

Re: Collapse OS – Why Forth?

#99

Post by ehaliewicz2 »

dreamcompiler wrote: post #92

There 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.

Re: Collapse OS – Why Forth?

#100

Post by KajMagnus »

logicprog wrote: post #67
KajMagnus wrote: post #50

Earlier quoted context omitted.

> I would be really curious to hear his opinion on why the supply chains should collapse before 2030 Think about seat belts. Do you ask the driver: > "I'm really curious to hear why you think you'll crash the car?" when s/he puts on the seat belt? S/he'd likely say "No I don't think that at all". And not impossible that the Collapse OS author might have a similar reply. Still, the project can be well spent time, like…

He said in the Why? article linked above somewhere that he really does believe, even if he has no evidence, that we'll be experience a collapse sometime around 2030. That's not really comprehensible to me, even though your description of a possible rationale, which makes more sense.

Oh, thanks for explaining. Here's the Why article: https://collapseos.org/why.html (didn't see it before).

In it, he writes: "... two important stages of collapse ... the second one is when, in a particular community, the last modern computer dies ... decades between the two ... Collapse OS won't be actually useful before you and I are both long dead"

making me wonder if one scenario he has in mind, is the different biggest countries in the world stopping trading with each other, so it won't be possible to get more rare earth metals (needed for today's computers, right). And then, maybe downhill from there, the thereafter following 50 or 100 years? — But not _necessarily_ a nuclear winter or something that dramatic & sudden.

And ... He also writes:

> What made me turn to the "yup, we're fucked" camp was "Comment tout peut s'effondrer" [a book]

I think you'd find the answers in that book then? Seems the book got translated: "How Everything Can Collapse" [in our lifetime] by Pablo Servigne.

Post reply on HN