He describes the good Forth programmers as people who are so smart they can focus on nothing but the problem. To such people, programming languages, operating systems, libraries, even the chips that run all this stuff, they are all non-problems, to be reduced or eliminated. And to do that, it requires that the mind be able to compensate for all the comfort all of those layers would have afforded.
> Why pay this cost? [The cost of adding junk you don't actually need]
> Because I don't do algorithms, other people do, so I have to trust them and respect their judgment to a large extent.
> Because you need superhuman abilities to work without layers.
> The Forth way of focusing on just the problem you need to solve seems to more or less require that the same person or a very tightly united group focus on all three of these things, and pick the right algorithms, the right computer architecture, the right language, the right word size, etc.
> I don't know how to make this work.
> having people being able to do what at least 3 people in their respective areas normally do, and concentrating on those 3 things at the same time
> Doing the cross-layer global optimization.
A sufficiently smart person is capable of analyzing and optimizing the problem from the requirements all the way to the literal chip running the software. They come up with custom unconventional algorithms and implement weird chips with 18 bit words.
These are people who are smart enough to modify standard engineering equations. Those things weren't sacred to them, they understood them to the point they felt confident enough to change them in such a way that they could be efficiently implemented in some weirdly minimal custom chips[1]. And this somehow yielded more efficient algorithms which were easy to implement in Forth.
I share their enthusiasm for minimalism and eliminating the dependencies and the "junk". It always ends with me learning everything I can about the junk and doing it myself, maybe even reimagining it, hopefully better and smaller this time. I can only hope to one day be half as smart as some of these folks seem to be, though. Every time I try to get into hardware, I discover my limits.
[1]: The Yamaha DX7 is an example. People understood things and reframed the problems until the solution fit the available resources. They needed a sine wave...
> multiplying the sine wave by the envelope level yields the output
> However, fast multiplication required too much hardware in the 1980s, so the DX7 uses a mathematical shortcut: adding logarithms is equivalent to multiplying the values.
> The obvious problem is that computing logarithms is harder than multiplying, but the trick is to store the (negated) logarithm of the sine wave in the lookup table (below) instead of the sine wave.
> This provides the logarithm for free.
> The implementation takes advantage of the symmetry of the sine wave so only a quarter-wave needs to be stored.
Thanks for clarifying! In that case, he and I have the same "problem" although at very different levels. I've written in other posts about Forth and Lisp that I would very much like to get over the hump of changing how I think about problems. Unfortunately, I have never been able to do it.
There are times where I see how Moore and McCarthy are using a language to define itself. I can sort-of understand how Moore creates a custom language in Forth to tackle something. But, damned if I can explain it or apply that to even a toy problem. I am thankful that there are people out there who can think differently.
That being said, I wonder whether those applications tend to be embedded or devices, that lend to "first, you must invent the world" style thinking (which is good!)
The last task I was doing on a side project was making sure some bidirectional content accessible by a screen reader, which was the ultimate task of relying on other people's work.
Ultimately, I can't imagine having to think through in an integrated matter all of the layers that power this TTS – from the Unicode parsing, through the NN models to the sound synthesis, all the way to dealing with sound output.
He describes the good Forth programmers as people who are so smart they can focus on nothing but the problem. To such people, programming languages, operating systems, libraries, even the chips that run all this stuff, they are all non-problems, to be reduced or eliminated. And to do that, it requires that the mind be able to compensate for all the comfort all of those layers would have afforded.
> Why pay this cost? [The cost of adding junk you don't actually need]
> Because I don't do algorithms, other people do, so I have to trust them and respect their judgment to a large extent.
> Because you need superhuman abilities to work without layers.
> The Forth way of focusing on just the problem you need to solve seems to more or less require that the same person or a very tightly united group focus on all three of these things, and pick the right algorithms, the right computer architecture, the right language, the right word size, etc.
> I don't know how to make this work.
> having people being able to do what at least 3 people in their respective areas normally do, and concentrating on those 3 things at the same time
> Doing the cross-layer global optimization.
A sufficiently smart person is capable of analyzing and optimizing the problem from the requirements all the way to the literal chip running the software. They come up with custom unconventional algorithms and implement weird chips with 18 bit words.
These are people who are smart enough to modify standard engineering equations. Those things weren't sacred to them, they understood them to the point they felt confident enough to change them in such a way that they could be efficiently implemented in some weirdly minimal custom chips[1]. And this somehow yielded more efficient algorithms which were easy to implement in Forth.
I share their enthusiasm for minimalism and eliminating the dependencies and the "junk". It always ends with me learning everything I can about the junk and doing it myself, maybe even reimagining it, hopefully better and smaller this time. I can only hope to one day be half as smart as some of these folks seem to be, though. Every time I try to get into hardware, I discover my limits.
[1]: The Yamaha DX7 is an example. People understood things and reframed the problems until the solution fit the available resources. They needed a sine wave...
https://www.righto.com/2021/12/yamaha-dx7-reverse-engineerin...
> multiplying the sine wave by the envelope level yields the output
> However, fast multiplication required too much hardware in the 1980s, so the DX7 uses a mathematical shortcut: adding logarithms is equivalent to multiplying the values.
> The obvious problem is that computing logarithms is harder than multiplying, but the trick is to store the (negated) logarithm of the sine wave in the lookup table (below) instead of the sine wave.
> This provides the logarithm for free.
> The implementation takes advantage of the symmetry of the sine wave so only a quarter-wave needs to be stored.