> 3. Carefully construct a well thought out solution.
I think he might be on to something here ...
The Forth Methodology of Charles Moore (2001)
11–20 of 65 posts
Re: The Forth Methodology of Charles Moore (2001)
#12[flagged]
Re: The Forth Methodology of Charles Moore (2001)
#13Most 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…
This works well when the problem.stays the same for long enough, and you're not in a particular hurry. Good for radio telescope control (the original application of Forth), good for spacecraft design (some of Moore's CPUs have flown in space). Harder in a typical business setting, alas.
Re: The Forth Methodology of Charles Moore (2001)
#14His methodology has a lot of planning. I'm in general, terrible at planning how long a program will take to be written. But there is one class of programs I am pretty good at: very short, very simple, programs.
Good news is that every problem you'll ever face can be broken down into sub-problems which are easier to solve.
Bad news is planning a software project in that much detail, down to the granularity needed for me to get accurate time estimates, takes as long as actual doing the programming would.
And even at that, there will still be many problems with the plan, because all that time we were not, say, making unit tests, or proto-types large enough to expose problems.
But yet, here he is, and his methodology certainly worked for him. I wonder how much Forth itself contributed to that success, or could he have used any interpreted language.
Any pointers on how to better estimate programming effort would be greatly appreciated.
Re: The Forth Methodology of Charles Moore (2001)
#15[deleted]
Re: The Forth Methodology of Charles Moore (2001)
#16Compare it to the process of the Shuttle Software Group, detailed in the FastCompany article, "They Write the Right Stuff" (https://archive.is/HX7n4)
(Previously discussed many times on HN; the most popular post: https://news.ycombinator.com/item?id=23537530)
To me, the Forth process is more rigorous and less error-prone. It may not be the 'industry standard', but for certain very specialized and intelligent teams (such as the Shuttle Software Group), I'm surprised it hasn't taken off (excuse the pun)...
Re: The Forth Methodology of Charles Moore (2001)
#17His methodology has a lot of planning. I'm in general, terrible at planning how long a program will take to be written. But there is one class of programs I am pretty good at: very short, very simple, programs. Good news is that every problem you'll ever face can be broken down into sub-problems which are easier to solve. Bad news is planning a software project in that much detail, down to the granularity needed for…
Make up a number that sounds good. Check if anyone has done this before in your setting. Multiply this estimate by three. Keep people updated on your progress if you are late.
Re: The Forth Methodology of Charles Moore (2001)
#18you 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…
And yet it is wise to write code in a way that will lend itself well to additions later on. It is bad advice to forgo thinking about making ones code flexible and extensible. To simply spit out some code and without further thought accept the first barely working version of it. This will lead to obstacles, that in businesses will be interpreted as cost of changing something in the future, wgich in turn will lead to decision of simply never making this or that improvement. You will not be given the chance to revise your design later, in many cases, so you better make it work well the first time.
One might not be able to anticipate future requirements, but there are situations, in which the engineer, provided they even get the right idea, can make their code reusable with little to no additional time needed, simply, because they know they they are doing and have experience with the matter. The worst that can happen to a product is, when less experienced engineers think to do well in telling the engineer with the experience, that this can be done in the future, when actually that future never materializes. Whole new directions of products die, because of this. Code might become even more, because of not anticipating things, and having to build workarounds later, because one does not get time to refactor and has feature pressure from management.
It can all be pretty shortsighted and can limit the output that skilled engineers can provide. Bad management is gonna manage badly.
Re: The Forth Methodology of Charles Moore (2001)
#19His methodology has a lot of planning. I'm in general, terrible at planning how long a program will take to be written. But there is one class of programs I am pretty good at: very short, very simple, programs. Good news is that every problem you'll ever face can be broken down into sub-problems which are easier to solve. Bad news is planning a software project in that much detail, down to the granularity needed for…
Make up a number that sounds good. Check if anyone has done this before in your setting. Multiply this estimate by three. Keep people updated on your progress if you are late.
> multiply this estimate by three