The Forth Methodology of Charles Moore (2001)
ultratechnology.com
The Forth Methodology of Charles Moore (2001)
1–10 of 65 posts
Re: The Forth Methodology of Charles Moore (2001)
#2you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.
Re: The Forth Methodology of Charles Moore (2001)
#3you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.
That is: there are more dimensions to real-world solutions than purely technical.
Re: The Forth Methodology of Charles Moore (2001)
#4you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.
in pre-c programming practice it was common to write programming language keywords and variables in all upper case, among other reasons because teletypes and computer character codes often omitted lower case. in prose this rather rebarbative convention serves to distinguish them from natural-language words, much as we often use typewriter typefaces today. it is not intended as shouting, which i think is your reading. the loop we write in c as
do {
x();
y();
} while (!z());
begin x y z until
the thesis of this document is that you get faster results by taking the time up front to think your problem through until you understand it, and throwing away your code and hardware designs is not something to be afraid of
i'm not sure jeff and chuck's results at itv bore this out; hardware kept evolving out from under them too fast, other people's code became more useful (because of shitty hardware, because of the free software movement, because efficiency became less critical, and because of higher-level languages with better reusability), and they ran out of money
but simplifying a problem is still immensely valuable when you can do it. the problem with programming continues to be overcomplicating things
Re: The Forth Methodology of Charles Moore (2001)
#5you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.
That is: there are more dimensions to real-world solutions than purely technical.
that's jeff's main point here
Re: The Forth Methodology of Charles Moore (2001)
#6It's a nice philosophy, but good luck doing this in a strict Scrum process.
Re: The Forth Methodology of Charles Moore (2001)
#7It's a nice philosophy, but good luck doing this in a strict Scrum process.
Well, there is the question of how much quality we want or need. This process is by someone who created a very terse programming language. Indeed, it probably is a way to create such a thing. Most of us are not writing programming languages, let alone very terse ones. I am not entirely sure it is optimal for that use either. The triply nested loop might be a bit excessive. Of course scrum is, in theory, very flexible. One could have a 'definition of done' that includes the design of at least two alternative solutions, benchmarks for all of these and more stuff like that....
Re: The Forth Methodology of Charles Moore (2001)
#8you can write "UNTIL" in bold capital letters, but your boss or customer can equally write "right now" in bold capital letters. worse, they can hold on to your paycheck or give it to somebody else.
If you read the bio of Charles Moore [1], you will see for yourself that he is well aware of business constrains. Among other things he co-funded Forth, Inc. (which is still alive, as you can see) and was a Forth freelancer. I grant you in advance the point that it was 30-50 years ago and that the situation can be different today. It is however still worth following this methodology when you can afford. There's often a life after deadlines.
But that's actually not something specific to Forth. Every programmer does that to some degree. Sometimes it is included in big and small so-called "refactoring" steps. Moreover, one could say at first glance that the core of this methodology is the well known "if you spend more time on design you will spend less time on code".
The other thing is that, indeed, in this context it is less of a problem to throw away what you've done because of step 1-2. The phrasing is a bit too abstract; Perhaps clearer is what he said in an earlier interview: "Don't anticipate, solve the problem you've got." [2].
This piece of advice is so beneficial that it is almost a motto for me. It is also harder to do that one may think, because it is so easy to FUD oneself with "what if" and "what about" and sometimes you have to fight against your own hubris too (e.g. "I'll build something powerful"). So it requires some training; after all these years programming in Forth I still catch myself anticipating (e.g. "I think it could be useful to have that").
[1] https://www.forth.com/resources/forth-programming-language
[2] https://www.ultratechnology.com/1xforth.htm : Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.
Re: The Forth Methodology of Charles Moore (2001)
#9Most of Moore's Forth methodology comes down to extracting the optimal solution by:
1. Iterating your understanding until you have the deep core of the problem.
2. Experimenting with possible solutions until you find the best approach.
3. Not coding the final production code until the first two steps are met. (Maybe this is a variant of Fred Brook's "Plan to Throw One Away"? see https://course.ccs.neu.edu/cs5500f14/Notes/Prototyping1/planToThrowOneAway.html)
4. Writing code and documentation that is simple, direct, and easy-to-understand.Re: The Forth Methodology of Charles Moore (2001)
#10Most of Moore's Forth methodology comes down to extracting the optimal solution by: 1. Iterating your understanding until you have the deep core of the problem. 2. Experimenting with possible solutions until you find the best approach. 3. Not coding the final production code until the first two steps are met. (Maybe this is a variant of Fred Brook's "Plan to Throw One Away"? see https://course.ccs.neu.edu/cs5500f14/N…
someone online mentioned(i'll link if i find it again) a quote similar to this, something like that:
- go crazy in understanding the problem
- break it in small words
- repeat above steps until it's easy to write in forth