6 ms·

Masterminds of Programming: Chuck Moore (2009)

98 points by chrispsn 7y ago

shrubble 7y ago
In reading this interview I couldn't help but think that what he was saying about his parallel computing chips, ended up applying to GPU's.
- agumonkey 7y ago
  I wonder if gpu core arrays can share ~high level code like GA144. Passing bits of forth thunks onto neighbors felt immensely powerful (and as much more rope to tie yourself into knots).
dewster 7y ago
If you actually look at the way Forth works you'll see that every stack manipulation wastes code space and real-time. Since there is only one data stack there are a lot of stack manipulations going on. Forth programmers are aware of this and do their best to minimize them, which tends to make their incredibly cryptic code even more cryptic. If the definition of a low level language is one that bedevils the programmer with minutiae, the Forth is the lowest of the low. I don't understand the fascination others have for it, and don't understand how anyone can like it after actually programming with it. It's horrible.
- LargoLasskhyfv 7y ago
  I hear that repeated often. What about 'Freude am Fahrvergnügen!' in a light sports car, vs. some wobbly limo or SUV? Furthermore: [1] http://home.pipeline.com/~hbaker1/ForthStack.html http://home.pipeline.com/~hbaker1/ForthStack.html [2] https://news.ycombinator.com/item?id=12237539 https://news.ycombinator.com/item?id=12237539 [3] https://news.ycombinator.com/item?id=13154111 https://news.ycombinator.com/item?id=13154111
- rabidrat 7y ago
  It teaches you to set things up so that the code doesn't have to do stack manipulations and other minutiae in the typical case. Most other languages seem to encourage modules with general APIs and hard boundaries so that the caller has to unpack/repack/rearrange the data as it enters and leaves. Forth very deliberately encourages developing a holistic system, and it discourages wholesale code reuse from other projects and systems, which gives you the power and flexibility to refactor relentlessly, until only the essence of the computational solution remains. Forth is definitely a difficult language to work with, particularly in a professional environment where managing turnover is massively important. When I dive in to some Forth code that I've written, to make even the smallest of changes, my brain has to be fully engaged, and that's a non-starter in most environments (Chuck probably thinks this is a good thing; why are we making changes to code we don't understand?). But I am still an avid proponent of learning and applying the principles of Forth, because of the results that it makes possible. It is quite eye-opening to see directly how a system can become 10x as powerful, with 1/10th of the code, if you are willing to do the work and embrace the "minimalist" (I would call it "essentialist") mindset.
- kragen 7y ago
  I have a hard time resisting the temptation of ROT >R myself at times, and it's true that I never pass arguments to the wrong function in C, while in Forth I do. Even assembly is less bug-prone in my experience. But I think there's probably a there there that I don't fully understand, and I want to. Sometimes I wonder if Forth would be better off with no stack manipulation words. If you really need to swap, after all, you can X ! Y ! X @ Y @. Chuck left SWAP out of the x18 in the end.
- upofadown 7y ago
  In a stack oriented language the stack manipulations are the logic. You could make a more complicated compiler to optimize them or use local variables but most people/projects don't bother. >Forth programmers are aware of this and do their best to minimize them, ... This has never been true in my experience. The effort goes into insuring that the stack manipulations are correct.
- thesz 7y ago
  One of Elbrus supercomputers was a stack machine that translated stack operations into out-of-order register operations, quite successfully. There was also a variant of Ada called El-76. (see more about Pentkovsky for more interesting stories) This means that you do not need to sacrifice speed for compactness. Also, zero-operand ISA (stack machines are zero-operands) have what can be called normalizing property: if you have stack layout for inputs and outputs you have only one optimal way to achieve it. E.g., "( b a -- x) swap -" sequence won't be different in any place where you have to compute b-a (in the register's three operand typical RISC case there are 32^3 combinations). This means that if you can use something like [1] Sequitur algorithm to make code more compact than six bit per opcode. [1] https://en.wikipedia.org/wiki/Sequitur_algorithm https://en.wikipedia.org/wiki/Sequitur_algorithm This is, actually, what Forth programmers often do manually. And in untyped language, which will not complain about stack layout violations after refactoring. But this does not mean that you cannot use, say, dependent types for Forth programs for better programming safety. And this does not mean that you can't benefit from single (or double) stacks or their alternatives. For example, Applicative class from Haskell's Prelude is good in expressing concatenative programs, just like ones in Forth, I think.
kick 7y ago
These types of books have always been a bit frustrating to me. Coders at Work is another one. Moore is a genius, and his inclusion is absolutely for the better. However, if it came just 5 years earlier, it would have been able to have so much more value. Falkoff's inclusion within was great, Falkoff contributed greatly to the APL ecosystem, but interviews with Iverson are scarce and hard to come across, and he had an amazing view on the big picture for these things. His books are probably the most valuable I have on my shelves. Also, it leaned far too hard on ALGOL's many derivatives. Roger Hui and Arthur Whitney would have been more valuable than most of the people included. Even Forth got three people interviewed, which is admittedly pretty cool! (PostScript is Forth.)
- yesenadam 7y ago
  >PostScript is Forth Last year I got into Forth, then PostScript, which seems a kind of dumbed-down, simplified Forth. On PostScript's wikipedia page, Forth is not mentioned as an influence. So I went to change that, and in the page html there's a comment saying if you came to add Forth, see talk page. I looked into it a bit. (One of?) The guy who wrote PostScript's previous couple of languages were based on Forth (wikipedia admits), but then PostScript was not so much as influenced by it?! That actually made me very angry! The PostScript reference manual reads as if written by lawyers, which maybe shed some light on it. They don't admit it's influenced by Forth, but say of course it has influences, and the next sentence is about Forth. As if they couldn't not mention Forth, but legally didn't want to spell anything out. Pretty disgusting treatment of Chuck Moore, seems to me. HN, help me right the wrong!
  - kick 7y ago
    It's at times like these where the corporatism of Wikipedia editors for any article involving a tech company shines through very clearly.
    - sansnomme 7y ago
      Consider the current lawsuits regarding APIs, I think it's probably safer for wikimedia to defer to whatever the corporate PR department believes to be correct lest they be compelled to testify in court.
kjs3 7y ago
I keep reading papers on stack-based vs register-based architectures, and it's clear there's no "conclusive" right-answer. But I think it's pretty telling that very little looks like a B5000, and an awful lot looks like a PDP-11/S360. Maybe the Forth faithful are right and the rest of us are too dumb to 'get' stack-based, but it's pretty clear what the market decided.
- RodgerTheGreat 7y ago
  The B5000 does not closely resemble a Forth machine. It is stack-oriented, but does not contain separate parameter and return stacks which may grow and shrink independently. You could perhaps argue that the JVM and its peers are the modern-day successors to the B5000.
  - kjs3 7y ago
    That wasn't the point. The point is that most of the field abandoned stack hardware for register hardware, upon which all sorts of software paradigms are implemented.
    - kragen 7y ago
      Sounds like somebody hasn't read Koopman yet.
      - kjs3 7y ago
        I've read Koopman; fascinating stuff. Really solidified my understanding of the use of multiple stacks in Forth-like environments. But I think it's instructive that none of the commercial architectures he describes (from 1989) have a contemporary descendant (although I think you can still get the RTX 2000 as a space-rated special order at an astronomical unit price). I think that tends to support my premise.
        kragen 7y ago
        That's reasonable. I thought you were talking about things like the B5000 and the 8087.
markus_zhang 7y ago
Can anyone elaborate on the bottom up method with a small but concrete example? Say I want to parse a special format of strings, read part of each line and dump into say. CSV, how would a Forth programmer approach the problem?
- rabidrat 7y ago
  One of the things about Forth, is that the techniques have not proven to be amenable to generalization. Chuck Moore himself says[0]: > I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. --- I would have to start by asking, what is the essence of what has to happen to parse the string? How I would approach the problem depends a great deal on the specifics of the actual problem. So, your "concrete" example problem would have to be a lot more concrete before a Forth programmer could even start tackling it. That's the nature of a bottom-up method. [0] http://www.ultratechnology.com/moore4th.htm http://www.ultratechnology.com/moore4th.htm
  - lifthrasiir 7y ago
    I feel the following line (from [1], quote original) is a way better summary: > Remember the freedom quote? "Forth is about the freedom to change the language, the compiler, the OS or even the hardware design". > …And the freedom to change the problem. [1] http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
    - kragen 7y ago
      Yosef Kreinin is a smart guy and a good writer but probably not a reliable authority on Forth.
      - lifthrasiir 7y ago
        Yes, but I didn't need an authority. I just needed a good summary for what Moore tries to say but not.
quantified 7y ago
I would like to find the motivated time to analyze how Forth and lambda-calculus functional languages compare/connect. Each Forth word seems to be effectively a lambda that must be connected to a correctly-typed stack, and words can themselves manipulate the stack as its own structure.
- kragen 7y ago
  Manfred van Thun’s Joy, Christopher Diggins’s Cat, Henry Baker’s Linear Lisp.
  - quantified 7y ago
    Thanks for the pointers!
- thesz 7y ago
  It is relatively easy. You can look at stack as a list: type Stack = [Int] Adding two values at top of stack is easy: add (a:b:stk) = (a+b) : stk Dropping and duping is also easy: drop (_:stk) = stk dup (x:stk) = x:x:stk double stk = add (dup stk) You can encode list using Church encoding [1] and voila! You just connected lambda calculus and stack machine (not Forth, but close). [1] https://en.wikipedia.org/wiki/Church_encoding#List_encodings https://en.wikipedia.org/wiki/Church_encoding#List_encodings Forth include more that just stack machine - return stack, vocabulary, definintions, memory, etc. This means that these simple definitions will not be as simple as above for complete Forth. But they also can be represented as Church encoded data and they still be representable in lambda calculus.
dang 7y ago
The book discussed in general at the time: https://news.ycombinator.com/item?id=583164 https://news.ycombinator.com/item?id=583164

98 points by chrispsn 7y ago

In reading this interview I couldn't help but think that what he was saying about his parallel computing chips, ended up applying to GPU's.

agumonkey 7y ago
I wonder if gpu core arrays can share ~high level code like GA144. Passing bits of forth thunks onto neighbors felt immensely powerful (and as much more rope to tie yourself into knots).

dewster 7y ago

If you actually look at the way Forth works you'll see that every stack manipulation wastes code space and real-time. Since there is only one data stack there are a lot of stack manipulations going on. Forth programmers are aware of this and do their best to minimize them, which tends to make their incredibly cryptic code even more cryptic. If the definition of a low level language is one that bedevils the programmer with minutiae, the Forth is the lowest of the low. I don't understand the fascination others have for it, and don't understand how anyone can like it after actually programming with it. It's horrible.

LargoLasskhyfv 7y ago
I hear that repeated often. What about 'Freude am Fahrvergnügen!' in a light sports car, vs. some wobbly limo or SUV? Furthermore: [1] http://home.pipeline.com/~hbaker1/ForthStack.html http://home.pipeline.com/~hbaker1/ForthStack.html [2] https://news.ycombinator.com/item?id=12237539 https://news.ycombinator.com/item?id=12237539 [3] https://news.ycombinator.com/item?id=13154111 https://news.ycombinator.com/item?id=13154111
rabidrat 7y ago
It teaches you to set things up so that the code doesn't have to do stack manipulations and other minutiae in the typical case. Most other languages seem to encourage modules with general APIs and hard boundaries so that the caller has to unpack/repack/rearrange the data as it enters and leaves. Forth very deliberately encourages developing a holistic system, and it discourages wholesale code reuse from other projects and systems, which gives you the power and flexibility to refactor relentlessly, until only the essence of the computational solution remains. Forth is definitely a difficult language to work with, particularly in a professional environment where managing turnover is massively important. When I dive in to some Forth code that I've written, to make even the smallest of changes, my brain has to be fully engaged, and that's a non-starter in most environments (Chuck probably thinks this is a good thing; why are we making changes to code we don't understand?). But I am still an avid proponent of learning and applying the principles of Forth, because of the results that it makes possible. It is quite eye-opening to see directly how a system can become 10x as powerful, with 1/10th of the code, if you are willing to do the work and embrace the "minimalist" (I would call it "essentialist") mindset.
kragen 7y ago
I have a hard time resisting the temptation of ROT >R myself at times, and it's true that I never pass arguments to the wrong function in C, while in Forth I do. Even assembly is less bug-prone in my experience. But I think there's probably a there there that I don't fully understand, and I want to. Sometimes I wonder if Forth would be better off with no stack manipulation words. If you really need to swap, after all, you can X ! Y ! X @ Y @. Chuck left SWAP out of the x18 in the end.
upofadown 7y ago
In a stack oriented language the stack manipulations are the logic. You could make a more complicated compiler to optimize them or use local variables but most people/projects don't bother. >Forth programmers are aware of this and do their best to minimize them, ... This has never been true in my experience. The effort goes into insuring that the stack manipulations are correct.
thesz 7y ago
One of Elbrus supercomputers was a stack machine that translated stack operations into out-of-order register operations, quite successfully. There was also a variant of Ada called El-76. (see more about Pentkovsky for more interesting stories) This means that you do not need to sacrifice speed for compactness. Also, zero-operand ISA (stack machines are zero-operands) have what can be called normalizing property: if you have stack layout for inputs and outputs you have only one optimal way to achieve it. E.g., "( b a -- x) swap -" sequence won't be different in any place where you have to compute b-a (in the register's three operand typical RISC case there are 32^3 combinations). This means that if you can use something like [1] Sequitur algorithm to make code more compact than six bit per opcode. [1] https://en.wikipedia.org/wiki/Sequitur_algorithm https://en.wikipedia.org/wiki/Sequitur_algorithm This is, actually, what Forth programmers often do manually. And in untyped language, which will not complain about stack layout violations after refactoring. But this does not mean that you cannot use, say, dependent types for Forth programs for better programming safety. And this does not mean that you can't benefit from single (or double) stacks or their alternatives. For example, Applicative class from Haskell's Prelude is good in expressing concatenative programs, just like ones in Forth, I think.

kick 7y ago

These types of books have always been a bit frustrating to me. Coders at Work is another one. Moore is a genius, and his inclusion is absolutely for the better. However, if it came just 5 years earlier, it would have been able to have so much more value. Falkoff's inclusion within was great, Falkoff contributed greatly to the APL ecosystem, but interviews with Iverson are scarce and hard to come across, and he had an amazing view on the big picture for these things. His books are probably the most valuable I have on my shelves. Also, it leaned far too hard on ALGOL's many derivatives. Roger Hui and Arthur Whitney would have been more valuable than most of the people included. Even Forth got three people interviewed, which is admittedly pretty cool! (PostScript is Forth.)

yesenadam 7y ago
>PostScript is Forth Last year I got into Forth, then PostScript, which seems a kind of dumbed-down, simplified Forth. On PostScript's wikipedia page, Forth is not mentioned as an influence. So I went to change that, and in the page html there's a comment saying if you came to add Forth, see talk page. I looked into it a bit. (One of?) The guy who wrote PostScript's previous couple of languages were based on Forth (wikipedia admits), but then PostScript was not so much as influenced by it?! That actually made me very angry! The PostScript reference manual reads as if written by lawyers, which maybe shed some light on it. They don't admit it's influenced by Forth, but say of course it has influences, and the next sentence is about Forth. As if they couldn't not mention Forth, but legally didn't want to spell anything out. Pretty disgusting treatment of Chuck Moore, seems to me. HN, help me right the wrong!
- kick 7y ago
  It's at times like these where the corporatism of Wikipedia editors for any article involving a tech company shines through very clearly.
  - sansnomme 7y ago
    Consider the current lawsuits regarding APIs, I think it's probably safer for wikimedia to defer to whatever the corporate PR department believes to be correct lest they be compelled to testify in court.

kjs3 7y ago

I keep reading papers on stack-based vs register-based architectures, and it's clear there's no "conclusive" right-answer. But I think it's pretty telling that very little looks like a B5000, and an awful lot looks like a PDP-11/S360. Maybe the Forth faithful are right and the rest of us are too dumb to 'get' stack-based, but it's pretty clear what the market decided.

RodgerTheGreat 7y ago
The B5000 does not closely resemble a Forth machine. It is stack-oriented, but does not contain separate parameter and return stacks which may grow and shrink independently. You could perhaps argue that the JVM and its peers are the modern-day successors to the B5000.
- kjs3 7y ago
  That wasn't the point. The point is that most of the field abandoned stack hardware for register hardware, upon which all sorts of software paradigms are implemented.
  - kragen 7y ago
    Sounds like somebody hasn't read Koopman yet.
    - kjs3 7y ago
      I've read Koopman; fascinating stuff. Really solidified my understanding of the use of multiple stacks in Forth-like environments. But I think it's instructive that none of the commercial architectures he describes (from 1989) have a contemporary descendant (although I think you can still get the RTX 2000 as a space-rated special order at an astronomical unit price). I think that tends to support my premise.
      - kragen 7y ago
        That's reasonable. I thought you were talking about things like the B5000 and the 8087.

markus_zhang 7y ago

Can anyone elaborate on the bottom up method with a small but concrete example? Say I want to parse a special format of strings, read part of each line and dump into say. CSV, how would a Forth programmer approach the problem?

rabidrat 7y ago
One of the things about Forth, is that the techniques have not proven to be amenable to generalization. Chuck Moore himself says[0]: > I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. --- I would have to start by asking, what is the essence of what has to happen to parse the string? How I would approach the problem depends a great deal on the specifics of the actual problem. So, your "concrete" example problem would have to be a lot more concrete before a Forth programmer could even start tackling it. That's the nature of a bottom-up method. [0] http://www.ultratechnology.com/moore4th.htm http://www.ultratechnology.com/moore4th.htm
- lifthrasiir 7y ago
  I feel the following line (from [1], quote original) is a way better summary: > Remember the freedom quote? "Forth is about the freedom to change the language, the compiler, the OS or even the hardware design". > …And the freedom to change the problem. [1] http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
  - kragen 7y ago
    Yosef Kreinin is a smart guy and a good writer but probably not a reliable authority on Forth.
    - lifthrasiir 7y ago
      Yes, but I didn't need an authority. I just needed a good summary for what Moore tries to say but not.

quantified 7y ago

I would like to find the motivated time to analyze how Forth and lambda-calculus functional languages compare/connect. Each Forth word seems to be effectively a lambda that must be connected to a correctly-typed stack, and words can themselves manipulate the stack as its own structure.

kragen 7y ago
Manfred van Thun’s Joy, Christopher Diggins’s Cat, Henry Baker’s Linear Lisp.
- quantified 7y ago
  Thanks for the pointers!
thesz 7y ago
It is relatively easy. You can look at stack as a list: type Stack = [Int] Adding two values at top of stack is easy: add (a:b:stk) = (a+b) : stk Dropping and duping is also easy: drop (_:stk) = stk dup (x:stk) = x:x:stk double stk = add (dup stk) You can encode list using Church encoding [1] and voila! You just connected lambda calculus and stack machine (not Forth, but close). [1] https://en.wikipedia.org/wiki/Church_encoding#List_encodings https://en.wikipedia.org/wiki/Church_encoding#List_encodings Forth include more that just stack machine - return stack, vocabulary, definintions, memory, etc. This means that these simple definitions will not be as simple as above for complete Forth. But they also can be represented as Church encoded data and they still be representable in lambda calculus.

dang 7y ago

The book discussed in general at the time: https://news.ycombinator.com/item?id=583164 https://news.ycombinator.com/item?id=583164