Chuck Moore

Inventor of the Forth Language. Radical thinker and inventor. He isn't afraid to even piss off Forth followers (he thinks ANS Forth was a big, big mistake).

The ANS Forth standard does not express Moore's vision of Forth. Moore believes the ANS standard is far too large and complex, and he doesn't see much value in any standard since people should write their own Forth. It is fair to say that most of the Forth community disagrees.

Moore left the mainstream of Forth several years ago, and has since worked mainly on chips which directly run Forth as their instruction set. Many believe that Moore has journeyed far away along the "Blue Plane"... (Stealing an idea articulated in Alan Kay's allusion to Arthur Koestler's metaphor of progress in two planes -- see web.archive.org .) He is currently working on the next generation of Forth Language called Color Forth.

He led development at IntellaSys, where he almost realized his decades-long dream of high-performance, low dissipation Forth chips. Here are the stats of the Sea Forth 24-core processors he demoed at the Nov-17-2007 Forth Day:

die size: 3x3mm (!)

24 cores

1 billion instructions per second per core (!!)

9 mW dissipated per core at full speed There are limitations though:

32 opcodes, operandless, like all his Forth chips (This is actually one more primitive than was available on earlier designs!)

18-bit words

only 64 words of RAM per core (though that fits up to four instructions per word)

only some of the cores connect to the outside, so you must route your code/data yourself to each of the cores you wish you use Even with these limitations, there were some amazing demos:

decoding H.264 video (MPEG4) using only two cores

music synthesis with 10 voices (dedicating two cores per voice), integrated using waveguide synthesis

grayscale SVGA (only one color channel, because the Sea Forth has only two built-in DACs, not enough for full color)

software AM/FM radio

prototyping: 1GB USB Flash drive with a Sea Forth chip on-board and its IO ports exposed.

www.intellasys.net - datasheets are available upon request

Alas, Chuck has been plagued by poor business partners. He has had his work stolen by both Patriot Scientific and Intellasys. He is currently litigating with both. He now develops his designs in his own company, Green Arrays. He has scaled down his product from 32 to 4 cores, for smaller packaging and even lower power dissipation. He has started publishing techniques for programming this very idiomatic chip: www.colorforth.com www.colorforth.com

His personal homepage is here: www.colorforth.com

He has started writing a personal blog: www.colorforth.com Fascinating insights into the mind of a veteran engineer.

Green Arrays hardware development blog: www.colorforth.com

Jeff Fox has a web site at www.ultratechnology.com which contains several talks by Chuck Moore. More recent interview: www.simple-talk.com He was also published in Masterminds of Programming (ISBN 978-0-596-51517-1)

For more info on Forth Language and Chuck Moore, see www.forth.com

Also check out his Slash Dot interview: slashdot.org

www.forth.org


Moore has been following the same set of values for thirty years. The numerical majority of people who write Forth code have been trying to make it more like other languages, taking it in directions opposed to Moore's core values (e.g. adding huge libraries to the core, throwing in lots of late-binding extensions, etc.). They're the ones who're going in a new direction, not Chuck.

The interested reader should go poke around on Chuck's site, read what he has to say, and keep reading past the point where you think to yourself,

"This is all wrong! That's not how to develop software!". XP people will have an easier time finding common ground with him, since he's a big fan of factoring and solving only the problem you have now. --George Paci

As I read about Moore's philosophy, I'm struck by the similarities with XP: Moore's basic principle is "Keep it simple!" and his first corollary is

"Do not speculate!". This is mainstream XP. --Joe Bowbeer

The Evolution of Forth: www.forth.com


Moore's programs are highly factored, which might trip up some, but they're much easier to understand than the much bigger programs other people would write to solve the same problem.

I wonder if the same people who praise his factoring have actually tried to read some of his more involved Color Forth code, such as the PNG generation code?

Those who don't know Forth won't be able to read Forth. Conversely, those who don't know C won't be able to read C. If you know Forth, you can read Forth source code. Some are better than others, obviously. You can write obfuscated code in any language. However, having dealt with both Color Forth and punctuated Forth, of which I prefer the latter, I can say that Chuck's code is well-factored. As with any large coding development, however, you must understand "the big picture" before you can understand the little stuff. If you don't understand his PNG generation code, then you either don't understand his big-picture/metaphor, or you don't understand his coding conventions, or both (note that metaphor and coding conventions are two very important concepts in Extreme Programming as well, providing yet more common ground between Forthers and XPers). Here's a hint though: most of what he does for generating files is to build a RAM-based image of the file first in the dictionary, then he bulk-writes it out to a file, then he releases the memory when it's no longer needed.

I have to disagree with you on readability. Forth is radically different from other programming languages. Look at this Forth And Csample. If you know, say, Pascal or Fortran, heck, even BASIC, you've got a good shot and understanding the general flow of a C program. At least, you'll be able to get an idea of what's going on here or there. On the other hand, you might know 10 programming languages and still not have a clue what's going on in a Forth program until you've done some programming in it. Forth is wonderful, but totally bizarre. - Richard Lack

So if you know any Algol-family language then you'll have a shot at partially understanding another Algol-family language, but that doesn't help much with reading non-Algol-family languages? Knowing BASIC doesn't help with understanding Lisp or Prolog? Gee, what a surprise. -- Doug Merritt

Indeed; I know English, and due to my familiarity with it, I can also pronounce Italian (but not necessarily understand it) because they both use the Latin character set and similar-enough pronunciation rules. But ask me to read Chinese, and I couldn't even begin to tell you what I'm looking at. By the same token, someone familiar only with C or BASIC will look at Forth in shock and horror, as you (Richard) have done above, and say, "But, no! It's not readable! It's trash! You LIE!" You just patently demonstrated what I'd written originally -- that you don't know Forth, and therefore, cannot read it. Try reading Sumerian cuneiform(sp?)! Try reading Incan quipus (language using knots, not scribbles)! Can't do it, can you? Of course not. Same thing applies with computer languages. They're called languages for a reason.

If, on the off chance, that you do have Lisp experience, reverse the order (instead of verb/objects, it's objects/verb), and you have some idea of how to read Forth. But again, only an idea -- until you code in Forth, you just won't be able to read it, any more than someone who's never programmed before won't be able to read BASIC until they code in BASIC.

I remember reading Smalltalk once and thought to myself, "How can anyone understand this? It's incomprehensible." Now, it's my all-time favorite infix (if you can call it that) notation.

And as someone who has experience with infix, prefix, and postfix notations, by golly, postfix is the most natural to me. --Samuel Falvo


Quotes from the Slash Dot interview:

Automatically generated or factored code has never impressed me. Nor has automatic place and route for circuit boards or silicon. They are both an order-of-magnitude from human performance. Because humans understand the problem, judge the results and cheat as required.

I grew up worshiping Principia Mathematica 'till I learned how Goedel refuted it. The result is that I distrust formal representations. For example, the ANSII Forth standard does not describe Forth, but a language with the same name.

The advantage of Forth in this kind of context is that it scales. Forth is the Machine Language, Forth is the High Level Language, Forth is the task-control language, Forth is the supervisory language. Each of these has a different vocabulary, but they share syntax, compiler and programmer skills.

I've been bemused with the preoccupation of new languages with text processing. I've been accused of not providing string operators in both Forth and colorForth. Indeed, I haven't because I don't use them. Editing a file to pass on to another program never struck me as productive. That's one reason I chose pre-parsed source, to break the dependence upon strings and text processors.

My goal is to develop tools that augment my abilities. If others can use them, fine. It would be foolish to lose an opportunity to explore or excel just to conform to some equalitarian philosophy. Too often our culture seeks the lowest common denominator.

These [newer] languages are all infix. Which is extraordinarily clumsy for anything but arithmetic expressions. And even those are comfortable only because we learned them in Algebra 101. Do you remember the learning curve?

Stacks are a compiler-friendly construct. Every compiler has to use one to translate infix notation to postfix. If this stack solution has to be assigned to registers, it's an extra step. Forth uses stacks explicitly and avoids the whole subject.


See original on c2.com