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

21–30 of 65 posts

Re: The Forth Methodology of Charles Moore (2001)

#21

Post by coliveira »

nine_k wrote: post #13
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…

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.

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.

Re: The Forth Methodology of Charles Moore (2001)

#22

Post by coliveira »

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.

Re: The Forth Methodology of Charles Moore (2001)

#25

Post by saulpw »

kstrauser wrote: post #24

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?

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.

Re: The Forth Methodology of Charles Moore (2001)

#26

Post by bitwize »

coliveira wrote: post #21
nine_k wrote: post #13

Earlier quoted context omitted.

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.

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

Re: The Forth Methodology of Charles Moore (2001)

#27

Post by oersted »

saulpw wrote: post #25
kstrauser wrote: post #24

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?

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…

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

Re: The Forth Methodology of Charles Moore (2001)

#28

Post by [deleted] »

saulpw wrote: post #25
kstrauser wrote: post #24

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?

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…

[deleted]

Re: The Forth Methodology of Charles Moore (2001)

#29

Post by floxy »

kstrauser wrote: post #24

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?

Something like:

https://yosefk.com/blog/my-history-with-forth-stack-machines...

...might recalibrate your expectations.

Re: The Forth Methodology of Charles Moore (2001)

#30

Post by diffxx »

oersted wrote: post #27
saulpw wrote: post #25

Earlier quoted context omitted.

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…

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

Post reply on HN