Closures Are Like Closures

I've been learning JavaScript over the past few months. It's possible, of course, to "learn" a programming language, or anything, by picking up only what you need to get a desired result and then stopping there. For example, I can figure out that putting down:

Math.min(42, 56, 31);

will give me an output of 31: the minimum. I could choose not to care why I need to have "Math" there, or why there's a period, as I've already got what I was looking for.

And, to a certain degree, this kind of thinking can be useful when you're just beginning to learn something. Nothing's more frustrating, in my experience, than feeling like something you want to know is unreachable due to the brick wall of abstractions and jargon you keep slamming into.

That initial momentum gained from immediate results quickly stops being satisfying, though (for me, at least). With JavaScript, I only had to call a few object methods (which I didn't know were object methods yet) before I needed to know what that period was doing there--both to fulfill my own curiosity and dive further into the theory underpinning the commands I was currently just inputting like a monkey.

The aphorism tells us we obviously can't know what we don't know. But I did understand there was no better way to build up false confidence in what little I did actually know than to stay comfortable, ignoring what was the under the hood. So I tried to start looking at the engine, even if it was easier to stay behind the wheel. (Already tired of this bad metaphor…but that's probably for the best! More on that in a minute.)

Which is not to say that JavaScript objects are especially theoretical or complex, but to point out that I, like many people starting out with programming, I think, at first resisted going deeper into the foundational concepts behind the language due to fear of unknowable abstractions.

And, from my perspective, abstractions and theory can be anxiety-inducing because it feels like we're leaving the physical world behind. That may itself sound a bit abstract, but the fear is that we'll encounter, but won't be able to grasp, concepts that have no analog in the physical world, which our bodies inhabit and have inhabited since long before we started tackling abstract things like math and computer science and art.

This fear is why (in part, at least) figures of speech evolved within human language. I'm mostly talking about metaphors and similes and the like here, but if you want to see the gargantuan number of more obscure figures that you probably weren't taught in 7th grade language arts, the Wikipedia entry is (in typical fashion) an okay place to begin overwhelming yourself.

That entry will also tell you about the many uses and modes of figures of speech, but here I'm specifically talking about tropes that use "ordinary" words to convey a more abstract meaning--and in doing so make us more comfortable with the abstraction because we can tie it down to a more simple, usually physical thing we already understand.

To get back to programming, let's talk objects again. The best way, at least initially, I found to approach objects was--surprise--figuratively. JavaScript objects are much like real-world "objects"--they are individuated from other objects, have properties, and are sometimes based on a more generic type of object. When I pick up a rock in my backyard, it's distinct from other rocks; has properties like color, weight, and shape; and I can make a few assumptions about it that I derive from my broader knowledge of what a rock is.

None of that will be a revelation to anyone--in fact, W3Schools uses a comparable car simile right at the top of their guide to Javascript objects--but illustrates that many programming topics, particularly more basic ones like objects, lend themselves to fastest abstract understanding through figurative language. There's something comforting about that.

But what happens when figures of speech can't illuminate even the simplest parts of a concept? Even if harder to explain, is there maybe more potential in a concept that defies figurative language? Those are the questions I've been meandering toward in this post, and ones I've been thinking about a lot recently while exploring a gnarlier JavaScript feature: closures.

Confession: while I understand the basic use cases for closures--much more precise control of variable scope, etc--I haven't had the "click" yet. Or whatever you call it for yourself, but essentially that mysterious and satisfying moment where the concept reveals itself to you. Even if there are parts you don't fully grasp yet, there's a feeling that you've found the core of it and the rest will fall into place with practice and time.

The conceptual "click" often happens for me when I find a particularly insightful figure of speech. But what if there's no complete figure of speech for a concept? I think it's telling that this Stack Overflow question about how closures work has many great answers, but the top one makes the case for just working through well-written examples until the "click" happens. No metaphors. (There are a few metaphors in other answers on that page, but none that I found helpful. I'll admit it's possible I'm just dense.)

The implication of "just work through examples until you get it" is that no figurative language totally explains what closures are and do. The further implication (okay, speculating now, but roll with it) is that closures actually draw power and flexibility from defying simple linguistic comparisons with things we already understand, and so are innovative--they push the boundaries of what we knew and could do prior to closures showing us that certain things were even possible, or even valid ways to approach program design.

So trying to understand and use closures is, in a way, embracing that computers--and their capabilities through programming--aren't just digital duplicates of physical reality. They're ultimately a separate thing, with separate and different potential, and to try to describe what they do solely through comparative figures of speech is to limit them.

A tangential example, but with the same idea at the center: skeuomorphism in digital interfaces. An instance of this many people are familiar with is the major design overhaul Apple made between iOS 6 and 7.

If you've forgotten that shift (I had--and wow, looking up images of old GUIs I once used every day, but that now look incredibly dated, is a strange experience), the baked-in Photos app was like this in iOS 6:

iOS 6 Photos app icon--a sunflower in front of a blue sky

And like this in iOS 7:

iOS 7 Photos app icon--a color wheel on a flat white background

The iOS 6 icon is a skeuomorph: it resembles a physical thing that, through familiar comparison, supposedly guides you in your understanding of the app's purpose. You might find a meadow, take a photo of a sunflower, and look at in the app. The iOS 7 icon is completely different: it's a color wheel that has an impressionistic connection to the function of the app, but it's not as figuratively on the nose.

So, like closures--and I fully recognize the iOS Photos app is not nearly as flexible or powerful as a JavaScript closure, but the comparison still stands, I think--when Apple let go of the physically figurative design, they opened up the implied possibilities of the app. After all, you can take screenshots, edit color balance, manage your library, and share photos from the app, and the more abstract design reflects these actions better than the limited sunflower in a field.

Another (maybe more consequential) example: DAW (digital audio workstation) interface design. Even if you've never recorded or mixed audio before, it's fairly easy to see that the Logic Pro X mix window:

Digital audio interface, but lots of faders, knobs, and other objects with real-world analogs

Looks a lot like an analog mix console:

Neve 5422 Suitcase Mix Console, also with lots of faders and knobs

That particular mix console, the Neve 5422, went into production in the late 1970s. The first version of Logic Pro X was released in 2013. That's an awfully long gap, during which the way we record audio changed completely but the skeuomorphism of the necessary tools didn't.

While there are a few good reasons why most major DAWs still resemble physical consoles--the most important being that many engineers work with DAWs using physical controllers that, shockingly, look like analog mix consoles--why not update this design for the digital era, and thus expand its capabilities?

Physical volume faders made intuitive sense when you could put your hands on them, but dragging a mouse (or, worse, scrolling on a trackpad) to do the same is often frustratingly clunky and imprecise, particularly when you're adjusting them in real-time while a song is rolling. I could go on for another post's length with just complaints about using a keyboard and mouse with most DAWs as they're designed. Sure, keyboard shortcuts and patience help, but there's a lot of room for interesting improvement if the designers would just stop emulating decades-old physical consoles.

Do I have specific ideas for a DAW design that better reflects the endless possibilities of working with audio on a computer? Not really. Just like I don't fully understand the capabilities of JavaScript closures, I'm less concerned with where exactly venturing outside of skeuomorphism and other types of physically figurative understanding takes us, and more just excited that we've created computers and other amazing abstractions that have the potential to land us somewhere interesting and completely new.