Hacker News Reader

>Given the absence of "higher-level" constructs, the resulting OS will never be as complex as something like an NT kernel

i wonder whether you've worked with Forth - in my view of Forth (spent 1987-89 mostly in Forth running on 8088 clone based terminal of USSR clone of IBM 360, so Forth is my second language after mandatory Pascal and the first true "computer" love really) what you said is a huge advantage and natural characteristic of Forth, not a deficiency. Everything in the Forth world is like Salvador Dali's clock face plates - flexible/pliable/flowing and you build whatever "higher-level" constructs and complexity levels you need right now and leave them behind the moment you don't need them anymore, create and destroy worlds as you go... In comparison to that the static monstrosity like NT kernel is just dead dusty world of an ancient complex tech civilization who died off under the weight of its own complex tech.

To Cyph0n below: man, as an enterprise programmer for 25 years i completely understand and agree with you. As that Forth programmer enjoying it 3 decades ago i can only say to you - you just don't get it :)

That was an analogy attempting to explain what OKAD does. The kernel represents the circuit being designed, while the assembler represents the OKAD toolchain.

The goal of the analogy was to demonstrate that OKAD is not suitable for designing large circuits, just like using assembly to write a modern kernel is not practical.

Well, presumably it’s not meant to be suitable for designing large/complex circuits, but rather to solve just the specific problems that Moore had when he wanted to make a chip. That’s an essential part of Forth philosophy: write only and exactly what you need. Forth itself is designed this way, to be the minimal useful tool you can bootstrap in a few dozen instructions on a chip with almost no resources.

> Not even a moderately complex digital chip from the mid-90s could be designed and verified using such a simplistic toolchain.

Maybe he didn't want to design a moderately complex chip to begin with? His 144 core chip is likely very simple. OKAD may have been sufficient.

>>modern EDA toolchain from e.g. Cadence is many orders of magnitude more complex.

Moore considers that a mangitude of bugs not features.

http://yosefk.com/blog/my-history-with-forth-stack-machines....

Has some good quotes on it if you scroll down to the end

Oh N.B. I just looked it up the GA144 is fabbed at 150nm

And ?

TL;DR Not really as impressive as it was made out to be.

You're entirely missing the point made by Chuck Moore and by extension probably don't understand why his way of looking at programming and the Forth language in particular are a big deal even this long after their invention.

This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't actually need 4 GHz chips and billions of transistors to get the job done then why would you?

Reliability and simplicity go hand-in-hand.

> This kind of minimalism and stripping things down to their essence is a powerful tool to allow you to focus on what matters rather than at all those things that don't really matter. If you don't actually need 4 GHz chips and billions of transistors to get the job done then why would you?

I agree entirely. I just wanted to point out that it's not accurate to equate what Chuck designed (i.e., OKAD) to a modern EDA toolchain and technology node.

If it works for him, then great!

Nobody equated that. The time when he made his is decades ago, so obviously nothing from those days compared to a modern EDA toolchain and associated bits and pieces.

I think you subconsciously added the 'modern' in there somewhere and then argued against that.

You might actually be right. When I read this:

> He wrote his own chip design software and analog simulator

I immediately thought of a modern toolchain. Had I known that this was done decades ago, I might have reacted differently.

Nonetheless, even decades ago, both Cadence and Synopsys likely had pretty advanced tools under development. I may be mistaken though.

Heh, I remember running Solo 2030 on Motorola-based Sun workstations almost 25 years ago...

Moore mentioned these in passing at the end if the link https://colorforth.github.io/1percent.html He was stressing the solution fits the problem. Not a solution which can cover/contain the problem

And here's why that matters. Below is the complete source of a Forth block editor. This editor is more than sufficient to write an OS with, although of course emacs or vim would be better. That is pretty awesome.

Forth is a language in which it's realistic for each programmer to have his own custom editor. That's even more awesome.

    | RetroForth Block Editor (http://www.retroforth.org)
    | * Released into the public domain *
    |
    | This is the block editor from RetroForth Release 9.2.1
    | It splits the normal 1k block into two smaller 512-byte blocks,
    | the one on the left for code, and the one on the right for
    | documentation/comments. Both are displayed side by side.
    |
    | It makes use of some features specific to RetroForth, so it
    | will not work on an ANS FORTH system without changes. 
   
   
    tib 1024 + constant <buffer>
    128 variable: <#blocks>
    <buffer>  variable: b0
    variable  current-block
   
   
    : there b0 @ ;
    : #-of-blocks <#blocks> @ ;
   
   
    : new there #-of-blocks 512 * 32 fill 0 current-block ! ; new
   
   
    : (block) @current-block : block 512 * there + ;
    : (line) 32 * (block) + ; 
   
   
    : p 2 current-block -! ;
    : n 2 current-block +! ;
    : d (line) 32 32 fill ;
    : x (block) 512 32 fill ;
    : eb (block) 512 eval ;
    : el (line) 32 eval ;
    : e 16 for 16 r - el next ;
    : s !current-block ;
    : i 0 swap : ia (line) + lnparse rot swap move ;
    : \ 1 s e ;
   
   
    loc:
     : | '| emit ; 
   
   
     : row dup 32 type 32 + ;
     : left# -16 + negate dup @base <if space then . ;
     : right# negate 32 + . ;
     : code|shadow row | swap row swap space ;
     : rows 16 for r left# code|shadow r right# cr next ;
     : x--- 2 for ." +---:---+---:---" next ;
     : --- space space space x--- | x--- cr ;
     : blocks @current-block 1+ block @current-block block ;
     here ] --- blocks rows 2drop --- ;
    ;loc is v
   
   
    : edit [[ clear v ]] { is ui } ;

> : right# negate 32 + . ;

This is an example of "ugly" Forth code. It's ok here to make the code as short as possible.

In reality I would write (educational) Forth code this way. The texts in parentheses are comments.

  ( compute Hypotenuse sqrt[a²+b²] )
  : hypo       ( a  b   )
    swap       ( b  a   )
    dup *      ( b  a²  )
    swap       ( a² b   )
    dup *      ( a² b²  )
    +          ( a²+b²  )
    sqrt       ( result )
  ;

  ( Application:  1.2 3.4 hypo )

Isn't the first swap unneccesary?

Of course. You learn quickly ;-)

Aren't a lot of us already doing what matters, but just not articulating it the same way?

I collaborate on a team, so we use one documentation standard and one coding style. We've stripped down our coding and commenting styles to the bare essential--one style that works across the whole team, across the lifespan of the project.

The business that pays our team pays for what customers want. Every once in a while a new guy on the team will write something no one wanted, and we end up chucking it. We're stripping down the project code to the bare essentials necessary to make money.

I think what Chuck Moore brings is not so much a plain ol' minimalism, but a nostalgia for a wild west "one man in a garage" tech scene that never really existed, at least not the way we like to imagine it did, because we live in a world driven as much by money as by love of cool new things.

Not to say he doesn't do cool things, but I could do cool things if I didn't have to answer to business constraints, my fellow team members, and so on.