Stages of Denial (2020)

(beyondloom.com)

35 points | by pabs3 254 days ago

5 comments

  • msla 251 days 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 251 days 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 250 days 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 250 days 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 251 days 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 250 days ago
        There's comfort in settling for mediocrity. Muddling through at your own pace instead of grasping for the ideal.
    • joelignaatius 251 days ago
      [dead]
  • JadeNB 251 days 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 250 days 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 250 days 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 250 days 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 251 days ago
  • kstrauser 251 days 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 250 days ago
      I'm not sure I believe that's actually the code the maintainers edit.