6 ms·

Programming Forth caused the most massive change in my programming mindset (the LSD of programming languages). Even more so than Lisp. Thinking of the rapid r

by asguy 2y ago

Programming Forth caused the most massive change in my programming mindset (the LSD of programming languages). Even more so than Lisp. Thinking of the rapid rise of the base language to the problem domain (i.e. it's a DSL construction kit) opened my eyes to how to design useful and extensible APIs. https://thinking-forth.sourceforge.net https://thinking-forth.sourceforge.net is worth reading, even if you have no desire to ever program any Forth.

nequo 2y ago
What are your main lessons from Forth for API design? Is it something you could summarize?
- saulpw 2y ago
  They just said it was like the LSD of programming languages. Your question is kind of like "What are your main takeaways from LSD? Can you summarize?" which realllly misses the point.
  - nequo 2y ago
    I don’t think so. There are many ways to describe how a mind altering experience with LSD would change how you relate to yourself and your environment. I am curious how Forth changed parent’s approach to programming.
    - immibis 2y ago
      Probably in a similar way to learning Haskell, assembly, Erlang, data-oriented design, 4k demo programming, or any other thing that is unconventional enough that your normal patterns don't work and you are forced to expand the set of ways you know how to program.
      - nequo 2y ago
        This is both vague and speculative though. Vague because you have made no specific claims that could be evaluated one way or the other. Speculative because you have said nothing about Forth. You cannot make engineering decisions based on "it'll change how you program." There are several concrete examples of turning imperative code into pure monadic code that contains less boilerplate and is less noisy with Haskell's do notation. Exhaustiveness checking, encoding invariants in types, those all have good examples that one can read and agree or disagree with. Surely there are concrete examples that one can give about Forth too?
        skydhash 2y ago
        It's metaphysical. Like learning a foreign language widen your perspective. It's a particular insight you gain about the act of programming that makes you realize that you've been boxing yourself to a very small imperative/oop space. Writing C code feels like writing a rule book, writing java feels like designing a lego set, writing lisp feels like writing proof, writing prolog feels like writing puzzles. Writing forth feels like writing a dictionary, then after that you write a few sentences. They're different feeling, but forth is one of the most flexible as you can go up and down from the most basic units to the high level ones. As another comment has mentioned, you can program forth where the basic units are elements from another language, and construct a dsl/dictionary out of it. Then switch the basic units while retaining your business logic for a faster implementation without a full rewrite.
        immibis 2y ago
        Not just the realization you were boxed into a space, but also knowledge of stuff inside a different box. The more boxes you have the ability to access, the better.
        saulpw 2y ago
        The creator of Forth wrote this: > I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. -- Chuck Moore https://www.ultratechnology.com/moore4th.htm https://www.ultratechnology.com/moore4th.htm You might appreciate other quotes from the above page.
      - 7thaccount 2y ago
        Not OP, but I would only partially agree with that statement. Sure, learning all those things is mind altering. If you only know Java or Python...Haskell is very unusual. However, the Forth experience and reading about legends like Chuck Moore (at least for myself), just gave me this feeling that most of our problems come from software bloat and having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore. Such a system is ironically more efficient from a developer's perspective (at least until you run into weird bugs and edge cases) as developers just basically glue together libraries and only need surface level understanding to get something running. Another option might be to design your own hardware and then a simple forth system on top of that which exactly solves the problem and nothing else. The implementor would have laser level understanding of the design choices. Of course, there are other issues such as how to maintain such a unicorn, even if it is beautiful and elegant. Today, we have lovecraftian horrors with huge swaths of people working together to keep all the abstraction levels working together and hope there aren't any leftpad incidents.
        fuzztester 2y ago
        >having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore s/infinite abstraction levels/Rube Goldberg contraptions/
        7thaccount 2y ago
        Lol. Probably a more apt description.
        immibis 2y ago
        Low level "machine sympathetic" programming is just one type. If you restrict yourself to it, you'll be no better than the programmer who's restricted to any other type. All these abstractions didn't spring out of nowhere - in many cases they make for very flexible software that is cheap to create. Go learn both ends. And the middle. And the weird outliers.
        2y ago
    - sph 2y ago
      You can describe LSD, or a novel programming paradigm, just as well as you can describe Beethoven's 5th symphony in words. The amount of lost bits of information makes the explanation totally worthless, even though you technically can explain it. The point is it's a waste of time. You won't understand LSD, Beethoven or Forth until you have tried them.
  - samatman 2y ago
    Several literary careers have been made on summarizing the main takeaways from LSD.
    - immibis 2y ago
      If several literary careers have been made summarizing it, and it still is not adequately summarized, that proves the point.
    - klyrs 2y ago
      In my experience, the value of a trip isn't what you take away from it; it's the things that you can't take with you. Nobody really wants to see a whole slideshow of your vacation photos; it'll never compare to being there.
      - sph 2y ago
        There is a large contingent of people that claim to know about X because they read a good book on it, which is ludicrous nonsense. Indeed the most unique things of any experience is what you cannot put into words. Language is a very lossy compression algorithm, and some concepts aren't even computable in the first place (i.e feeling and emotions)
        deleted 2y ago
        [deleted]
  - LudwigNagasena 2y ago
    API design is something relatively concrete though. One can provide examples of pre-Forth and post-Forth design.
- diffxx 2y ago
  Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving. Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code. Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model. Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access. To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description. Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."
- asguy 2y ago
  There have been some great responses that cover the gist of it, but to add a couple more mundane specifics: - Build up the thinnest abstraction that lets you express a solution in the problem domain. - Allow the API user to express their intent, and not be focused on mechanics they don't need to understand to get the job done. - Focus on getting the interfaces right before the implementation is perfect. - A clean interface will allow you to make drastic changes to the implementation without the API consumer becoming aware.

by asguy 2y ago

nequo 2y ago

What are your main lessons from Forth for API design? Is it something you could summarize?

saulpw 2y ago
They just said it was like the LSD of programming languages. Your question is kind of like "What are your main takeaways from LSD? Can you summarize?" which realllly misses the point.
- nequo 2y ago
  I don’t think so. There are many ways to describe how a mind altering experience with LSD would change how you relate to yourself and your environment. I am curious how Forth changed parent’s approach to programming.
  - immibis 2y ago
    Probably in a similar way to learning Haskell, assembly, Erlang, data-oriented design, 4k demo programming, or any other thing that is unconventional enough that your normal patterns don't work and you are forced to expand the set of ways you know how to program.
    - nequo 2y ago
      This is both vague and speculative though. Vague because you have made no specific claims that could be evaluated one way or the other. Speculative because you have said nothing about Forth. You cannot make engineering decisions based on "it'll change how you program." There are several concrete examples of turning imperative code into pure monadic code that contains less boilerplate and is less noisy with Haskell's do notation. Exhaustiveness checking, encoding invariants in types, those all have good examples that one can read and agree or disagree with. Surely there are concrete examples that one can give about Forth too?
      - skydhash 2y ago
        It's metaphysical. Like learning a foreign language widen your perspective. It's a particular insight you gain about the act of programming that makes you realize that you've been boxing yourself to a very small imperative/oop space. Writing C code feels like writing a rule book, writing java feels like designing a lego set, writing lisp feels like writing proof, writing prolog feels like writing puzzles. Writing forth feels like writing a dictionary, then after that you write a few sentences. They're different feeling, but forth is one of the most flexible as you can go up and down from the most basic units to the high level ones. As another comment has mentioned, you can program forth where the basic units are elements from another language, and construct a dsl/dictionary out of it. Then switch the basic units while retaining your business logic for a faster implementation without a full rewrite.
        immibis 2y ago
        Not just the realization you were boxed into a space, but also knowledge of stuff inside a different box. The more boxes you have the ability to access, the better.
      - saulpw 2y ago
        The creator of Forth wrote this: > I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. -- Chuck Moore https://www.ultratechnology.com/moore4th.htm https://www.ultratechnology.com/moore4th.htm You might appreciate other quotes from the above page.
    - 7thaccount 2y ago
      Not OP, but I would only partially agree with that statement. Sure, learning all those things is mind altering. If you only know Java or Python...Haskell is very unusual. However, the Forth experience and reading about legends like Chuck Moore (at least for myself), just gave me this feeling that most of our problems come from software bloat and having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore. Such a system is ironically more efficient from a developer's perspective (at least until you run into weird bugs and edge cases) as developers just basically glue together libraries and only need surface level understanding to get something running. Another option might be to design your own hardware and then a simple forth system on top of that which exactly solves the problem and nothing else. The implementor would have laser level understanding of the design choices. Of course, there are other issues such as how to maintain such a unicorn, even if it is beautiful and elegant. Today, we have lovecraftian horrors with huge swaths of people working together to keep all the abstraction levels working together and hope there aren't any leftpad incidents.
      - fuzztester 2y ago
        >having these infinite abstraction levels where nobody ever truly understands what in the world is going on anymore s/infinite abstraction levels/Rube Goldberg contraptions/
        7thaccount 2y ago
        Lol. Probably a more apt description.
      - immibis 2y ago
        Low level "machine sympathetic" programming is just one type. If you restrict yourself to it, you'll be no better than the programmer who's restricted to any other type. All these abstractions didn't spring out of nowhere - in many cases they make for very flexible software that is cheap to create. Go learn both ends. And the middle. And the weird outliers.
        2y ago
  - sph 2y ago
    You can describe LSD, or a novel programming paradigm, just as well as you can describe Beethoven's 5th symphony in words. The amount of lost bits of information makes the explanation totally worthless, even though you technically can explain it. The point is it's a waste of time. You won't understand LSD, Beethoven or Forth until you have tried them.
- samatman 2y ago
  Several literary careers have been made on summarizing the main takeaways from LSD.
  - immibis 2y ago
    If several literary careers have been made summarizing it, and it still is not adequately summarized, that proves the point.
  - klyrs 2y ago
    In my experience, the value of a trip isn't what you take away from it; it's the things that you can't take with you. Nobody really wants to see a whole slideshow of your vacation photos; it'll never compare to being there.
    - sph 2y ago
      There is a large contingent of people that claim to know about X because they read a good book on it, which is ludicrous nonsense. Indeed the most unique things of any experience is what you cannot put into words. Language is a very lossy compression algorithm, and some concepts aren't even computable in the first place (i.e feeling and emotions)
      - deleted 2y ago
        [deleted]
- LudwigNagasena 2y ago
  API design is something relatively concrete though. One can provide examples of pre-Forth and post-Forth design.
diffxx 2y ago
Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving. Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code. Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model. Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access. To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description. Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."
asguy 2y ago
There have been some great responses that cover the gist of it, but to add a couple more mundane specifics: - Build up the thinnest abstraction that lets you express a solution in the problem domain. - Allow the API user to express their intent, and not be focused on mechanics they don't need to understand to get the job done. - Focus on getting the interfaces right before the implementation is perfect. - A clean interface will allow you to make drastic changes to the implementation without the API consumer becoming aware.