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.

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

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

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

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

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.