Ignoratio elenchi

What is it, to make a mistake?  To commit to a false analogy.  Most human error is a matter of tacitly importing presuppositions into a situation where they're irrelevant; most confusions are covert equivocations, where some slippage of meaning has occurred between the major and minor premises of a practical syllogism.  The result is the equivalent of making a chess move in checkers: you've inadvertantly imported abstractions from one domain into another, and the result is nonsense.  A well-designed interface does everything it can to prevent this; a poorly designed one encourages it.

Finding Snowden

I saw Citizenfour at the theatre recently; it's a suberbly minimalist documentary which is less art than political act.  As a rule I hate political docs because most of them are hamfisted attempts to cajole you into a belief; this one is exceptional insofar as it's simply showing the true story of one guy following his concscience against terrible existential threats.  The emotional resonance of that is reason enough to see it: it will, if you're a thinking, feeling human being of any sensitivity, nudge you in the direction of being a better person.  

One thing the film indicated in passing rather than hammering on was that we're living in a perilous situation where the only thing keeping a monstrous apparatus of intrusive surveillance from being unleashed on us all is sheer legal tradition; all it will take is a couple of rulings that go the wrong way and set the wrong precedents and we will in fact find ourselves very rapidly in a very scary world.  There are known technical fixes to help prevent this world from coming about; all that's actually lacking is enough people who appreciate their importance enough to implement them.  I could hate on Apple and Google all day long, but the fact that they're actually moving in the direction of automatically encrypting everything in their OSes, in part due to the cultural influence of the Snowden leaks, is enormously to their credit.  

One thing the film crystallized for me is that, while I'm used to thinking of tech from the standpoint of aesthetics and power, the ethical dimensions of it loom very large in the background and should be more often discussed.  It doesn't take a lot of acuity -- just a sprinkle of cynicism -- to see that you keep people from being oppressed not by reciting pious mantras but by making them hard to oppress, and that any tech that makes it easier to oppress people is evil.  The problem is that a lot of things that get foisted on us in the name of 'efficiency' also make oppression efficient by creating single points of control.  They also make disruptions efficient -- oppressors here can be governments or rogues, and what makes us safe from both is an infrastructure that lacks such privileged nodes to be manipulated in the first place.

I've found it easy to be fatalist about a lot of things over the years, but the film helped awaken my inner Snowden -- realizing that it actually is possible to stop a lot of this insanity, if enough people wake the fuck up and do something intelligent about it. 

Don't cross the streams

One of the rudest things any program can do is to unpredictably jam its output stream into the operator's input stream.  It sounds like such a basic and obvious no-no, but it is astonishing how many pieces of software fail this basic etiquitte test.  'Stealing focus' is just the most common example, but in general anything that breaks your flow is a candidate.  The machine should only alter your behavior in cases where something critical depends on it, and so the fault here is that whoever designed the program has an inaccurate sense of what's actually important to you, and when it's important.

This is one argument for radically reconfigurable computing systems, but leaving that aside I often cannot fathom what thought process somebody went through to decide that it was worth interrupting my flow for something.  Or maybe they just didn't test the damned thing enough -- programmers should always have to eat their own cooking every day for a month before they even think about releasing it on an unsuspecting public.

The point is that output alters the user's behavior, and you only want to do that if the user is currently behaving inappropriately.  Superfluous output is wasted cycles on both the machine and user side, and the further sin of shoving that output directly in the user's active input stream is shitting where you eat.

(Addendum: A more insidious version of this is anything that assumes you want information dumped in your face, rather than waiting for you to tell it so.  This is why google.com is a nice interface while facebook.com is a rude one.  Also why all phones should come with a person-by-person ring setting, i.e. I want my phone to ring when my sister calls but not when my creditors call.)

Beauty and the Beast

I'm not the first to gripe about this, but one more voice in the chorus never hurts: it is an absolutely insane state of affairs that the conventional environment for something as nice and relatively ageless as Common Lisp is something as hoary and archaic as Emacs.  Forcing somebody to get used to the arcane and arbitrary keybindings in Emacs before they can enjoy Lisp is like making them learn to type with their toes in order to use a laptop.  It's utterly senseless, and I'm pretty sure the only reason it is this way is that once you've invested the months it takes to feel at home in Emacs, you have no incentive to create a more natural environment.

I'm currently playing around with Sublime Text with the SublimeREPL add-on, modded out to run CLISP.  As an environment it's cloying in its own way -- no, ST, I don't actually want you to insert that close-paren or quote mark for me, thanks anyway you interfering smartarse -- but the fact that I don't have to get a repetitive stress injury in my pinky or remember entirely un-mnemonic commands is a major plus.  Lack of a simple, standardized, intuitive environment that just works (like Racket has) makes CL substantially less 'approachable' -- Emacs-hate was precisely the reason I didn't bother diving deep into CL years ago, and if a more accessable environment had existed back then I might be a CL guru by now.

Sadly, this is indicative of the mindset of the CL community, which has a very 'eat your fucking vegetables' attitude -- not necessarily a bad thing, but certainly an impediment to widespread Lisp dominance.  You can have your elitism and complain about how brain-dead the rest of the world is, or you can work to enlighten the commoners and fill the world with beautiful things -- pick one.

Ethereum: solving the right problem

Some months ago I ruminated, not terribly productively, on what's conceptually muddled about bitcoin.  The conclusion I came to, but did not clearly state, is that since the most essential function of money is as a reliable standard of deferred payment, market transactions are best thought of as problems of contractual obligation rather than 'exchange of value', and that we should be pointing the tech at this more general and more fundamental problem, treating currency as a special case.  This is not a new thought, but good old thoughts are worth re-thinking from time to time.

A scant few days later, I discovered that somebody had already gone through this thought-process at lightning speed, and invented Ethereum.  These guys have thought all this through very well, and they are more on the right track than anybody else in the running right now; I strongly encourage anyone who's interested in the future of commerce to read their whitepaper.  This isn't merely another bitcoin hack like Namecoin; it's a proper ground-up generalization, crafted with a wide range of particular applications in mind.

As they put it on the main site, the concept behind Ethereum is: 'Turing-complete contracts on a blockchain.'  What they've done is to construct a fully loaded programming language, which can do anything C or Python can, on top of the same type of cryptographic infrastructure bitcoin uses (with some important tweaks).  'Contracts' are reduced to programs, autonomous pieces of code living a distributed life in an ever-growing ecology coded as a hashtable, and enforcement is automatic.

One result of this will be a closer approximation to real personal cloud computing than anything yet implemented, since you can frictionlessly contract out machine resources; it is not totally wrong to think of Ethereum as a distributed operating system for the cloud.  Another result will be a host of experiments in social organization, since the costs of starting and maintaining distributed organizations will be drastically lowered; another will be that most existing legal practice will be obviated, since formal languages are transparent and unambiguous in a way that natural languages aren't, making agreements both self-interpreting and, because of the crypto and the economics of the protocol, self-enforcing.  If the dubious reaction of governments to bitcoin is amusing, the reaction of lawyers when they figure out that Ethereum is about to eat their lunches is sure to be hilarious.

My coding project next year will be to write an Ethereum implementation in Common Lisp; given the pace I work at, almost surely somebody else will get there first, but it's more about the journey.  If I were to hazard a prediction, I'd guess Ethereum will also be a source of great employment for those wise in the ways of macros.  Because as Doug Hoyte puts it, macros make every other language a wrapper around Lisp, and I can think of no language better suited for such a dynamic problem-space, for crafting contracts that write contracts, etc.

Two Kinds of Hubris

I found a little essay, 'On Generalization', which is good but should have been titled 'On Premature Generalization' -- which deserves to be recognized as an anti-pattern.  The nut of this essay is that generalization is a form of prediction, which is a nice way of putting it; the obvious inference is that premature generalization is the equal and opposite error of premature optimization, which as we all know is evil.  Inappropriate generality and inappropriate particularity can both get us into trouble and waste a lot of time, but the problem is not the generality or the particularity but rather the impropriety -- attempting to fit the future to an ideal that turns out to be irrelevant.

What would be more helpful is guidance on when to generalize or to particularize, in the vein of the 'design patterns' way of thinking.  Some very rough guidance can be found in Christopher Alexander's notion that each pattern -- that is, each generalization -- arises naturally in response to tensions among desiderata, and is a way of coordinating the forces naturally present in a way that relieves the tension. So the most general answer is: examine the context, and ask what problem you're actually trying to solve, and why.

(Addendum: Subsequently found this quote from Emil Persson: 'Premature optimizations can be troublesome to revert, but premature generalizations are often near impossible.'  This gets to the heart of the matter much more concisely: the information thrown away in any act of abstraction is not, in general, easily recoverable.  Deleting is easy; rebuilding is hard.)

Metaphor, Analogy, Abstraction, Method

'Strictly speaking, metaphor occurs as often as we take a word out of its original sphere and apply it to new circumstances.  In this sense almost all words can be shown to be metaphorical when they do not bear a physical meaning; for the original meaning of almost all words can be traced back to something physical; in our first sentence above, for instance, there are eight different metaphors. Words had to be found to express mental perceptions, abstract ideas, and complex relations, for which a primitive vocabulary did not provide; and the obvious course was to convey the new idea by means of the nearest physical parallel.'  (Henry Fowler, The King's English)

I like this quote because it indicates a deep relationship between metaphor and abstraction -- the act of abstraction is the first step in the metaphor, and the second step is the application of the abstracted method to the new domain.  The graft takes if the two contexts are analogous; that is, if the relevant meanings inherent in them are commensurable though different.  Analogy is defined by equivalence of methods: 'what works here, also works there'.

But equivalence is not indistinguishability, and the difference between domains is what gives force to the metaphor: the power of a metaphor is proportional to how much variety it can successfully subsume under a common method.  When we lose sight of the differences, the metaphor becomes 'dead', i.e. nolonger capable of evoking the same emotion.  When the differences suddenly reassert themselves in the form of a contradiction, the magnitude of the emotion felt is apt to be proportional to that of the living metaphor -- albeit with the sign reversed!