What makes code hard to read: Visual patterns of complexity (2023)

Post by stouset » Thu, Mar 13, 2025, 3:34 PM UTC

porridgeraisin wrote: post #366

stouset wrote: post #365

Earlier quoted context omitted.

> What? Golang append()s also periodically grow the slice. If you already know the size of the result (there are no filtering operations), the functional approach can trivially allocate the resulting array to already have the correct capacity. This happens with zero user intervention. IIRC the Rust optimizer basically emits more or less optimal machine code (including SIMD) for most forms of iteration.

We are talking about making an array with unique elements here. You cannot know the correct capacity for that without overallocating. If overallocating is indeed OK for your usecase, then you can do so yourself uniq := make([]MyObject, 0, len(my_objects))

Post by porridgeraisin » Thu, Mar 13, 2025, 5:43 PM UTC

stouset wrote: post #372

porridgeraisin wrote: post #366

Earlier quoted context omitted.

We are talking about making an array with unique elements here. You cannot know the correct capacity for that without overallocating. If overallocating is indeed OK for your usecase, then you can do so yourself uniq := make([]MyObject, 0, len(my_objects))

I was talking more in the general case. Yes, you can always just write more and more and more code to fix these things. Or you could just… not write more code and still get optimal performance.

Post by throwanem » Thu, Mar 13, 2025, 10:06 PM UTC

deadbabe wrote: post #32

You really should try to pack an unbroken thought as a single line of code as much as possible. That’s the idea behind chaining multiple functions together on one line instead of spreading it out over several lines. Eyes go horizontally more naturally than up and down, it fits our vision’s natural aspect ratio. And stop making deep nestings. Making a single function call per line assigning output to a variable each t…

Post by stouset » Thu, Mar 13, 2025, 11:01 PM UTC

porridgeraisin wrote: post #338

stouset wrote: post #282

Earlier quoted context omitted.

> the only difference is whether or not it's hidden behind function calls you can't see and don't have access to. You "can't see and don't have access to" `if`, `range`, or `append` but somehow you don't find this a problem at all. I wonder why not? > You don't really think that functional languages aren't appending things, using temp vars, and using conditional logic behind the scenes, do you? By this metric all lan…

> by this metric False equivalence. You're saying that the statement "both for.. append and .map() executing the _same steps_ in the _same order_ are the same" is equivalent to saying that "two statements being composed of cmp,jmp, etc (in totally different ways) are the same" That is a dishonest argument. > Distinct could sort and look for consecutive, it could use a hashmap People love happy theories like this, but…

    # strings
    uniq = strings.uniq()

    # structs, if they are considered equal based on the
    # field in question (strings are just structs and they
    # implement equality, so of course this is the same)
    uniq = structs.uniq()

    # structs, if you want to unique by some mechanism
    # other than natural equality
    let uniq = structs.uniq(&:id)

    # strings
    let uniq = strings.unique();

    # structs, if they are considered equal based on the
    # field in question (strings are just structs and they
    # implement equality, so of course this is the same)
    let uniq = structs.unique();

    # structs, if you want to unique by some mechanism
    # other than natural equality
    let uniq = structs.unique_by(|s| s.id);

Post by cstrahan » Fri, Mar 14, 2025, 7:48 PM UTC

jghn wrote: post #343

atoav wrote: post #316

Earlier quoted context omitted.

To me the functional style is much more easy to parse as well. Maybe the lesson is that familiarity can be highly subjective. I for example prefer a well chosen one-liner list comprehension in python over a loop with temporary variables and nested if statements most of the time. That is because usually people who use the list comprehension do not program it with side effects, so I know this block of code, once unders…

> Maybe the lesson is that familiarity can be highly subjective. Over the years I've come to firmly believe that readability is highly subjective. And familiarity is a key contributor to that, but not the only one. There are other factors that I've found highly correlate with various personality traits and other preferences. In other words, people shouldn't make claims that one pattern is objectively more readable th…

  // Call a function.
  // Function call syntax isn't very visible (only a couple parens tacked onto an identifier);
  // this is a major win for readability.
  function callFunction(func, ...args) {
    return func(...args);
  }
  
  // Perform math.
  // Math symbols are arcane and confusing, so this makes it much more clear.
  // I'm trying to program here, not transmute lead into gold!
  function doMath(left, op, right) {
    const OPS = {
      "less than or equal to": (l, r) => l  l - r,
    };
    // TODO: add support for other operators.
  
    return callFunction(OPS[op], left, right));
  }
  
  const MEMO_TABLE = {}
  
  function fibonacci(n) {
    if (callFunction(doMath, n, "less than or equal to", 1)) {
      const result = n;
      // Memoization makes this fibonacci implementation go brrrrrrrrr!
      MEMO_TABLE[n] = result;
      return result;
    } else {
      const result = callFunction(fibonacci, callFunction(doMath, n, "minus", 1)) + callFunction(fibonacci, callFunction(doMath, n, "minus", 2));
      // Memoization makes this fibonacci implementation go brrrrrrrrr!
      MEMO_TABLE[n] = result;
      return result;
    }
  }

  function fibonacci(n) {
    if (n