Thread by @andy_matuschak

In cogsci, Marr suggests 3 levels at which a system (eg vision) can be analyzed: computational (the fundamental problem being solved), algorithmic (how it’s solved, abstractly), and implementation (hardware details).

It’s an interesting taxonomy for analyzing tools for thought!

e.g. for memory systems, three kinds of analysis:

* computational: the dynamics of human memory
* algorithmic: schedules which optimize learning relative to those dynamics
* implementation: details of software implementing those schedules

All important and intertwined!

One thing I like about this approach (same motivation for Marr in cogsci): it pushes you to characterize the computational task your system is performing.

e.g. if you’re designing creativity support systems, you’ll benefit from insights about what creative problem-solving *is*

(And perhaps you can use your system to generate those insights—i.e. to understand the constraints and dynamics of human creativity at an abstract, information processing level…)

Anyway, this is a nice overview of Marr’s levels of analysis, which I find are very difficult to compress to tweet-length discussion… cocosci.princeton.edu/papers/krafftC…

I started to say “it’s awfully hard to do good analysis at the implementation level without understanding the computational level,” but that’s only sort of true. People often have intuitive understandings of the computational level that are plenty good enough.

Like I expect the people making Figma do not have a strong computational conception of the problem they are solving (fun to think about!) but they have intuitions (eg find the “best" arrangement of elements given details of hierarchy…) & that’s enough to make good impl progress.