It’s Wednesday evening. Incandescence lazes out from the rectangle in the southeast corner of my home work station. Zen Master Bon Seong, a fiery bushel on screen, a big circle face in the biggest square. He is using the figurative Zen Stick to short-circuit our cognition. He is fond of saying things like “You are stardust” or “What is I?”.

Jeff breathes hot air through the broom on his face. Those bits go through audio processing and seem to emanate from nowhere around the work station. “The infinite expansion of the same thing” is uttered. We’re discussing how people can interpret the same phenomena differently. As we say: “The whole world is made by mind alone.” And: “The whole world is a single flower.” As the Heart Sutra says: “form is emptiness, emptiness is form”. You cough. I’m startled. I freeze. I think you have COVID. I think I’m going to get it. Then get long COVID. Someone else sees you cough, they think it’s a sneeze and continue on. Perhaps it is.

The dharma talk continues. There’s nothing wrong with our kaleidoscope of perspectives. They are regular. This is the human mind being itself, resting in its station, but painting a tale on snake, coloring it’s ridiculous karma all over “the small box” that is our little piece of understanding of the universe.

Gosh, we’re talking about boxes from within boxes. Our thinking creates this separate, enclosed being. (Consciousness bound by a skin sack? Not today, the microbiome field transforms you. (Sigh. No help lugging our sacks and their biomic nerve fields closer together. We have decades of men making the Bay car-friendly, but I can’t get across conveniently. I can’t get to Berkeley from Potrero without spending as much time commuting as the duration sitting meditation with the other sacks on for Wednesday night dharma talks.)) The problem is getting attached to difference. Not understanding our “universal substance” – what we say as a convenience. That’s why Zen is about returning to before thinking, accessing the truth before difference. So maybe instead: you cough, then I hand you a tissue.

I don’t want this post to be about the negatives of the human mind’s proclivity to be a multiversal agent. It’s not really a negative, is it? It’s a matter of fact about our minds as atoms floating in space. Space dust. So, instead: let’s relish in the generative creativities that difference making unleashes when multiple human minds are applied to a problem of interpretation.

Zen students say: “All things return to the one.” Once again, I have returned to software. One of my favorite ones for sifting life’s exposures. Nonetheless, I’m thinking about difference. The way the one refracts and playfully escapes. Our turn here will be akin to Jewish monotheism – a personal return to spiritual foundations – a spiritual tradition where the only official doctrine claims one god but there’s no consensus about what that means.

An often-cited medieval midrash asserts that each of the Israelites at Mount Sinai heart God’s revelation differently according to their own capacity to understand it. They each had their own individual experience of the Divine. – Sarah Hurwitz, Here All Along

A long time passed but the Buddha did not open his mouth to say a single word. He then reached down, picked up a flower and, without a word, held the flower aloft. Nobody in the assembly understood what the Buddha meant by this action. Only Mahakasyapa, sitting at the far back, smiled.

But not everyone smiled!

This “problem” of software: the epistemological endeavor to solve challenges in the world through reasoning about what’s actually happening out there and interpreting it into binary logics, electrical pulses: of taking a shared thought among humans – sometimes only the wispy thrust of a thought – and converting it to instructions for the computer. Zen Master Seung Sahn used to say you have to “digest your mind meal”, your understanding. Making software is a kind of digestion of understanding. Pushing thought stuff through a cheese cloth named Divine.

The software process is messy, from beginning to middle to end. Which is why, as Zen student, I must utter: Where does the one return? Software’s interpretive act is a mix up, a Deleuzian differencing that flies a-face a unifying core concept. That’s why software is never completed, or doesn’t seem to exist anywhere in particular. Is it the text in your editor, the code running on the server, the git history, the button that is pressed in a browser, the heavy metals of the memory disk? The lines between human, software, software process, the hardware it runs on, the “world out there” the software performs for…not the cleanest of lines, but lines in flight.

I want to argue here that the distinction between the software system and its development–that is, between the process and product–is another “point of opacity” of software engineering since, albeit necessary, it cannot be kept up at all times. – Federica Frabetti, Software Theory

Software is subversive to hard-dick narratives. It’s feminist, it’s counter-cultural in its essence: which is why gate-keepers try to wrest it away from the hacker collective and make it property. The wisp of generative artificial intelligence hallucinatory resonance is hardly surprising, it’s a re-run run amok. Where does the one return inside your algorithmic nebula? Indeed.

Messy. Material. Just as digestion is wont to be, from mouth mashing through shitting. (Thankfully this physical body process is mostly obscured by our containment sacks.) The metaphor is apt. The world is messy as it is, and software is in it, made from it, made for it. This is why the end product of the software process inspires programmers of acrimonious humor, sometimes of low emotional intelligence, or of self-deprecatedness, or simply exasperated, exhausted… these programmers must declare that which comes from the butt. “This code is crap.” “Who wrote this shit code?”

It’s generally a pessimistic view to call code crap. I’d use “compost” if we needed a corresponding brownish, molten substance for a brighter horizon effluent cream - a regenerative solar punk version. Or something like “the best with what we had.” We need less snark in the industry, more heart.

Thankfully (we can breath a sigh) there are loving defenders of our end products out there. Rachel Kroll is one, synonymously online as rachelbythebay. She emancipates some lines (of code) and litigates her own “crap code” through a simulated trial judged by such an exasperated panel, and then performs my favorite type of “if I knew now what I knew then” refactor blogging with a procedural splunk. It’s a beautiful example of husbanding thought stuff a second time through.

Similar to verbalized language, programming languages provide multiplicities for getting thoughts out whether through your face broom or unadulterated cheeks and lips. Adult English speakers would not be surprised to hear the the idea of reversal expressed by the variations “they retraced their steps”, “they went back”, “they returned”. Back to computers: the “high level” Ruby programming language provides a relatively expressive syntax with multiple lexical pathways for computer instruction. While the variations in high level programming languages like Ruby may not be imbued with the rich cultural context of spoken English phrases, they demonstrate what I’ve always found to be a never gets old trait of programming since the recent invention of modern programming languages now used in heterogeneous postmodern programming environments: there is creative choice!

Similar to English speakers, Ruby programmers will follow contextual precedence, and are bounded by the limits of the syntax. And yet, when going about telling a computer to reverse something, they can still surprise us.

Let’s say a Rubyist wants to reverse a word, known in programming parlance as a “string”: any sequence of characters (letters, numbers, symbols). This rubyist might decide to key punch a common implementation using more “imperative” syntax constructs like a while loop, indexed lookups, and string concatenation. Synonymously referred to as language primitives, imperative expressions are more verbose, but yield more control and flexibility back to the programmer. To wit:

counter_index = original_word.length
# create empty string to contain new reversed word
reversed_word = "" 
# start processing reversal
while counter_index > 0
    # decrement the counter
  counter_index = counter_index - 1
  current_letter = original_word[counter_index]
    # add letter to the result
  reversed_word << current_letter
end

That’s one option. But looping over a string is such a common operation that Ruby provides some convenience to do this. In place of a while loop, index references, esoteric symbols like <<, Ruby let’s us slurp all that imperative code into higher order string methods like each_char – as in “loop over each character” – and prepend (self explanatory, I hope). Under the hood, Ruby implements these methods with it’s own primitives, likely similar to what we’ve written above. Let’s try it:

reversed_word = ""
original_word.each_char do |letter|
    # optional debuggers
    # puts letter
    # puts reversed
  reversed_word(letter)
end

This code is considered easier to read by many programmers because the method names already describe the code’s intent. There’s also less code to mash in the mouth, therefore less information to pack into the brain’s working memory.

Ruby’s do block syntax which yields control over the looped character logically bounds our new string construction procedure in a semantically associative workspace. Coding with the word. Somewhat different than the unhinged free jazz of a while loop block with throw-away variables.

A Rubyist interested in a concise way to “one line” this operation might want to do all the work in place without variable initialization. There’s this:

original_word
    .chars
    .each_with_object("") { |index, reversed_word| reversed_word.prepend(index) }
    .join

Transforming the original word string back and forth from an array to feed the each_with_object piles on the syntax, but this is useful for writing code in a more functional style.

Of course, who even has all that time on their hands to play around. Let’s just make Ruby do all the work for us:

original_word.reverse

In fact, we often have more time, because software needs to last. Therefore it’s not uncommon to see computational code like this registered into a system of collaborators as a member of a reversing machine that can receive messages for requests like reverse_my_word:

class WordReverseMachine
    def initialize(word)
        @word = word
    end

    def reverse
        @word.reverse
    end
end

# Somewhere else in my system...
WordReverseMachine.new(word).reverse

Although, maybe my WordReverserMachine shouldn’t be so opinionated by how to reverse things. Perhaps I want to borrow a reverse engine from other distant cyberscapes. Let’s allow our machine to swap engines as needed:

class WordReverseMachine
    def initialize(word, reverse_engine)
        @word = word
        @reverse_engine = reverse_engine
    end

    def reverse
        if reverse_engine? 
            @reverse_engine.new(@word)
        else 
            word.reverse
        end
    end

    def reverse_engine?
        @reverser.nil?
    end
end

# Somewhere else in my sytem...
WordReverseMachine.new(word).reverse

Reversing a word is a simplistic task, which is why languages like Ruby come with a reverse method on all String objects out of the box. And yet, programmers can dream wildly different expressions as demonstrated above.

Let’s take a look at the diversity of expression that unfolds from interpreting a task in a more culturally rich and relevant problem space. This is one is from an actual mess in the wild – unruly realism – where the task at hand is to look at all the products currently on sale in a restaurant website product inventory database that are not assigned to any particular menu.

Ok: so imagine this shop management software lets managers add products, but wait till later to figure out what menus those products go in. After all, does a croissant go in Breakfast or Pastries? It may not be obvious at first. Splitting up the administration of products this way creates efficiency for product inventory management and menu design. Which allows for more general flexibility and adaptability of a restaurant’s ordering experience. It lets a shop not use menus at all, or have some products in menus and some just floating on their own as standalone products.

These requirements imply that software developers working with this database will need to care about querying for products in a few different ways. Let’s play with a use case where a restaurant manager wants to display a website menu with products that are both in menus as well as a section for all other products. For example, there might be menus for Breakfast, Lunch, Dinner, and then a general list of other products under an…“Other” heading.

The software that supports this shop management software implements this data model for relating products to menus: Marketplace Products have many Marketplace Tags, and these two data types are associated with each other through a bridge table of Marketplace Product Tags. This is a fairly typical way of modeling a tagging system in a Ruby on Rails project with a relational database. Here’s what the model definitions might look like in Rails code leveraging ActiveRecord as an ORM:

# Product Model
class Marketplace::Product
	has_many :tags, through: :product_tags, inverse_of: :products
end

# Tag Model
class Marketplace::Tag
	has_many :product_tags, inverse_of: :tag, dependent: :destroy
  has_many :products, through: :product_tags, inverse_of: :tags
	scope :menu_tag, -> { where(is_menu: true) }
	scope :not_menu, -> { where(is_menu: false) }
end

Ok: so menus, or groups of products, are formed by products sharing a Marketplace Tag where a special boolean field called is_menu is set to true on that tag.

For our case, where this restaurant’s ordering page lists both products in menus and the rest beneath an “Other” heading, querying the right content for our others is the tricky part. This system allows shop managers to tag products freely. There is no restricted set of tags, or other constraints for product and tag associations. Therefore we’ll need to join across three different tables, marketplace_products, marketplace_products_tags, and marketplace_tags, and then collect any Marketplace Products where none of their associated marketplace_tags have an is_menu flag set to TRUE.

Lets start the beautiful differencing!

With the help of my fellow coders at Zinc Coop with whom I workshopped this problem, I’ve cooked three ways to query our postgres database for products without a menu tag with both postgres-flavored SQL and ActiveRecord ORM. (More ways left to be discovered.)

Even if you’ve got a mature ORM like ActiveRecord at hand, it can be pragmatic to express your query in SQL so the selection logic you enshrine in code is blatantly evident. What if, for our initial cook, we code with oneness. Get the data with a single select statement. Not necessarily bravado, or premature consideration for performance characteristics just yet. Let’s see what we can do with that generative single origin select start point.

Mario Kart starting line count down anticipation…

 select
            mp.*
        from
            marketplace_products mp
            full join marketplace_product_tags mpt on mpt.product_id = mp.id
            full join marketplace_tags mt on mt.id = mpt.tag_id
        where
            mp.marketplace_id = '#{id}'
        group by
            mp.id
        having not
            't' = any(array_agg(mt.is_menu));

The cleverness on the last line creates a collection of boolean markers for each Marketplace Product – t or f – representing whether the corresponding Marketplace Tag is a menu tag. The resulting row would look like {f, f, t, f}. Moving out left from the aggregate function, a filter computation is applied against the collection for any existence of a TRUE/t flag. The lispy parentheticals are sleek!

Thought: while the above option foregoes a subquery, I find the combination of group by and having clauses with the aggregating semantics notionally similar to a subquery insofar as we are selecting over a secondary “view” into the data.

It’s dawning on us: getting all the products without menu tags is not complex, although it may have seemed tricky at the jump. We’re only narrowing the product result set based on a single condition, it’s just that the condition happens to live a distance away. Let’s try again without the single select cleverness and consider nested queries:

select
    mp.*
from
    marketplace_products mp
where
		 mp.marketplace_id = '#{id}' AND
    mp.id not in(
        select
            mp.id from marketplace_products mp
            inner join marketplace_product_tags mpt on mpt.product_id = mp.id
            inner join marketplace_tags mt on mt.id = mpt.tag_id
        where
            mt.is_menu = true);

Because we now know that this query is shallow, both wide across only a few tables, and deep with only a single subquery, let’s see if Active Record’s query interface can provide similar conveniences like we achieved earlier with Ruby in our toy string reversal fractals above. As it turns out, we can one-line all that SQL!:

Marketplace::Product.where.not(id: joins(:tags).merge(Tag.where(is_menu: true)))

This is slick, but might not be easy to come by without our previous work or deep knowledge of ActiveRecord. Our subquery version is informative for getting a mental handle on this terseness. We can reverse engineer. Notice how the entire subquery is captured in the outer parens pair. Now: the need for merge and passing in the Tag model as the argument is a bit elusive because we might expect to be able to simply joins(:tags).where(is_menu: true). But this would error because Active Record would think we were applying the where clause to Product instead of Tag, despite chaining on the join. merge is a logical separator that let’s us filter across these two relations with more discreet semantics.

Refine. Refine.

We can utilize the is_menu scope on our Tag class, hiding our where(is_menu: true) filter behind a shorthand that minimizes keystrokes:

Marketplace::Product.where.not(id: joins(:tags).merge(Tag.is_menu))

Ruby on Rails scopes are a brevity blessing. You can imagine where this might be going. Adding a scope for without_menu_tag on Product will make querying and displaying results on our restaurant odering page a triviality. Dropping into the view layer we can grab the data and splat it into components with human-readable phrasing:

<h1>Other</h1>
<div class="grid lg:grid-cols-3 gap-3">
  <%- marketplace.products.without_menu_tag.each do |product| %>
    <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>
  <%- end %>
</div>

The without_menu_tag scope can play well with other chainable scopes for quick prototyping and iteration for restaurant managers.

<h1>Other</h1>
<div class="grid lg:grid-cols-3 gap-3">
  <%- marketplace.products.unarchived.without_menu_tag.sort_alpha.each do |product| %>
    <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>
  <%- end %>
</div>

How shitty is that?

Mind meal tests your mind: do you go for the bait? If you check the Ten Gates, the ten kong-ans, does hungry mind, desire mind, not-enough-mind appear? If so, you must eat your mind meal. You must completely digest your understanding. Then finishing your mind meal is possible. Then you get enough-mind, no-hindrance mind, no I-myme mind. Enough-mind does not go for the bait, so everything is clear and you can perceive any situation in your life and kong-an clearly, and save all beings. – A DOG’S “WOOOF WOOF” IS BETTER THAN ZEN MASTER JOJU, Only Don’t Know by Zen Master Seung Sahn

In 2015 I bought this book.    
7, or 8 years ago.    
Year one into my software career.   
This book is canon.   
I've had little use for its studies of algorithms. # thus far, see below     
I don't think Bentley would be offended.    
First sentence: "Computer programming has many faces."    

I’m sure I glanced at its pages before entering the corporate interview gauntlet, to get in the vigilante mood. Like shaking out the shoulders when staring down a twenty two minute treadmill run (or pile of laundry Sunday evening). (You must to armor up for the algos in the kingdom of men.)

You know, Bentley’s pearls are usually the type of polished wisdom earned through real life experience I drift with, but this book never became the vade mecum for my quotidian affairs. Is it for others? Most of it, after Part I, was too metallic for an early-career front-end Rails dev. But the book can quickly be pragmatic in the earlier pages – see 3.2 Form-Letter Programming!. Templating is up there with the best of them.

The book is pedagogically caring (great headings). It’s pornographically geeked in thoroughness. The cases are so well-situated. Bentley spoils you with opinionated further reading and subjective sidebars that add the kind of first-hand-account historical/social context that remind you that the metal has been worked over by person hands.

It reminds you that software is not lonely.

Look out, there’s a modest amount of myth-making for his contemporaries and mentors. But who wouldn’t. The most honest plagiarisms. Yes/and he’s humbler than many. Ok maybe I have to read it again now that I have more years behind me.

Although I am a visual learner and thinker: logical word-problems were always a pain. In recent years I tend to reach for Bhargava’s Grokking Algorithms for a refresher on binary search or walking trees. It has cute pictures. It’s stacked next to other faves like Land of Lisp and Why’s (Poignant) Guide to Ruby.

Hmmm (thinking emoji, I will not look you in the eye as I cock my head buried in thots). After all the solstice konmari of my bookshelf – which I thought would elicit a reflection on some forgotten paper taking up space – has become the discovery of lost treasure. And yet, I’m still tickled by the scant amount of notes taken. I can’t read without a pen. Perhaps we’re time-traveling, then.

It's year one. 
Young Rails dev. 
He makes only two liner notes in a book considered staple grocery. 
I don't remember if I even read the whole thing. 
I bet I got through Part 1's wider lens, then started to gloss over.

One note is an exaggerated check mark next to this principle listed on p29 (Second Edition, published 2000):

Rework repeated code into arrays. A long stretch of similar code is often best expressed by the simplest of data structures, the array.

With “the array” also underlined from the outer left edge of the “t” to the outer right edge of the last “a.”

This one has stuck. Arrays, especially maps, can be more durable when staring down change. Before long any thoughtful software developer will realize that the components of a software system will become ordered and/or multiple.

There is no lonely software.

Data, whether as scalar, “bags” of properties, even subroutines and processes, even the manual lever pulling human tasks must be sequenced, serial, bound, reversed, indexed, sorted. The maintenance cost of housing data in ordered collections is generally low.

[<anything>, <anything>] 

Whole ass languages, like Clojure, were designed to favor ordered, associative arrays. As I learned after finding Hickey’s seminal talk Simple Made Easy. (Richly simple and luxurious as Hockney’s bathers.)

A second mark: a vertical line next to the opener for section 12.2 One Solution. This was (yet another moment in my lifetime) I learned that we never have to go it alone when staring down the void of what we’re building next:

As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth’s Seminumerical Algorithms (having copies of Knuth’s three volumes both at home and at work has been well worth the investment).

This has also stuck, reified after seasons.

But night software is not like that. It’s not written for the day job. It’s not written to see the light of day at all. It’s not written to be looked at and scrutinized by anybody. It’s intimate and personal, it’s messy and buggy. To take a look is to transgress.

Boundary cross. Sex.

From a small heap software that helps make software. By way of Devine Lu Linvega

IYKYK DEI in tech is all but dead. If you’re an outsider, it’s important to understand that employee-led efforts to make workplaces less racist – which began in earnest at the onset of the Obama years – have been steadily blotted out since Trump. The Tech aristocracy has decided to abandon DEI budgets along with other workplace perks. As @betsythemuffin notes (in the thread I’ll be referencing below):

DEI is seen by a sizable chunk of the funder class as an allowable luxury to keep the peons happy.

It has been tragically hard to swallow this defeat. @betsythemuffin again:

Regret that we didn’t do more to build material power when we had the chance.

And yet, as the movement has regrouped and recentered to reposition the struggle, some have begun to take note of a problematic adaptation in the techy left’s rhetoric. @danilo started a thread on Mastodon that points out a new-born form of absolutist skepticism for emerging technologies – notably AI (of course). Regardless of why the left slips into what @glyph calls a problem of “semasiology” around the term “AI”, point is, the hurt seems to be cutting so deep that the movement has retreated into an unproductive preservationism.

The abject and understandably heartbreaking defeat of DEI-type progress in tech has moved most leftist critique of the space into a technological conservatism built on denialist, magical thinking.

You can’t successfully advocate for a dead end when the other side is investing in roads that lead to helpful places.

You can’t win against technologies people find useful by pretending they aren’t useful.

Check out the rest of the conversation. There are smart people in here thinking through this “AI” moment. The underlying question seems to be how we can continue the fight without completely disavowing what might be practical revolutions borne out by this albeit early phase of “AI” that is “finally bearing serious fruit.”

If you’re wondering on what side of the line I fall, my major beef with the LLMs is their wanton extractive consumption of human labor without citation or, god forbid, recompense. Of course, a time honored tradition of slave traders and capitalists. Here is Marc Andreesen with a recent plea written to the US copyright office, hopeful we can just all ignore this blatant theft for the common good of the funder class. This is class warfare:

Imposing the cost of actual or potential copyright liability on the creators of AI models will either kill or significantly hamper their development.

I hold that citation is feminist since it combats the authoritative mansplain that obscures collaboration, hardens selfhood, and hoards ideas. Ergo I consider the de-linkified, referent vacuum of effluvium produced by ChatGPT et al as patriarchal in its presentation of “knowledge” and preoccupation with mastery. I’m scare quoting because philosophically I’m confused about what this content even is, so unhinged. Although I recognize that the interplay of this text with the reader and their investigative context does produce meaning.

UPDATE (minutes after the writing the above): heh, Danilo actually expounds generously about the left’s false critique of AI in a long-form piece on his blog.