thinking about this: complexity has to live somewhere

complexity has to live somewhere—the trick is putting it in the right place. modern cpus are incredibly complex: multiple tiers of caching, speculative execution, etc. none of which you ever think about when building a web app, which in turn has its own kind of complexity.

a cpu runs on top of some very complex and speculative physics that we only incompletely understand: neutrino oscillations, quark color confinement... luckily you also don’t need to understand any of that when building a web app. 😀

my 2¢ is, put as much complexity as is necessary inside of a microservice, framework or library—as long as the team that maintains it can understand it. but make its interface as simple as possible, so that the team at large can effectively make use of it.

it’s kind of the opposite of worse is better, but i think the use case is different.

#software #complexity

i came across supertasks while reading “bangs crunches whimpers and shrieks” by john earman.

a supertask is an infinite sequence of tasks that occur within a finite amount of time. how do you fit an infinite number of tasks into a finite interval? assume a one second interval. perform the first  task at time 0.5 seconds, the next at time 0.75 seconds, the next at time 0.875 seconds, and so on—always dividing the remaining time in half. mathematically, you’ll end up with an infinite number of tasks in a one second interval.

zeno's paradox articulates a supertask—the task being to cover half the previous distance at each step. luckily, evidence refutes zeno's assertion that motion is an illusion.

other supertasks are not so easily analyzed. the thomson's lamp puzzle toggles a lamp on or off at each step and asks if the lamp is on or off at the end of the interval. it must be one or the other, right?

imo, a supertask feels a bit like finishing a software project. call it the generalization of the 80/20 rule.

#supertask #software