Chuck Moore, Extreme Programmer

It is always cool to see UNI and Cedar Falls on HN. Also from CF and got my MIS degree at UNI.

> from scratch

This is even understating it -- it's not like he used existing software to lay out the chip, and then ran tests using PSPICE to verify the functionality. He wrote his own chip design software and analog simulator, and designed the chip in his own environment, and created the CPU, the GA144: a working 144-core processor designed to run "ArrayForth", a parallel version of Forth that he designed and authored, just as he designed ColorForth, and just as he designed, once upon a time, the language known as Forth.

Any of the tasks above seem like it would be a reasonable accomplishment for a good programmer. Combined, they make me question whether I even qualify as a developer by this standard, and make me wonder whether I should take a year off of development and just really learn Forth.

The "Do Not Speculate!" idea reminds me of the practice of delivering "the kitchen sink" when only a small program that does one thing would suffice.

It reminds me of when, e.g., a 1990s-2000s Windows user needed a small program that does one thing, and in order to get it, the download from Microsoft was an installer with hundreds of megabytes of unneeded binary files. It was not possible to download only the single program, which was no more than 1-2MB in size.

It reminds me of this quote: "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong

It reminds me of bloat, of giving users things they do not need. A problem that continues to this day.

Instead of bloated, complex UEFI, I wish something like OpenBIOS/OpenFirmware/SmartFirmware/OpenBOOT would be available for today's hardware. I have played around with fgen on i386 and read some of the history. They even provided courses on how to write drivers. Besides OLPC, why did this not catch on?

IMO, Forth is the most elegant and flexible language for initializing hardware.

I've heard of the wonders of Forth for many years -- about how it was just as good at metaprogramming as Lisp, how it was very powerful and yet extremely light-weight, about how you could run it on bare metal, and write your own OS and utilities in a fraction of the time it would take in other, more well-established languages, and so on.

I got really excited about it, and when I finally started learning it, I had very high expectations and really wanted to love it. Unfortunately, overall those expectations were not met. I did find the experience enlightening, as it was a pretty different way of programming, and I love to gain new perspectives. That said, I was disappointed to find Forth was mostly an obfuscated, write-only language.

Many in the Forth community preach that one should write only very short, well-documented "words" (ie. functions) that are clear and easy to understand. But the reality in the Forth code that I've seen was a lot of long, poorly documented, convoluted words which were a nightmare to read or debug. Granted, this was in the open source community. I've heard that the code in commercial Forths is in a much better state, but I don't have any experience with that.

One also seemed to have to write a lot of one's own code in Forth, because there just really weren't that many libraries you could lean on. I guess I prefer the more batteries included approach. I've also heard even Forth fans admit to me that writing Forth was painful and that the point of using Forth was to write yourself a higher level language as quickly as possible, so you don't have to work in Forth.

Well, I'm personally not all that interested in writing languages myself, and am quite content to use a pre-written language where all the hard and boring work was already done for me by someone else, and I can just use the nice higher-level features that already exist in these high level languages.

I guess if you're on a resource-starved system like some tiny microcontroller, using Forth over assembly might make sense. But as I usually work on relatively powerful desktops or servers, I don't really see the point of using Forth there at all. I'd just rather save myself the pain and hassle, and use any of number of existing high level languages to begin with.

As for Moore's work, I kind of see it like the work of someone building the Eiffel Tower out of toothpicks. It's certainly an impressive accomplishment. But how practical is it?

I'm also not sure how much Moore subscribes to what have become well-accepted software engineering practices such as having good documentation, clarity of code, and testing. It seems like he prefers to sacrifice all at the altar of size and performance. That's great as far as it goes -- if that's all that's important to you and you can make it work for you (and he certainly made it work for him). But looking around at the mountains of poorly documented hacky spaghetti code in the rest of the world, it just seems like following that path leads to an unmaintainable, buggy mess.. unless maybe you are Chuck Moore and can make it work anyway.

I don't know how much of the usual stack it accounts for or if it specifically was used for the GA144 but they're referring to OKAD, often talked about as in hundreds/thousands of lines of colorforth https://duckduckgo.com/?q=Moore+okad+forth&t=fpas&ia=web