1. 36

  2. 9

    Interesting thoughts on abstraction. Doesn’t quite mesh with my experience: I really enjoy being able to call up, e.g., the Python standard library, even if I don’t know how their JSON parser works, or I don’t need my hash tables to keep track of insertion order. Most of the time (all of the time?) I don’t need to know in order to solve the problem at hand.

    The analogy that came to my mind is cache misses. With Forth, you write more code from scratch, so almost every function you need is a “cache miss” in the sense that you’re looking for something that doesn’t exist yet. It’s like you don’t even have a cache, and you move consistently but slowly – up to the point where you’ve written everything you need (“the cache has been warmed”), and you have the sensation of everything falling into place. Contrast with a language that has lots of abstractions: you have more “cache hits” because when you need some functionality, you can usually find a library that meets your needs, and you move faster as a result. But the tradeoff is that the occasional cache miss is more painful: you think library Foo meets your needs, but there’s some corner case it handles badly, and you won’t discover that until it burns you. Maybe you never even discover why – all you know is things are suddenly on fire all the time.

    It’s not a perfect analogy, but it gave me a way to think about the issue. As is often the case, the “real” answer is likely at neither extreme.

    People in the upper echelons of Forth programming (like Chuck Moore) design their own hardware and make sure that the interfaces are easy to use from Forth, but that’s not for everybody

    That’s a bit of an understatement.

    1. 4

      I wonder how you would feel with a language like Factor. It’s a descendants of Forth but has a massive standard library, to the point where the community just bundles new libraries in instead of releasing separate packages.

    2. 5

      whether you need all this heavy optimization work is an open question: most of your code runs seldom (or never), particularly in the bloatware that is produced nowadays, and the search for runtime performance has taken on a somewhat religious meaning. We try to eke out every cycle of speed, yet never worry about the huge amounts of code involved, which increase memory traffic and cache misses.

      Religious or not, I feel that our search for runtime performance is failing miserably. Many of our programs are slow. They take forever to boot, eat up a crazy amount of memory, and often the only meaningful difference from what we had 20 years ago is in the eye candy. I like my eye candy, but it rarely justifies the slowdowns that come with it.

      My feeling is that in general, we aren’t serious about performance. We pay lip service to it, but we rarely ascertain where we actually need it. In the worst cases, we get a false sense of having done what we could, all while stuck in a freakishly high local minimum.

      This reminds me of Casey Muratori’s philosophies of optimisations:

      • Optimisation: where you measure stuff and then make it leaner or faster. (Only use it when you really need it.)
      • Non-pessimisation: where you simplify what the CPU has to do, and avoid unneeded work. (Should be used pretty much all the time.)
      • Fake optimisation: where you rely on heuristics outside of their original domain. (Avoid. Obviously.)

      I get the feeling that Forth leans heavily towards non-pessimisation.

      1. 4

        This article makes me about https://prog21.dadgum.com/38.html, about how Forth is among a set of puzzle languages, or https://prog21.dadgum.com/33.html about how writing Forth can be akin to Sudoku.

        I know for me, I’m the sort of person who, when it comes to programming outside of work, wants to reach an end-point without having to implement much of the standard things along the way. And so, for me, forth tends to be a bit too low-level. But it does have a certain intellectual appeal.

        1. 2

          This helped me to understand the mindset of Forth programmers. @akkartik’s link https://yosefk.com/blog/my-history-with-forth-stack-machines.html is excellent if you want to explore further.

          1. 1

            The Forth mindset reminds me of the APL / J / K mindset. Chuck Moore reminds me of Arthur Whitney. Some common elements:

            • An emphasis on compact code.
            • A brutally stripped down language, and a programming culture that de-empthasizes the use of standard libraries in favour of coding everything yourself using language primitives.
            • A style of programming that results in compact code, by reframing the problem and the requirements so that your code is smaller, by eschewing layers of abstractions and coding to the bare metal.

            This mindset can be used when programming in any language. Whitney’s incunabulum, in C, in case you haven’t seen it: https://www.jsoftware.com/ioj/iojATW.htm It’s a complete language interpreter, for a language that is the ancestor of J and K.