Future of Coding • Episode 62 Fred Brooks • No Silver Bullet 𒂶 https://futureofcoding.org/episodes/062 Jimmy and I have each read this paper a handful of times, and each time our impressions have flip-flopped between “hate it so much” and “damn that’s good”. There really are two sides to this one. Two reads, both fair, both worth discussing: one of them within “the frame”, and one of them outside “the frame”. So given that larger-than-normal surface for discursive traversal, it’s no surprise that this episode is, just, like, intimidatingly long. This one is so, so long, friends. See these withered muscles and pale skin? That’s how much time I spent in Ableton Live this month. I just want to see my family. No matter how you feel about Brooks, our thorough deconstruction down to the nuts and bolts of this seminal classic will leave you holding a ziplock bag full of cool air and wondering to yourself, “Wait, this is philosophy? And this is the future we were promised? Well, I guess I’d better go program a computer now before it’s too late and I never exist.” For the next episode, we’re reading a fish wearing a bathrobe. Sorry, it’s late and I’m sick, and I have to write something, you know?

Ivan was right — programming is inherently spacial, but not because programs are. Programming is a thing human beings do, and human beings are inherently spacial.

Come for the FoCing. Stay for the music.

Cant wait to listen! For anyone interested there is a lovely response by David Harel in 1992 called “Biting the Silver Bullet: Towards a Brighter Future for System Development”! https://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/BitingTheSilverBullet.pdf

Assume Harel is talking about a 40-year time horizon, and then look at things like TLA+, and s(CASP)'s event calculus over unbounded continuous time, he seems pretty prescient, if maybe optimistic on timeline. Still, it's strange to see someone writing in the 90s about something that barely exists nearly 30 years later.

Is a Turing machine inherently spatial? Is text inherently spatial? How about a linked list? What does "inherently" even mean? Also, what does "spatial" even mean? I think we can all agree that Jimmy and I would end up agreeing, and that he wouldn't sincerely hold such a strange perspective as to believe programming isn't inherently spatial.

Lol. 😉 Spacial means that it can be described in multiple dimensions of the same type, plus time. If you multiply a length by a width you get an area. If you multiply a Turing machine array address by the binary value at that address, you get nothing useful. You can diagram the Turing machine, but the diagram will have area that the program does not. That's what I take "not inherently spacial" to mean: representing it spacially necessitates adding info.

Ivan was right — programming is not inherently spatial but it ought to be

Does the world really need a paper that says "there's no silver bullet"

I think so? If there's a wave of hucksterism that's whipping people into a frenzy, it's helpful to have someone put their reputation on the line and say "Web3 is bullshit. All crypto stuff is a scam. The blockchain has never been used for anything good, and likely won't be for at least a decade."

That's true, though I guess I can still believe that there are silver bullets out there in this space - it just isn't crypto :) I think that would be a different position to the paper's - but I might be wrong!

The wyrds quietly moaning "spatial"

Small (spatial) steps 💪

I tried to post my thoughts, and I got this. 😂 I'll have to split it up, but I don't have time now. I guess that's what happens when I listen to such long episodes. 😂

@Personal Dynamic Media I'm excited to read it. Feel free to create a "text post" / attachment to a message. That might let you share the full thing in one go.

He's an attempt at attaching it.

Also, text IS graphical. It consists of graphics that we spend our entire childhood and adolescence mastering and connecting with deep semantic structure. The utility, flexibility, and expressive power of plaintext representations are extremely high, and personally I think one of the challenges of implementing graphical programming is that one is competing with a medium as powerful and expressive as text.

YES! I don’t know why we don’t talk about this more! Spacing, collection of similar methods, naming_conventions, line length limits, syntax highlighting, and splitting or merging files are all examples of basically graphic design and visual hierarchy (in addition to other things). In fact, the use of folder hierarchies could be an argument that all of our projects are at least somewhat spatial. Further than that: a program file is a map from instruction order to time, which we represent spatially when we’re working by ordering our programs. We have function arguments immediately follow function invocations. The most common form of argument passing uses the horizontal access of text to communicate inclusion with paired characters ((), [], {}) and we even claim those characters can be divided into “left” and “right” brackets!! I think one reason this argument sticks around for so long is that nothing is “inherently spatial”. Atoms are just mathematical models. Maybe they represent something that exist in space—but when we refer to the model, you could argue that. i don’t know. They’re more inherently a model of mass and charge than they are of space. The bottom line is that no one has a direct line to reality—we have human brains that get trained up from an early age to prioritize processing a huge number of vitally important experiences by arranging that data spatially—whether vision, touch, proprioception, pain, sound, balance, or emotive feelings etc! Who cares if programs are inherently spatial? Our brains are highly likely to think of them that way by default, and tremendously more efficient at processing and thinking about things that way. I do think that we’ll be able to find more than one near-perfect mapping between space and programs, but given our neuro/experiential/ergonomic advantage we have absolutely no reason to tolerate the level of hostility to people devoting time and energy to leveling up our visual metaphors just because the chips aren’t in on a thousands-year-old debate that boils down to semantics at its most base level and spiritual contemplation at its most rewarding! We have the moral imperative to do our best to empower the creative potential of everyone as quickly as we can before our civilization fries or bombs or sedates itself into a dark age in pursuit of private profit! how’s that for demagoguery lol

I was just writing about different ways of being spacial on another thread! There's "spacial" as in being physical, "spacial" in a mathematical sense, and "spacial" as in an image you might have in your mind that you share by putting on the screen (or elsewhere) with text and illustrations.

@Garth Goldwater You've said it better than I could have! I guess I should set some boundaries. I'm interested in whether space exists, or programming is inherently spatial, in a "_do numbers exist?_" sort of conceptual foundations sense. But I'm much, much more interested in what folks like Brooks mean when they say "programming isn't inherently spatial", which I take to mean: programming is largely about symbol manipulation and the shuffling of bits facilitated by a language, and language isn't spatial in the sense that the world around us is spatial, so programming isn't spatial. It's this view (and the others like it) that I disagree with. So maybe I should object to their use of the word inherently, and instead frame the discussion as: Is programming practically spatial? As in, to what practical degree does space play a role in how I program? What could we do to improve programming and its practical use of space? The obvious answer, and the one which I currently swear by, is significant whitespace. One transpiled language to rule them all.

@Ivan Reese I wonder if we could approach this topic from a slightly different framing? Mainly, let’s say that a program is a set of topological relationships that allow the computer to perform computations. Some examples of these relationships include containment, order, adjacency, and connection. It shouldn’t matter what level of abstraction (bytecode, assembly, ect.) we are thinking about the program at, these relationships are encoded in some way. The insight of this framing is that these relationships can be expressed in different modalities. Computer hardware cares about these relationships expressed as bytes, compilers cares about these relationships symbolically, and humans care about these relationships in a multimodal manner (symbolically, geometrically, spatially, ect.). For example, containment is typically defined as anything inside of a pair of brackets or parenthesis (e.g. function body, class body, ect.). The whitespace inside of those brackets is meaningless to a compiler, but meaningful to the people authoring that program as demonstrated by the commonplace cultural practices around code style guides and linters. Whitespace sensitive compilers are interesting because I would argue that those compilers dont care about the spatial modality, its that the symbolic/textual relationships maps to a meaningful spatial/geometric modality humans favor. Im not a fan of these “inherently spatial or not spatial” reductions. To me thr “future of coding” is about taking these topological relationships a program describes and enabling them it be viewed and interacted with in many different (and new) modalities that best enable the person and machine to understand and act on that program! Tangentially, programming paradigms what those topological relationships are, what they mean to the human and machine, and what guarantees can be made about them. Anyway see “On Visual Formalisms” by Harel for more on the topic! https://dl.acm.org/doi/pdf/10.1145/42411.42414

Great Episode! Lots to process, definitely have to re-read NSB sometime soon. Possibly of interest, the ~20 year NSB retrospective: https://www.infoq.com/articles/No-Silver-Bullet-Summary/.