Thinking like a programmer Everyday Without Being a Programmer, Issue 1

Drawers versus Functions

Places to put things versus when-you-need-it-dispensers

Programming in the age of C and Assembly

Back in the day, programming was all about making hurdling-devices to run their course down a narrow track. Like a rubber-band powered mini-car, programmers would set up their intricate devices on a contrived track to skip and hop the hurdles and achieve some side-effect.
Being able to read code 6-8 months down the line was less important than cranking out that last 10-20% of efficiency on large and small devices. Nice for speed and efficiency and gloating, creating cryptic and enigmatic loops and register allocations might rest nicely on the ego and its historical assuredness. Need a value? Let's put it in a drawer [a register]. Need to modify that value? Let's run an operation on it and store that new result in a new drawer. Uh oh. We're out of drawers. In the age of limitation, where drawers were costly additions to physical hardware and operations had to be optimized because computation cycles were scarce, it made sense to optimize the living daylights out of all sorts of code, resulting in abstract and obscure code that was great as long as it never needed to be optimized again.

However, in the modern era, it is unclear how long the same brain will be in charge of the same project. Oftentimes, we are modifying code left to us by the coding gods of yore, and we are ourselves culpable for what we leave to progeny, the legacy maintainers of the future, who may look upon our design decisions with joy or dismay.

Places to put things

Drawers and Registers are synonyms here. It's a box where something goes. If I have one person in one house (like in The Sims) then they know where their shaving tools are, where their pants are, where their toothbrush is. But if we have two people living in one house, suddenly having one drawer for pants can become trouser trouble. Person A might place the pants in Drawer A, and Person B might place their pants in Drawer B. As long as we have strict rules about what goes where we have harmony, but as soon as there is a violation of rules we have a race-condition, we must introduce semaphores, stoplights, go signals, mutex locks, and a whole world of stoplights, stop signs, green lights and causeways. We went from letting the students trample the grass as they wished to forcing them to use sidewalked paths on their way to and from each class.

Wright University in Ohio### Trample the Grass

I don't know anything about Wright University except for this one excellent anecdote. When the university campus was built there were only buildings -- no paths between them. The architects of the university let the students trample the grass as they saw fit, and only when natural paths emerged did the architects take the step to lay down sidewalk and cement connecting the buildings in a way already derived by human nature. It is this foresight that lets efficiency and comfort arise together.

Stay off the Grass

Why bother forcing people to "stay off the grass" when the grass is clearly the obstacle? You ought be thanking me for "taking the road less traveled" and "making all the difference" because clearly there ought to be a path where some genius thought there ought be grass.

When-you-need-it-dispensers### Chutes and Ladders

Chutes and ladders is a game for kids, with a board that has a simple graph structure, but due to the fun in dragging a piece along a drawing of a slide, kids can get great joy from this simple game. You climb ladders and you take slides to get to different board locations. It's quite illustrative of how computer architecture in the age of assembly worked. Not to say that age is over with, as it is quite alive in our pocket devices. You have a loop? You have a function call? You need to invoke a new stack frame? Take a ladder climb, slide down a chute. Congrats, we're in a new game-state.

Manifest-as-Needed

With greater memory comes greater freedom. With two grains of sand, I am limited in my ability to produce creative art. But with a beach of sand suddenly I am able to make everything from small castles to huge mansions. Temporary as they are, they are impressive structures. When silicon is arranged compellingly enough to afford the VM or a virtual instance of an operating system, we are operating on the level of a beach rather than on the level of grains in limited number.

One amazing part of functional programming is the lazy sequence. In theory, a lazy sequence spans an infinite range, but we need not evaluate all infinite set objects up-front. Nay, we can invoke the next object as necessary, and still work our way slowly and conceptually towards "infinity" without violating our hardware limitations and without forsaking our mathematically sound principles of approach.

When-you-need-it-dispensers

So I like to say, rather than using drawers to store things, create a "when-you-need-it-dispenser." In my ideal mansion for Sims in The Sims, they would never have a closet, just a device that could manifest the exact outfit they need, and it would manifest it in such a way that as they outstretched their arm it was already oriented properly to make it up their arm and cast their sleeve. Imagine the super hero whose super power is simply "have it when you need it." The bus magically appears as they reach the stop, the materials to repair the wheel arrive as the wheel hits a large rock and pops. The road is repaired as the bus departs, the workmen arriving perfectly in synchrony with the needs of the situation.

One of my friends who works at GitHub shared a note online one day, "The tighter the feedback loop, the faster the growth." I like this quote, I think it starts approaching this idea of instant connection and synchronous achievement. Our programs ought not be hurdlers catapulting themselves down the narrow contrived track and runway of perplexity, but striving to create a just-in-the-knick-of-time experiences (JITKOT) -- give your teacher a napkin as s/he needs to wipe their lips from the pizza, meet their outstretched arm with kindness and a smile and exactly what they need when they need it to proceed.

Proceed with Precision

To lock in and synchronize with your mates takes but two things: kindness and eye contact. The more we can be of service to each other, by producing easy-to-maintain and easy-to-read code for the legacy code maintainers of the future ("historians of tomorrow"), or by anticipating the needs of those around us before they become manifest ties and throttle-points of necessity and pause, the wavier our experience becomes. Build a bridge, help people cross, help people connect. Become the bridge, and efficiency is yours.