[HN Gopher] The Forth Methodology of Charles Moore (2001)
___________________________________________________________________
The Forth Methodology of Charles Moore (2001)
Author : todsacerdoti
Score : 79 points
Date : 2024-07-12 08:45 UTC (14 hours ago)
(HTM) web link (www.ultratechnology.com)
(TXT) w3m dump (www.ultratechnology.com)
| exe34 wrote:
| you 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.
| smitty1e wrote:
| That is: there are more dimensions to real-world solutions than
| purely technical.
| kragen wrote:
| that's jeff's main point here
| smitty1e wrote:
| And yet we watch organizations overlook the fullness of the
| problem on essentially a daily basis.
| exe34 wrote:
| muh shareholder value
| kragen wrote:
| 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());
|
| is written in forth as begin x y z until
|
| and that is what the all-caps untils in this text refer to:
| three nested loops
|
| 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
| astrobe_ wrote:
| 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._
| zelphirkalt wrote:
| 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.
| astrobe_ wrote:
| > To simply spit out some code and without further thought
| accept the first barely working version of it
|
| That's not exactly what TFA describes, though.
|
| > 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
|
| Maybe. Problem is, how do you know when you or someone else
| has enough experience to make those calls? I guess the only
| way is to try and try again. But if you go that route, you
| should really keep the score, that is, note down when you
| made a call and check later if you were right or wrong.
| It's easy to trick oneself though because the future is
| virtually infinite, so a decision to make e.g. something
| more reusable at "this little extra cost" can be
| indefinitely neither right nor wrong.
| coldcode wrote:
| It's a nice philosophy, but good luck doing this in a strict
| Scrum process.
| cjfd wrote:
| 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....
| thesuperbigfrog wrote:
| 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 wrote:
| 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
| sitkack wrote:
| Charles 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.
| nine_k wrote:
| 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.
| coliveira wrote:
| What 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 wrote:
| The 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 wrote:
| Everything 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.
| sieste wrote:
| > 3. Carefully construct a well thought out solution.
|
| I think he might be on to something here ...
| rhelz wrote:
| His 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.
| hobs wrote:
| 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.
| exe34 wrote:
| > multiply this estimate by three
|
| https://en.wikipedia.org/wiki/Hofstadter%27s_law
| fractallyte wrote:
| Compare 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)...
| coliveira wrote:
| The main weakness of Forth is that modern programming is
| basically connecting pieces of APIs from different systems. This
| is true at the OS level, and much more so at the distributed
| level (web). So you're stuck with languages that help with this
| type of interfacing, such as Python and Java, while languages
| that excel in expressibility and logical development like Forth
| provide little benefit to the type of programming we're forced to
| do every day.
| 7thaccount wrote:
| You hit the nail on the head. My ideal world would involve me
| having an extended period of time to research a problem and
| then artfully craft a perfect solution to a problem that is
| beautifully documented.
|
| The world I live in is mostly crappy software products
| involving an infinite mess of APIs glued together and poor
| understanding of the core problem which leads to a huge mess.
| It's worse for the organization too, but good luck arguing
| that.
| stephen_cagle wrote:
| One other weakness that I sometimes wonder about in relation to
| Forth is that modern processors are just much more complicated
| to reason about internally. I am not sure how much efficiency I
| can pull out of them at reasonable cost considering they likely
| have.
|
| 1) Out of order execution 2) Multiple levels of caches 3)
| Branch predictors
|
| Forth has several neat advantages. I think it might be a better
| way to reason about a complex problem. It can be bootstrapped
| on almost any piece of hardware. It can be made to be very
| memory efficient in its runtime.
|
| Those things were true in the past and they are still true now.
| But I do wonder whether the performance part of it is still
| true. Not because Forth has changed, but simply due to the fact
| that modern hardware (+ compilers) can take mediocre code and
| make it into pretty damn performant code.
| coliveira wrote:
| That's correct, but Forth can always be made to run faster
| with enough additional work (a more robust compiler for
| example). That's what commercial Forth still do nowadays.
| interroboink wrote:
| This is why Perl stays attractive to me -- not because of the
| language, but because of CPAN and all that accumulated API
| interfacing knowledge expressed therein.
| kstrauser wrote:
| Everything I read about Forth, and about people's reaction to it,
| sounds amazing.
|
| So why don't we use Forth for everything? Does it have some
| ceiling that makes it not great outside things like making
| firmware?
| saulpw wrote:
| The Forth philosophy generates specialized and incompatible
| systems that are only suitable for one person or small teams.
| For those teams who develop the system (or are willing to put
| significant time into learning a bespoke system), it's amazing
| --a 10x effect. But if you want to share code between teams or
| on the Internet or if you want fungible engineers (or have
| rapid turnover such is common in the industry these days) it's
| not workable.
|
| Also, it's incredibly efficient, which is necessary when you
| have kilobytes of RAM. When you have gigabytes of RAM you can
| cobble together a Rube Goldberg machine without having to think
| too much, and time-to-market wins out over system coherence and
| quality.
| oersted wrote:
| Indeed, any language that encourages you to program by
| building tailored DSLs for every problem domain has the same
| issue (Lisps, Racket...).
|
| It sounds very productive to always be able to express
| solutions with the perfect language for that type of problem.
| But you end up with a myriad bespoke languages that are very
| impractical to document and learn, and are a constant
| friction for collaboration (even with your future self).
| diffxx wrote:
| It can work if you think carefully about module boundaries
| so that the dsls do not leak out of their containing scope.
| Most of the time, dsls are not well bounded and even if
| they are, they are likely to confuse newcomers to the
| codebase. Of course, whether or not dsls are used, every
| program does have custom dsls in the form of functions that
| newcomers also aren't going to understand so it isn't as
| though programs written in a vanilla host language don't
| have many of the same comprehensibility problems as those
| written in a dsl.
|
| That being said, not every piece of code needs to be
| accessible to everyone. Dsls allow you to create a hermetic
| world inside of a programming environment in which certain
| properties always hold, even if the environment does not
| guarantee these things for you. Programs written in the
| right dsl can be more productive to write and have much
| lower overall operational costs. But the price is that the
| rules of the dsl are not necessarily the same as the rules
| of the host language and this leads to confusion. For the
| truly ambitious programmer, it can be worth sacrificing
| accessibility to the median coder to build systems that the
| median coder can't even conceive of. Of course your reward
| is to be derided for not expressing the solution in a
| language they can already understand.
|
| Wrt to Forth itself, Chuck Moore has pointed out that Forth
| is a multiplier: it makes good programmers better and bad
| programmers worse. I personally care more about the former
| property and frankly don't want to work with bad
| programmers anyway.
| floxy wrote:
| Something like:
|
| https://yosefk.com/blog/my-history-with-forth-stack-machines...
|
| ...might recalibrate your expectations.
| db48x wrote:
| Marketing. There was a recent article that hit the nail on the
| head. The author was quite prolific within his field, and
| always used Forth. He would be called in as a consultant to do
| a certain kind of work (mostly DSP programming), and could
| adapt his existing Forth code to the new problems. His
| coworkers invariably thought that he was _cheating_ by using
| Forth. They were Real Engineers writing code in a Proper
| systems language like C. Don't you know all of C's advantages?
|
| The fact was that he could run rings around whole teams of C
| programmers. His implementation would be more efficient, more
| reliable, and cheaper to mass produce (lower ram requirements,
| lower power requirements, etc). But he could never stay
| anywhere very long because all the Real Engineers knew that C
| was the Right Language to implement things in. His better
| solutions were seen as aberrations rather than a condemnation
| of their own mediocrity.
|
| That's the power of good marketing. Forth never had an industry
| giant spending billions a year on marketing to convince all of
| the engineers that it was the best language ever. C, C++, and
| Java all did. All the VPs have read articles and attended
| conferences that touted C++ or Java as the best thing ever, but
| they've never even heard of Forth.
| agumonkey wrote:
| I've seen this partly. The influence of mediocre smooth
| talkers is hard to believe. I also believe that non-tech
| social groups are more impressed by large teams rather than
| one or two geniuses. Lastly large companies asking loads of
| money to operate will also have cushions in case of
| problems.. the efficient lone wolf will not.
|
| People with deep non mainstream knowledge should avoid
| mainstream by wide margins and try to assemble in small
| groups of like-minded hackers.
| coliveira wrote:
| The main reason comes from how we were taught to write
| programs. It is the same problem with human languages: if you
| learn to speak English as a kid, you'll hardly have the need to
| learn German. Going from something like Python to Forth is
| similar to learning a foreign language, the way things are
| expressed in Forth are sometimes radically different. So you
| need to relearn to program, which is a painful and expensive
| process for companies. The languages that become successful are
| a direct translation of the first successful programming
| languages like Fortran and C. Everything else is too alien to
| succeed.
| gumby wrote:
| Many of these aphorisms are useful in a non-programming context
| as well.
| coliveira wrote:
| I wonder if a programming methodology could work by: (1) writing
| the solution in Forth and creating a prototype that will be 100%
| thrown away. (2) making sure that it works. (3) re-writing the
| solution in a language that will be accepted by the business
| people. In other words, using Forth as a fast prototype system.
| sitkack wrote:
| I have done that with Python, coded up prototype in Python.
| Wrote tests against service interface. Translated the Python to
| Java in the second version until the tests passed. It actually
| did save us a bunch of time, esp since the front end devs could
| use the Python prototype to do their work.
| mistermann wrote:
| > First consider the options that everyone else would reject
| first, that is where the biggest algorithmic improvement is
| likely to be found.
|
| This is excellent advice for humanity in general.
___________________________________________________________________
(page generated 2024-07-12 23:01 UTC)