La dissolution des mots

I have always found it challenging to write about both my software work and about my evolving philosophical notions, the latter I think primarily because those ideas are still so amorphous. For quite some time, though, I thought that my reluctance to discuss my software art was entirely due to anxiety over it not being good enough, and indeed that might be a factor. However, I also now realize that past attempts have ended up merely being descriptions of my software as something that already exists, as a sort of linear history of how I got to where I am, and to be honest, I find that type of thing to be mind-numbingly boring. A while back I claimed that I only care to write when it seems likely that doing so could lead to some kind of epiphany or catharsis, and writing about facts and details absolutely does not do that for me. Nevertheless, I have recently made efforts to explore some of my philosophical ideas, even if I’ve done so in a decidedly non-academic way, and I haven’t found myself entirely dissatisfied with the results. So maybe it’s time to try again to discuss my software.

From the moment my father brought home an IBM PC Jr one day when I was 9 years old and I discovered simple commands in BASIC that would allow me to place colors on the screen, to create imagery with my mind and a keyboard instead of with a paintbrush and manual dexterity, I was hooked. Always since then programming itself has been nothing but a basis, a mere foundation for my true purpose, which has been to create beauty. Or perhaps it’s not beauty I sought, but simply an esthetic outcome, which might mean that I have in fact always strived to be an esthetic researcher. Programming itself is interesting, to be sure, but it is nothing more than a tool that I have hoped would one day allow me to show you the awe and wonder I feel about the simple fact of being alive as a human being, and perhaps that is what the technological sublime is all about. However, that goal has forever remained just beyond my reach.

There’s nothing very advanced about my software art, if that’s even the right word for it. It’s based on just about the simplest possible generative algorithm, something that everyone starts with but then quickly abandons because it’s been done to death. It’s a variation on John Conway’s Game of Life, but also heavily influenced by Brian Eno’s ideas about what ambient music is and can be. But that’s all just something of scaffolding, something to give it a minimum of shape and form, so that it be visible at all, because I have discovered that I have tremendous difficulty with form itself, which is also why I eventually gave up my nearly decade long obsession with architecture. However, I am ultimately satisfied with that being the case, because that distant thing I have in my mind is itself entirely shapeless and without form.

In my opinion there are two enormous limitations to the Game of Life in its original form. First, it only has two states – on and off – though, yes, there are variations such as the Generations algorithm which adds a series of steps between on and off, a place to add a color gradient for some added interest. The second problem is that at its core it’s just a grid, a checkerboard. The edges are too harsh and rectilinear, and blinking the squares on and off is too staccato and jarring. But if one blurs the edges, which Leo Villareal has done with frosted plexiglass in front of LEDs, or which I have ended up doing by treating the colors on the checkerboard as points in a cubic NURBS surface, then it starts to become more serene. And if the changes that happen over time, as the cells turn on and off and pass through intermediate stages, happen slowly and traverse smooth (that is, C1 or C2 continuous) color gradients, then it starts to become even more serene yet. Finally, another lesson I learned from Villareal is that it is preferable not to show the entire checkerboard, but instead to zoom in on a small section of it. But that’s all I have. Blobs of color fading in and out. Sometimes I think, oh, that’s kind of nice. Once, exactly once, something caught in my throat as I was playing around with it, and I thought, holy shit, that thing came out of me! But then it was gone.

John Conway’s Game of Life, along with my variations, are a class of algorithms called Cellular Automata. “Cellular” basically just means the squares on the checkerboard. It could also be hexagons or any other shape that tiles. “Automaton” just means it runs without ongoing intervention by a user. Quite frankly, I don’t give a shit about any of that. I haven’t the slightest interest in any of the numerous mathematical properties of cellular automata and their so-called “emergent” properties. It’s awesome if other people care about that, but it’s also awesome if I care about the things that I care about, and math and technology and even programming do not really count among those things. Which is exceptionally weird, considering that they make up the core of what I am proposing is my real work.

One characteristic of Cellular Automata is that there needs to be a starting pattern of cells turned on and off on the grid. There isn’t any specific pattern that’s necessary, but different patterns can sometimes have significant effects on how the grid evolves over time. I choose animation parameters that are not very interesting mathematically, but instead that keep the whole thing from collapsing to a state where all the cells are either stuck in the off position or in a simple stable pattern that can no longer change among more than a few states. As a result I can be rather flexible in choosing my initial state, but I do still need to choose something. From the very beginning I had no interest in doing something like drawing a circle or a squiggle or just generating random numbers to choose which cells should start out in which state. At some point I decided that an image of black-and-white text would be absolutely perfect. Words — words would be the basis, the starting point. And from the very beginning my idea was that those words would eventually be the words of others, short quotes from the poets and musicians and authors that have been such an inspiration to me throughout my life. It would be my homage to them, a thank you letter for all that they have meant to me.

However, the starting patterns for my animations are typically not visible. Even if they can be seen for a brief moment, they still always quickly disappear as the algorithm runs. And so I have a mantra that keeps reverberating in my head – “la dissolution des mots” (“the dissolution of words”, in French because it uses a different part of my brain than my native English). It’s a similar theme to Millie quoting Lessing’s “Read in my eyes all that which I cannot say to you” (originally in German). It’s about the things that exist beyond the ability of words to express, or at least the ability of my words to express. But for me, it seems, words are the foundation, the respite, the fortification. They are the, or a, sine qua non of my real work, but they do not seem to be my real work itself.

And yet all of the above is only part of what it is that I’m actually doing with my software. I’ve described what might be considered the final product, but ninety percent if not more of the time that I spend writing software has very, very little to do with that final product directly. For some reason, I keep holding that outcome at arms length, forever writing and rewriting lower level components. And in fact, what I’m really working on is something perhaps best described as a Photoshop or After Effects (though not even remotely as complex) that I can use to create and edit animations that then run using the algorithm described above.

Perhaps I can’t go quite so far as to fully agree with Paul Valéry’s assertion that the final artistic product is nothing more than a “precious excrement”, when instead the work of creating it is all that has any real meaning. And yet that is how I have been treating my programming work. All of my focus has been on creating software that will allow me to produce and modify these animations with utter simplicity and ease. For example, don’t like that color? No problem, there’s a slider to adjust it immediately. No need to stop the animation, tweak the underlying code, recompile, and run it again. That latter process is something I could do almost from the very beginning, and yet it was deeply unsatisfying and frustrating. The delay between thinking of modifications and seeing their results was simply unacceptable to me. One could say in Boydian terms that my OODA loop was not nearly tight enough.

And so I’ve been working on my editing software, which itself has shown itself not to be the end of the recursion. I had a version working nearly three years ago. It didn’t do everything I wanted it to do, and it was ugly to look at, but it did work. And yet I keep rewriting it. Over and over, one component at a time, down and up the hierarchy of systems, components, sub-components, etc. It makes no sense. It’s maddening, and yet I believe that this type of work is exactly what I should be doing. Perhaps the end product, if I assume that the end product is a visible animation, is indeed nothing more than a precious excrement. But I also recognized at one point that the end product is most likely not that at all, but instead is me or at least my world view.

Debates rage among software developers about what is the one true way to write all software. This is of course the wrong question. It arises from the same exhaustion of internal Subject that plagues all aspects of society, and from the same Verneinung or doubling-down on the belief that there must – simply must! – exist one core, underlying, unquestionable idea, to build upon which every product can be successfully elaborated. But software and the tooling around it is one of the most effective tools that humanity has ever conceived for modeling and testing hierarchies of concepts, even if it has instead typically been used in order to create “products” that we then try (yet ultimately fail) to reason about in terms of the types of products that we’ve been building since the Industrial Revolution. That latter practice almost works, or at the very least a great many people have become extremely wealthy in attempting to do so. But a software “product” is obviously not a car or a dishwasher.

In fact it seems to make little sense even to use the term “product”, by which we mean external Object, in describing what software is, can be, or should be. I’m far from the first person to suggest that software is something like a far more complex form of human, that is spoken or written, language. Yes, one can readily imagine a “language product”, like a book, but is that really what language is or has traditionally been? I hardly think it would be controversial or even insightful to claim that language has traditionally been used as a tool by which to describe, clarify, or illuminate how life works, how it should work, or how it can work better. Epic poems of antiquity (be brave!), sermons (be virtuous!), medieval Everyman stories (follow the rules!), Boy Scout guide books, etc. Language is obviously about communication and explanation, though of course we can still sell the printed or digital versions of collections of words for a profit, that is, as a “product”, and I won’t argue that it is unreasonable to do so.

But words and language obviously don’t in and of themselves do anything. They can incite action, to be sure, but they don’t really do anything in the active, Get Shit Done, external Object sense. And so perhaps software shouldn’t be expected to do that kind of work either, or at least not always. 

Hierarchies in the sense of Commons et al’s General Model of Hierarchical Complexity (GMHC) have very clear ties to the way one tends to create software hierarchies wherein lines of code form functions, grouped together to create subcomponents, themselves making up components, out of which sub-systems, systems, and then programs are built. Consequently, the GMHC’s associated dialectic of stage change, that is, the process of vertically elaborating the next higher level in the hierarchy, would very likely have ties to how one might go about creating software. 

At least that’s how I have been trying for a while to think about and practice programming. Of course I myself have spent nearly the entirety of my career thinking there must be, if I could only find it, one true, perfect, and always applicable and appropriate process of or methodology for organizing code so as to create “perfect” systems without, as they say, having to reinvent the wheel every single time, or without having to think so damn hard every time about how to fit together bits of code that simply don’t want to fit together. Eventually I came to the conclusion that such a process could never exist, partially because everything in all of existence has both a known/knowable aspect and an unknown/unknowable aspect, that is, Object is always paired with Subject, which realization, if it can be accepted, actually feels quite amazing to consider.

So my software will never be perfect, and that’s okay. Well, not entirely okay; I still wish it could be perfect, but I try not to wish too hard. On the other hand, there are certain combinations of Object and Subject which are somehow more stable, somehow better able to withstand the forces of dissolution that are ever present in the universe. Aeons ago atoms were discovered to be a stable way to organize their subcomponents, and then molecules as a way to organize atoms. And so on up to ideas, which are still so recent, in cosmological terms, as to be almost completely flexible. However, I do believe that some combinations of software components – of ideas – are indeed more resilient – not just more robust (won’t fall apart) as Taleb says, but more able to be used as building blocks for outward expansion, which means, I guess, more “antifragile” as well.

But how does one go about finding and/or building such “more resilient” software hierarchies? It very much seems to me that one does so by doing what I’ve been doing – taking apart and reconfiguring all of the existing and past components that have made up the hierarchy of the software in question. Obviously no commercial venture, which treats its software as merely a means to an end, can afford to or would be willing to have its employees do such work. And so it is up to artists, or esthetic researchers, to do so instead. 

The exuberance of several years ago behind startup culture, along with Clayton Christensen’s disruption theory and ideas like “failing fast”, seems to have died down to some extent recently, but if we reconsider those ideas in the present context, then art, or at least esthetic research, is truly the most fertile and safe ground in which to make “small bets”, because one simply cannot fail to create a successful “product” if one is not truly creating a product (external Object) at all. One cannot succumb to competition, because there is no competition in the traditional, market focused sense. Of course, this is only true for “esthetic research” as opposed to trying to play the game of the contemporary art market. And sure, one can fail personally in some way to keep themself fed or clothed, for example, but the failure of one single person as compared to a large corporation on the order of Google, Apple, or GM, or even of a small startup with only a handful of employees, is very, very low stakes indeed, as long as any such person is willing to undertake that risk. Furthermore, an esthetic “product” need not fulfill any requirement to facilitate others in their effort to create even more “products”, and in fact must not do so. So then art, once again, is the safest and dare I say easiest initial laboratory for societal change.

But I still haven’t explained how to create “resilient” software hierarchies, and to be honest I cannot offer a fully satisfactory explanation, because I myself have yet to build one. However, one thing I do find over and over is that the shortcomings of my existing hierarchies only truly become noticeable and intractable once I try to extend them beyond their current use or to build another vertical layer on top of them, which is exactly what Commons et al, not to mention John Boyd, suggest would be the case. And then my intuition, which I am tending to trust ever more over time, convinces me to rip everything apart and reconfigure the boundaries all the way down and then back up the hierarchy. But it’s mostly about boundaries or connective code, to change which does often admittedly require breaking apart whole components but rarely a complete rewrite of them. I suppose even then that after splitting apart components it is often just a matter of configuring new boundaries. And I don’t necessarily have to traverse the entire hierarchy, because there are bits of code all the way down at the bottom that haven’t changed in a very long time, and might never in fact change. And I think that’s the key – there are a certain number of layers that are readily amenable to change, and then below that, especially if we go all the way down to atoms, change becomes increasingly difficult. I have a hunch, nevertheless, that the farther one is willing and able to descend down the hierarchy, the more robust or even “antifragile” that hierarchy can be made. I believe that kind of practice is a significant factor in Apple’s success, and why Alan Kay posited several decades ago that “people who are really serious about software should make their own hardware.”

Eventually after numerous acts of reconfiguring the hierarchy, the bottom-most “readily changeable” layer will have been revisited the most often and then at some point, I suspect, sufficiently often that the basic contours of “what works” will have been relatively well worked out. This then perhaps forms something like the bottom rung on a ladder, a firm base, a starting point for further upward elaboration, or at least a means of avoiding infinite downward recursion. 

But why not do this with any software? Why must the end result be esthetic in nature as one might deduce from Mario Costa’s philosophy? Why can’t I do all of this while attempting to write my own version of Microsoft Word or Google’s search algorithms? I can only assume that it is because of the incompatibility of motivations that guide each type of goal. It is the difference between the ends being an entirely Subjective experience versus focusing on an end product as a tangible external Object. It is vertical versus horizontal elaboration, and I suspect that the former is mediated by the Default Network in the brain while the latter is mediated by the Task Positive Network, which networks for the most part appear to be incapable of being simultaneously active. (And again we see hints of human beings referencing quantum complementarity-like phenomena.) Both types of elaboration are necessary, to be sure, but for some reason it must be in alternation, and none of us appears to be equally adept at each type and thus spends a relatively larger amount of time practicing one versus the other. We fall into one of them more readily, and it then becomes the dominant theme in our work, or even in our cultural era. For me personally, it seems to be predominantly about external Subject and vertical elaboration.

And so that’s how I try to work. I hold in my mind an idea, ever just out of reach, of a transcendent, or I guess I could say sublime, visual outcome with no purpose but to feel amazing and sensual, to remind me and I hope one day show you that to be alive and to be a human being is a breath-taking, awe inspiring, and wondrous thing. If the sublime does indeed mean an enjoyable kind of fear, where we feel as though we won’t actually be harmed because we now have a better understanding of the phenomenon, at this point in human history perhaps it is internal dissolution itself that we must learn not to fear, and if that dissolution can be simulated or explored by repeatedly building up, tearing down, and rebuilding conceptual hierarchies expressed in software, then perhaps software is indeed the doorway to the technological sublime.