Create and share images of your source code

Was going to suggest this. Make it take up more space on your screen, that's more pixels in the same pic. You might need to do that anyway, if you're on an unusually low (nowadays) resolution: Otherwise the whole pic will be too small to make stuff out on high-res screens.

Ah yes. I'll do that right after I download more RAM.

...

It's already maxed out.

My editor looks nothing like that

I don't see much difference from screenshotting particular area of an editor.

Yup, true, I was thinking only pic.

3 function declarations in a single line already broke my ability to parse the first line :) It's not the first time that happens to me, so I suspect that it's simply a matter that my mental push-pop stack for comprehending tightly nested code layers has a depth of just 1, or maybe 2 after a coffee...

I'd reject all 3 of these in code review. `pluckDeep` and `unfold` are basically unreadable and don't make sense without comments ("go"? this is javascript!). "Pluck deep" sounds mildly disgusting and "unfold" I guess has some analogy to folding but I couldn't tell you what it is. `compose` gets a pass because function composition is a widespread concept and the argument is `fns`, which suggests that it is indeed function composition.

You should write comments anyway, of course, but you shouldn't also punish the reader by forcing them to break out a notebook and/or reformat the code just to make it make sense. The alternating `=` and `=>` is ugly and unnecessarily difficult to follow visually. And the lines in the first two functions are too long, like writing a long forum post in one big paragraph.

Here's what I'd rather see, leaving out the mandatory JSDoc comments (caveat: JS is not my main language):

    const getPropPath = (keyPath) =>
      (obj) => {
        return keyPath.split('.').reduce(
          (prevResult, nextKey) => prevResult[nextKey],
          obj,
        )
      }

    const compose = (...funcs) =>
      (x) => {
        return funcs.reduce(
          (prevResult, nextFunc) => nextFunc(prevResult),
          x,
        )
      }

    const unfold = (func, startArg) => {
      const unfoldAux = (func, currArg, accum) => {
        const result = func(currArg)
        if (result) {
          const nextArg = result[1]
          const nextAccum = accum.concat([result[0]])
          return unfoldAux(func, nextArg, nextAccum)
        } else {
          return accum
        }
      }
      return unfoldAux(func, startArg, [])
    }

Note especially how the mostly-identical structures of the first two functions is now visually obvious, whereas before it was obfuscated. Yes, it has more words than before, but it also limits the syntax to one `=>` per line and breaks up the needlessly dense use of the conditional operator in `unfold`. It's less visually noisy specifically because we added structure.

The original version might feel elegant and efficient to some people, but to me they look like someone else's shorthand scribbles. If I am writing something for other people to read, I am going to take the time to structure it for the benefit of the reader.

That said, I don't think I've ever needed a function like `unfold` (state machine? parsing?) in a Javascript program, so I'd place extra priority on making sure the doc comment explained what it's used for, ideally with a self-contained and easy-to-understand example.

You could also rewrite `unfoldAux` to remove the explicit `func` parameter and get it from the enclosing scope; that would be fine too IMO. That's a matter of taste, depending on how much you like closures.

"But wait! It would be just as terse in any real functional programming language! You're just a bad functional programmer!"

Yeah, I probably am a bad functional programmer. But here's how I'd write `unfold` in OCaml:

    let unfold func start_value = 
      let rec unfold_aux func curr_arg accumulator =
        match func curr_arg with
          | None -> accumulator
          | Some (result, next_arg) -> unfold_aux func next_arg (accumulator @ [result])
      in unfold_aux func start_value []

Obviously this is inefficient because `@` requires a linear scan over the data, so maybe it should be written with cons-and-reverse.

But I'd argue that the OCaml version has more or less the same structure and syntactical clarity as the Javascript version, but with the ability to take advantage of pattern matching (and taking a bit of liberty in narrowing down the opaquely truthy-or-not return value to a `None`).

As a bonus, here's a Python implementation, which uses the new structural pattern matching and looks quite a bit like the OCaml version:

    def unfold(func, start_value):
        def unfold_aux(func, curr_arg, accumulator):
            match func(curr_arg):
                case None:
                    return accumulator
                case (result, next_arg):
                    return unfold_aux(func, next_arg, accumulator + [result])
        return unfold_aux(func, start_value, [])

Of course, in Python nowadays I'd encourage adding type annotations, but that's another story.