Programming as magecraft

2026-05-01 23:44 by Ian

"Magic is a curious fire. It pollutes the minds of those who would shape it. One magician may sense the mind of another magician, blazing like a beacon in an otherwise dark landscape." ---Alastair Reynolds (House of Suns)

As an indication of how deep this goes, I present a true anecdote.
I once stunned my wife by identifying a stranger as a computer programmer in public. We were behind him in line at a coffee shop, and I passively heard him interacting with the clerk. When he finished his exchange and turned to leave, this happened....

Me (to my wife): Watch... you'll love this...
Me (to the stranger): Pardon me, but you have a computer programming education, don't you?
Stranger (to me): [Not surprised whatsoever] Yes.
My wife (to me): How did you know that?!?

I didn't know the man. Nor had I heard him speak more than 168 words in the brief time I was looking at the back of his head. Even more telling, he didn't seem at all surprised that I would ask him the question I did, nor that I should have guessed correctly. After all, he had probably made the same deduction about me from the same brief window of my wife and I chit-chatting while in line. After his indifferent "yes", he continued on his way. Not even curious.
Something in the structure of our communication gave us away for what we were to the other.
A fellow mage.

Expert programmers are very specific about language, and it bleeds into their everyday thoughts and utterances. Which can only mean that the craft has seeped into and remade their minds.
Ambiguity-control as habit.
Definitions first, then logic.
De Morgan's Theorem underpinning every uttered conjunction.

I've always loved the metaphor of magecraft for programming. Think about how a 14th-century scribe would describe a smart phone to one of his contemporaries, it having been explained to him to his satisfaction...

"The artificers [hardware engineers] developed a method for inscribing tiny runes onto purified, polished stones [chips]. These they then join together with high heat onto an unyielding cloth that is itself inscribed with runes and bores [pee cee bee]. To this is mated a plane of deeply shaded glass of such fineness and perfection of measure that at first I could not see it as having principles common to those employed by our own artisans.

"The artificers turn over their polished and engraved stones to the mages, who then imbue them with the crystallized thoughts of many mages whose consciousness never inhabited such a plane. Countless many such simple thoughts in an eye-blink, and wondrous forms and colors appeared in the shaded glass. The formerly lifeless lump of artifice produced a mutual clairvoyance to another holder of a similar work of the arcane arts, this despite their distance being so great as that one's day is the other's night."

Magecraft. Magic.

I've written a fair amount of code that changes things in the real world. Even if that change is sometimes as simple as improving power efficiency for a machine. And although I don't work with motors to the extent that many of my peers do, I submit: We live in a world where cars can drive themselves, robots call humans on the phone, "printers" operate in 3D, and code is underpinning all of it. And if real-time A/V links aren't (by some standard) the same thing as a palantir, than perhaps I've misunderstood the meaning of "magecraft". Certainly, it requires artifice as a precondition, but I'm sure the seeing stones weren't conjured ex nihilo from the vacuum, either. Some poor dwarf had to dig it out of the mountain first. To say nothing of cutting and polishing. The strongest mages tend to also be decent artificers, as to their needs.

Without really being able to explain why, I think this is one of my favorite comments I've ever left for myself. (from EnumWrapper.h). 

Meditation: What is the difference (if any) between semantics and syntax?

Axiom: Naming a thing that does not exist will (by the act of naming it) bring
         the thing named into existence.
That is: A label is sufficient (but not necessary) grounds for ontogenesis.

To the extent that we can bias the evolution of the ontology of a thing by
  naming it, naming a thing is a form of control over the thing named.

In a computer, we always face ontological limits to our named things when we
  first attempt to create one in a finite memory space, or try to consider them
  in finite amounts of time. So we tie a few pieces of information to our names
  for the sake of facilitating the future evolution of things that we name with
  these classes.

Previous:
Next: