Stages of Denial (2020)

(beyondloom.com)

35 points | by pabs3 8 months ago ago

15 comments

  • msla 8 months ago

    My only "denial" when encountering high-church array languages is to deny them the precious brain space required to memorize their line noise syntax in order to be able to read them without a high ratio of comments to code.

    They're (poorly) aping mathematical notation without the properties that give actual notations their power to augment thought using symbolic manipulation, but the people writing code in such languages don't see the need to write like mathematicians; to wit, they don't write mostly in English and save their code snippets for apposite moments when they would illuminate as opposed to obscure. Haskell programmers at least have the taste to use names in their code.

    • 082349872349872 8 months ago

      > don't see the need to write like mathematicians

      Counterexample: https://dl.acm.org/doi/pdf/10.1145/1283920.1283935 (the 1979 Turing Award Lecture)

      Counterexample: https://dfns.dyalog.com/max_impln.htm

    • mhuffman 8 months ago

      >They're (poorly) aping mathematical notation without the properties that give actual notations their power to augment thought using symbolic manipulation

      Yeah, I'm not sure I agree with that. Both of these are some of the most eye-popping books I have ever read related to math and computing [0] [1] (note, both pdf files) Both are well-written (by the guy that created both APL and J) in extremely approachable language and the introduction of J into the mix is almost obvious compared to doing some of the common operations in any other non-array language. These two documents and Joe Armstrong's PhD thesis were ones that really made me "think different" about programming.

      [0]https://www.jsoftware.com/books/pdf/arithmetic.pdf

      [1]https://www.jsoftware.com/books/pdf/calculus.pdf

      • msla 8 months ago

        The whole point of mathematical notation is to ease the cognitive burden by making certain things more automatic via symbol-shuffling: We don't need to think too hard about solving an algebra problem because we can shuffle symbols around and be assured that the result is valid. I've never seen APL or any other array language used that way, even though it's the only thing that could possibly justify their pathological terseness.

    • mikrl 8 months ago

      Most programming languages exist just because devs would rather write 1000 lines of spaghetti than see 7 ‘)’s at the end of a 100 line lisp program.

      /s

      • sdwr 8 months ago

        There's comfort in settling for mediocrity. Muddling through at your own pace instead of grasping for the ideal.

    • joelignaatius 8 months ago

      [dead]

  • JadeNB 8 months ago

    Isn't the loop

        let max = list[0];
        for (let i = 0; i < list.length; i++) {
         max = Math.max(list[i], max);
        }
    
    at the end just implementing the variadic `Math.max()` of JavaScript by pretending that it's binary? (I bring up JavaScript because the text seems to indicate that's the language in which the snippets are written: "You suggest an alternative, wincing slightly at the lambda notation you need to avoid running afoul of JavaScript’s variadic Math.max(): ….")
    • geocar 8 months ago

      > Isn't the loop ... at the end just implementing the variadic `Math.max()` of JavaScript by pretending that it's binary?

      I assume you're talking about:

          Math.max.apply(Math,list)
      
      This isn't exactly the same if list=[] (the loop yields undefined; Math.max.apply returns -Infinity), so maybe this is what he is referring to.

      This variadic capability is also really specific to Math.max (and min, and a few other functions), and wasn't in early JavaScript so maybe John just doesn't know.

      But the main point I think is that it's much much longer than this:

          |/list
      • RodgerTheGreat 8 months ago

        There's also "spread application" syntax in JS, like `Math.max(...list)`, but for many years browsers might permit it for small lists while crashing when supplied with large lists; the compatibility tradeoffs and non-obvious behaviors of all these alternatives make the point pretty clearly, I think.

        • geocar 8 months ago

          Hi John. Big lists are a good point. I didn't think of that. Cheers.

              function ta() {
                  window.la = arguments.length;
              }
              for (var i = 1; i < 32; i++) {
                  var list = new Array(1<<i);
                  ta(...list)
              }
          
          
          la is only 65536 in Safari and Chrome; 262144 on Firefox. I have no idea what MSIE does. Using ta.apply(null,list) gives same results.
  • phoe-krk 8 months ago
  • kstrauser 8 months ago

    Step 1: Huh, I wonder what some of those implementations look like?

    Step 2: https://codeberg.org/ngn/k/src/branch/master/a.c

    Step 3: Uh, I think I'm urgently needed elsewhere.

    • msla 8 months ago

      I'm not sure I believe that's actually the code the maintainers edit.

  • 8 months ago
    [deleted]