3 ms·
Most 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 pr
by thesuperbigfrog 2y ago
Most 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.
- agumonkey 2y agosomeone 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
- sitkack 2y agoCharles Moore definitely believes in modifying the original problem so that it fits forth while he modifies forth to fit the problem. I have used a similar approach when I needed to get a PoC out in 6 weeks, we made it, but not without drastically modifying "the spec". In one instance the PM wanted continuous queries over geospatial data, millions of points and arbitrary locations along with a time dimension. I changed the spec to use 3 buckets, near, medium and far. That feature took 2 hours, the continuous query itself would have taken weeks or longer. Successful projects have a malleability to them.
- agumonkey 2y ago> Charles Moore definitely believes in modifying the original problem so that it fits forth while he modifies forth to fit the problem. This philosophy is often described by 80s lispers. They're not top-down nor bottom-up.. they lie in the middle. Trying to make a comfy intermediate layer so they can experiment various upper layers to fit the problem and adjust if rapidly in case of changes. Similar to IR in compilers I guess.
- nine_k 2y agoThis 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.
- coliveira 2y agoWhat you're saying is completely right after you realize that the problem with business software is not the software side, it is the illogical requirements of businesses. The issue is that different parts of the businesses throw requirements that are contradictory and generate unmaintainable systems in the long run. Thus the need to constantly rewrite and patch. In an "enterprise" setting, you don't want a solution oriented language, you want a language that can be twisted to produce whatever the business wants in a short period of time.
- bitwize 2y agoThe problem with business requirements is that there are no systems analysts anymore; that work has largely been given to programmers. A systems analyst could determine what information each part of the business needs and what information it can provide to whom. With that information in hand, designing an information system becomes a relatively straightforward process; programming it even more so. The way we do things today is basically guesswork. Which suits programmers just fine, as it lets them write a lot of code. But that's not the best of all possible worlds, only the default world.
- coliveira 2y agoEverything that involves planning and long term thinking has been eliminated from modern businesses, under the guise of "fast iteration", "just-in-time", or whatever new name they find. It's not a software-only phenomenon.
- exe34 2y agothe problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users, and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.