4 ms·

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 make

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 2y ago
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 2y ago
  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 2y ago
    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.
    - oersted 2y ago
      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.
  - deterministic 2y ago
    You can use tailored DSLs in any language. Not just Lisp. I do it all the time. It is a huge productivity boost. An example is a biz application I recently delivered to a large international customer. More than 90% of the C++ and Typescript code was auto generated from a simple declarative spec. The only custom code was the customer specific biz logic and custom interface logic to external tools. Yes it isn’t generated with macros Lisp style but it works equally well.
- deleted 2y ago
  [deleted]
floxy 2y ago
Something like: https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines... ...might recalibrate your expectations.
db48x 2y ago
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 2y ago
  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.
- deterministic 2y ago
  I hear the “marketing” argument all the time and I don’t buy it. Lisp (for example) has been promoted heavily for 60+ years by generation after generation of enthusiasts. And it hasn’t convinced the mainstream to switch. And meanwhile C and C++ code runs the world. Without any commercial marketing behind it.
  - db48x 2y ago
    Wow, ok. No commercial marketing? How about conferences? I’m sure none of the corporate sponsors have any marketing reason to contribute. <https://isocpp.org/wiki/faq/conferences-worldwide https://isocpp.org/wiki/faq/conferences-worldwide>, <https://javaconferences.org/ https://javaconferences.org/> Or magazines? Surely they were entirely supported by their subscribers, not their advertisers. <https://en.wikipedia.org/wiki/Category:Computer_magazines_published_in_the_United_States https://en.wikipedia.org/wiki/Category:Computer_magazines_pu...>, <https://en.wikipedia.org/wiki/Category:Defunct_computer_magazines_published_in_the_United_States https://en.wikipedia.org/wiki/Category:Defunct_computer_maga...>
coliveira 2y ago
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.
deterministic 2y ago
I know this is hard to accept for people enthusiastic about a language X (Forth/Lisp/Haskell/..) that hasn’t entered the mainstream despite years of salesmanship and promoting from X people: There is a reason why it hasn’t happened (obviously). It might not be for reasons X people agree with or value. However those reasons are important and valuable enough for non-X enthusiasts to bounce off X. And to make matters worse, the typical reaction from X enthusiasts is to then claim that non-X developers are not smart enough to “get it” or that somehow people using X are smarter than non-X developers. Claims that are so obviously ridiculous that it makes non-X people bounce even harder off the X community. I personally love learning new languages. And have written compilers for a few of my own. However that’s all fun and games. Not something I would use in anger for my day job where I have to work in a team and deliver highly complex software for large corporation that relies on my code to run their business. However having said all that, Forth is really cool and fun to play with. I love minimum languages! Lisp is another fun one. Or the lambda calculus. All great fun languages!

saulpw 2y ago

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 2y ago
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 2y ago
  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.
  - oersted 2y ago
    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.
- deterministic 2y ago
  You can use tailored DSLs in any language. Not just Lisp. I do it all the time. It is a huge productivity boost. An example is a biz application I recently delivered to a large international customer. More than 90% of the C++ and Typescript code was auto generated from a simple declarative spec. The only custom code was the customer specific biz logic and custom interface logic to external tools. Yes it isn’t generated with macros Lisp style but it works equally well.
deleted 2y ago
[deleted]

floxy 2y ago

Something like: https://yosefk.com/blog/my-history-with-forth-stack-machines.html https://yosefk.com/blog/my-history-with-forth-stack-machines... ...might recalibrate your expectations.

db48x 2y ago

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 2y ago
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.
deterministic 2y ago
I hear the “marketing” argument all the time and I don’t buy it. Lisp (for example) has been promoted heavily for 60+ years by generation after generation of enthusiasts. And it hasn’t convinced the mainstream to switch. And meanwhile C and C++ code runs the world. Without any commercial marketing behind it.
- db48x 2y ago
  Wow, ok. No commercial marketing? How about conferences? I’m sure none of the corporate sponsors have any marketing reason to contribute. <https://isocpp.org/wiki/faq/conferences-worldwide https://isocpp.org/wiki/faq/conferences-worldwide>, <https://javaconferences.org/ https://javaconferences.org/> Or magazines? Surely they were entirely supported by their subscribers, not their advertisers. <https://en.wikipedia.org/wiki/Category:Computer_magazines_published_in_the_United_States https://en.wikipedia.org/wiki/Category:Computer_magazines_pu...>, <https://en.wikipedia.org/wiki/Category:Defunct_computer_magazines_published_in_the_United_States https://en.wikipedia.org/wiki/Category:Defunct_computer_maga...>

coliveira 2y ago

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.

deterministic 2y ago

I know this is hard to accept for people enthusiastic about a language X (Forth/Lisp/Haskell/..) that hasn’t entered the mainstream despite years of salesmanship and promoting from X people: There is a reason why it hasn’t happened (obviously). It might not be for reasons X people agree with or value. However those reasons are important and valuable enough for non-X enthusiasts to bounce off X. And to make matters worse, the typical reaction from X enthusiasts is to then claim that non-X developers are not smart enough to “get it” or that somehow people using X are smarter than non-X developers. Claims that are so obviously ridiculous that it makes non-X people bounce even harder off the X community. I personally love learning new languages. And have written compilers for a few of my own. However that’s all fun and games. Not something I would use in anger for my day job where I have to work in a team and deliver highly complex software for large corporation that relies on my code to run their business. However having said all that, Forth is really cool and fun to play with. I love minimum languages! Lisp is another fun one. Or the lambda calculus. All great fun languages!