Many of these aphorisms are useful in a non-programming context as well.
The Forth Methodology of Charles Moore (2001)
31–40 of 65 posts
Re: The Forth Methodology of Charles Moore (2001)
#32Earlier 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…
> 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.
Re: The Forth Methodology of Charles Moore (2001)
#33The 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…
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.
Re: The Forth Methodology of Charles Moore (2001)
#34Everything 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?
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.
Re: The Forth Methodology of Charles Moore (2001)
#35Everything 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?
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 syst…
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.
Re: The Forth Methodology of Charles Moore (2001)
#36Earlier 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…
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.
Re: The Forth Methodology of Charles Moore (2001)
#37Everything 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 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.
Re: The Forth Methodology of Charles Moore (2001)
#38I 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.
Re: The Forth Methodology of Charles Moore (2001)
#39> 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.
Re: The Forth Methodology of Charles Moore (2001)
#40The 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 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.