Abstraction

Thoughts/notes from reading http://worrydream.com/LadderOfAbstraction/

  • realtime makes sense for things that need to be watched in realtime (like animation)
    • but sometimes it makes sense to not be limited by this - when editing movie for example, you don't want to keep watching the entire film in realtime
    • to explore a system you need to be able to control its time
  • the same way we scrub through time we should be able to scrub through variables
    • then, we can abstract over time - draw a path of what something will look like, and change the variables to see the path change, without having to scrub through it
    • then, we can then abstract over time and parameter - drawing all possible behaviours of the algorithm

      the purpose of abstraction is to bring out high-level patterns

      We stepped up a level of abstraction to see a high-level pattern, and then stepped down to discover the explanation for that pattern. I believe that this dance is where the deepest insights are born - not at any one level of abstraction, but in the transitions between them. This is why it is crucial that our representations provide both a step up and a step back down.

  • when abstracting, it's ok to omit some details to gain better understanding of the system
  • interaction is important part of abstraction - being able to interact with the visualization (and see other visualizations change) helps us build mental model of the solution space (solving things visually)
    • human brains are good at matching visual patterns, but slow and bad at logical inferences
    • it makes sense to turn those inferences into visual representations so we can reason about them
    • it makes sense to be able to play with them to gain even better understanding of them - static visualization is not enough, interaction with living system combined with visualization is important
  • how this relates to programming:
    • "concrete" representation:
      function f() {
        const t = 100;
        const r = 2;
        const [x, y] = calculate(t, r);
        return [x, y];
      }
    • abstracting over time:
      function f(t) {
        const r = 2;
        const [x, y] = calculate(t, r);
        return [x, y];
      }
    • abstracting over time and rate:
      function f(t, r) {
        const [x, y] = calculate(t, r);
        return [x, y];
      }
    • "stepping down" the ladder when we found interesting r is currying:
      const f_of_2 = t => f(t, 2);
  • interestingly "dialog" is used as a concept for exchanging messages with the OS:

    This same dialogue concept can be found in Haskell 1.0 Stream-based I/O, where type Dialogue = [Response] -> [Request] is the model of interaction with the Operating System. [Response] is a stream (lazy potentially-infinite list, to be more accurate) of messages from the OS, and [Request] is a stream of messages to the OS.

    https://cycle.js.org/dialogue.html#dialogue-abstraction

  • the titles are one step up on the ladder of abstraction
    • this should compound - allowing one to climb up using progressively abstracted concepts
  • Andy Matuschak noticed the same thing, calls notes "APIs":

    When Evergreen notes are factored and titled well, those titles become an abstraction for the note itself. The entire note's ideas can then be referenced using that handle. In fact, this property itself functions as a kind of litmus: as you develops ideas in notes over time and improve the "APIs," you’ll be able to write individual notes which abstract over increasingly large subtrees

    https://notes.andymatuschak.org/z3XP5GRmd9z1D2qCE7pxUvbeSVeQuMiqz9x1C

    • another point for the API metaphor is that one can combine APIs to build complex functionalities - same as combining different thoughts should create new (more complex?) thoughts
  • computer is better at simulating (infinite) possibilities (ladders of abstraction) than our mind

Another issue grows out of the way that nodes are connected together through global naming. This makes it hard to create reusable pieces of code, and the user is forced to create unnecessary abstractions, like:

I believe that writing code in vertical slices on some form of canvas has a lot of benefits, we just don't have the proper interactions and abstractions discovered yet.

Szymon Kaliski © 2020
mailtwittergithubwebring