Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Forth Methodology of Charles Moore (2001)

ultratechnology.com

Post reply on HN
Print view View original

41–50 of 65 posts

Re: The Forth Methodology of Charles Moore (2001)

#41

Post by sitkack »

agumonkey wrote: post #10
thesuperbigfrog wrote: post #9

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/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

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.

Re: The Forth Methodology of Charles Moore (2001)

#42

Post by sitkack »

coliveira wrote: post #38

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.

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.

Re: The Forth Methodology of Charles Moore (2001)

#43

Post by interroboink »

coliveira wrote: post #22

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 programmi…

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.

Re: The Forth Methodology of Charles Moore (2001)

#44

Post by coliveira »

stephen_cagle wrote: post #40
coliveira wrote: post #22

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 programmi…

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…

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.

Re: The Forth Methodology of Charles Moore (2001)

#45

Post by agumonkey »

sitkack wrote: post #41
agumonkey wrote: post #10

Earlier quoted context omitted.

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

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 chang…

> 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.

Re: The Forth Methodology of Charles Moore (2001)

#46

Post by oersted »

diffxx wrote: post #30
oersted wrote: post #27

Earlier quoted context omitted.

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 futur…

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 w…

To me it is an issue of documentation mainly, smart programmers cannot read minds either. There are standard and effort-efficient ways to document function APIs, whereas DSLs need full user guides. They have complex rules about what are valid expressions and what they do, hard to guess without a thorough explanation, and incompatible with modern dev tooling that makes it easier to quickly to discover how to use an API without much reading or trial-and-error.

I do agree there is room for such approaches and they can have 10x effects in some situations. But more often than not, smart programmers can get wrapped up in the logical beauty of it all, distracted away from the core problem, feeling extremely productive but barely getting anything real done (like Vim can make feel so much faster but you really aren’t when you measure and compare properly).

Creating new languages is useful: config, markup, query… But it is hard and laborious to do well, and usually it is only successful if creating the language is your core goal, rather as a one-off auxiliary part of solving a problem, as languages like Forth or Lisp constantly encourage by their design. And, again, a non-trivial language without a manual is unusable (or it is trivial).

Limits to flexibility can be very useful: they make you focus on solving the problem with the tools you have, rather than making the perfect tools to solve the problem, tools that you will probably never use again because they are too tailored to that one problem.

Re: The Forth Methodology of Charles Moore (2001)

#47

Post by loup-vaillant »

zelphirkalt wrote: post #18
astrobe_ wrote: post #8

Earlier quoted context omitted.

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 d…

> It is bad advice to forgo thinking about making ones code flexible and extensible.

In my experience, the best way to make code flexible and extensible is to make it simple. No hooks, no architecture, no pattern, just the smallest thing that does the job. And failing that, the most modular.

That way, when unforeseen requirements do come your way you can just modify your code. The simpler it is, the easier it will be. And it works for any future requirement, not just the ones you had the experience or luck to foresee.

The flip side though is that simplicity is not straightforward. One does not simply "spit out some [simple] code". Simple code requires time and effort. I would like to be able to just say "forget about extensibility, just make it simple", but it wouldn’t convey the difficulty of making things simple.

Re: The Forth Methodology of Charles Moore (2001)

#48

Post by smitty1e »

exe34 wrote: post #23
smitty1e wrote: post #20

Earlier quoted context omitted.

And yet we watch organizations overlook the fullness of the problem on essentially a daily basis.

muh shareholder value

Sure, but that is purely tactical, getting one to the next quarterly earnings statement.

The strategic question is why going long (or, a better strategic/tactical balance) seems so impossible.

Re: The Forth Methodology of Charles Moore (2001)

#49

Post by kragen »

smitty1e wrote: post #48
exe34 wrote: post #23

Earlier quoted context omitted.

muh shareholder value

Sure, but that is purely tactical, getting one to the next quarterly earnings statement. The strategic question is why going long (or, a better strategic/tactical balance) seems so impossible.

it's easy to convince yourself you're playing the long game when you're just screwing up. even in retrospect, it can be hard to tell if you were making a reasonable bet that happened not to pay off, rather than just a dumb bet—or, if you won, to what extent you were making an unreasonable bet that happened to pay off, rather than a savvy one. multiply this by the inevitable fact that, acting in a complex and unpredictable world, everyone is mostly acting out of profound ignorance

finally, aside from unpredictability, rapid innovation and capital growth implies a high discount rate: any new innovation must compete with the risk-free return on capital. if we assume 5% per year, we must discount a return 20 years in the future by 64% (≈1-1/e)

under these circumstances, it's sensible to focus on short-term gains with a rapid feedback loop, rather than long-term gains which might turn out to be chimerical

Re: The Forth Methodology of Charles Moore (2001)

#50

Post by exe34 »

bitwize wrote: post #26
coliveira wrote: post #21

Earlier quoted context omitted.

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 o…

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 thing…

the 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.
Post reply on HN