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

61–70 of 172 posts

Re: Collapse OS – Why Forth?

#61

Post by zentiggr »

undershirt wrote: post #17

> Forth doesn't elegantly describe complex algorithms… However, this mental pain does makes you question your need for complexity… This is something that I think few developers are familiar with and is hard to describe with words. It needs to be experienced. Nice framing, that it’s not an intellectual argument you can make to justify the benefits of drawbacks (i.e. an infamous red flag of stockholm syndrome), so you…

I'll agree with the article's author - there is a quality to a Forth-style solution that just doesn't compare to other languages' styles or overall structure.

When I first heard of Forth and started trying out some of my own code, I was surprised by the initial effort it took me to adjust to writing small words vs C style functions.

I then started building on the pieces I first wrote, and it took very little code to cover my needs.

So yes, there's a very different experience, and it does take adjustment for anyone only familiar with function-style code. And it is not just what I've described, there's a whole different thought pattern involved.

Re: Collapse OS – Why Forth?

#62

Post by imode »

If the author wants their code to survive the apocalypse, they should generate Turing Machines that have a simple shim interpreter for low-power architectures. The benefit of this is you can build an interpreter for a TM in wood or other simple materials. Semi-Thue systems also fit.

Re: Collapse OS – Why Forth?

#63

Post by schwartzworld »

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.

it doesn't mean you have to, but forth is awesome.

Re: Collapse OS – Why Forth?

#64

Post by richdougherty »

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.

I think the argument against a custom IR is that once you start optimising your IR for compactness you'll probably end up near Forth in the design space anyway. As you say perhaps making the IR stack-based.

Once you're at that point you may as well just use Forth, especially since it's got a proven ability to work in these kinds of resource contrained, self-hosting/self-bootstrapping environments.

Re: Collapse OS – Why Forth?

#65

Post by zentiggr »

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/expect you to build on the foundation to create your own implementation. Like someone else in this thread said, N programmers, N dialects. Or, more accurately, every Forth program is its own DSL for accomplishing its work.

Re: Collapse OS – Why Forth?

#66

Post by gmfawcett »

mlang23 wrote: post #58
japanoise wrote: post #44

Earlier quoted context omitted.

A Forth shibboleth is that you have to implement your own in order to understand it. Try reading the assembly, then forth source, for jonesforth: https://github.com/AlexandreAbreu/jonesforth This is how I learned.

Oh wow, thanks. That is pretty much exactly what I was looking for.

Original repository and introductory article:

http://git.annexia.org/?p=jonesforth.git;a=shortlog

https://rwmj.wordpress.com/2010/08/07/jonesforth-git-reposit...

Re: Collapse OS – Why Forth?

#67

Post by logicprog »

KajMagnus wrote: post #50
krick wrote: post #24

I thought this is pretty fun project and the idea is just cool right away, but then I went on reading and was surprised by the fact it seems the author is serious. I would be really curious to hear his opinion on why the supply chains should collapse before 2030. Obviously, there wouldn't be a shortage of people in the comments who can start speculating on why it might happen, and, of course, I myself also can provid…

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

Re: Collapse OS – Why Forth?

#68

Post by zentiggr »

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.

A Forth word is simple enough that defining any other level of handling just isn't necessary. Trying to put an IR in would just be another layer and an unnecessary complication.

Using Forth gets pretty close to being the most compact representation all by itself, there's literally no extra tooling needed. No compiler or other translations, it's all just there in the words.

Re: Collapse OS – Why Forth?

#69

Post by DonHopkins »

haolez wrote: post #39

> Some Forth enthusiasts like the language for itself. They think that its easier to express much of the logic of a program in this language. Many books and tutorials are touting this. [...] That's not my opinion. In my opinion, it's not that FORTH code is hard to read, but that FORTH gives the programmer so much freedom that every program becomes its own microcosm of DSLs.

    : C(-; LICK SMILE NOSE WINK ;
( See my profile for more microcosmic FORTH DSLs! )

c(-;

https://news.ycombinator.com/user?id=DonHopkins

Re: Collapse OS – Why Forth?

#70

Post by andrewflnr »

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

Interesting perspective. For anyone else who wasn't familiar with this usage of "selection": https://en.wikipedia.org/wiki/Structured_program_theorem
Post reply on HN