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.
'. . . one should only generalize in order to individualize better.' (Don Colacho)
Thursday, 28 August 2014
Tuesday, 19 August 2014
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.)
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!
The Significance of Style
I've previously linked to David Stove's infamous little stinkbomb, 'What is Wrong With Our Thoughts?'. After opening with a series of illustrative examples and wisecracks, Stove considers and rejects a number of facile answers to the titular question. I want to isolate a couple of points he touches on in passing, but is, characteristically, too quick to dismiss:
'Defects of empirical knowledge have less to do with the ways we go wrong in philosophy than defects of character do: such things as the simple inability to shut up; determination to be thought deep; hunger for power; fear, especially the fear of an indifferent universe. These are among the obvious emotional sources of bad philosophy. . . . Still it is, of course, an understanding of bad thoughts that we are after, rather than of bad hearts: of public intellectual effects, rather than of private emotional causes. . . .I've concatenated these two paragraphs because although Stove seems clearly to think of them as quite separate, it seems obvious to me that they're deeply related: after all, Hegel's dry, boorish and obscure style probably accurately reflects a dry, boorish and obscure character -- just as Schopenhauer's fiery, direct, and cranky style probably accurately reflects a fiery, direct and cranky character. As the latter says in The Art of Literature: 'Style is the physiognomy of the mind, and a safer index to character than the face.'
'That philosophers' errors are usually most intimately connected with their abuses of language, I not only do not deny but am most anxious to affirm. Far more often than not, their intellectual crimes and their literary ones are inextricably interwoven. . . . The exposure of philosophers' errors, consequently, is likewise often literary as much as it is intellectual. Hume, in his justly famous paragraph about 'is' and 'ought,' brought a fundamental logical truth to light, by complaining of a certain common literary sleight-of-hand. . . . It cannot be an accident, any more than it is an accident that our mental and our bodily powers are extinguished together at death, that thought and language arrive together, in Hegel, at the highest degree of corruption of which either is capable.' (ibid.)
The common term between language and character, then, is style, and what's wrong with our thoughts is what's wrong with our style. This doesn't answer the question, but shifts it to a more tractable domain: we know less about good thinking than about good style, and if the two turn out to be the proverbial obverse and reverse of eachother then we're already halfway to a solution. The early prototype of Stove's nosology of thought can be found in Fowler's The King's English, which contains not merely diagnoses but remedies for a host of minor illnesses. If Fowler's moralizing tone seems antiquated to us now, that's to our detriment -- his vehemence about proper use stems from the conviction that stylistic defects are intellectual defects are moral defects.
Which is a good occasion for a little digression. Elsewhere in the essay, Stove writes (only a little untruthfully): 'Nothing which was ever expressed originally in the English language resembles, except in the most distant way, the thought of Plotinus, or Hegel, or Foucault. I take this to be enormously to the credit of our language.' Which is incredibly funny if you're familiar with the evolution of English, because it's only since the 18th century that English has even been a serviceable medium for expressing abstract thought in any degree of sophistication. (If you doubt this, R.F. Jones' The Triumph of the English Language is a book that can prove it to you.) You might even say that until the 19th century there was something of a wilful hostility toward abstraction in the tradition of English vernacular.
Earlier along that path, here and there we see a figure like Chaucer or Shakespeare who manages to heroically improve the language by working with the grain of it; but you can equally well see sad spectacles like Francis Bacon or Richard Hooker struggling mightily against English to little avail. For serious intellectual work, Bacon, like almost everyone else up until the late 17th century, used Latin. Even into the 20th century, one can find an American with antique sensibilities like C.S. Peirce faintly complaining that ancient Greek is a far superior language for thinking in.
Of course, Stove also might be less of a chauvinist if he spoke German -- I'm a novice at it, but it does have obvious virtues that English lacks, such as much greater freedom to form compound words. This is a famously mixed blessing, as people have been known to fall into a stupor before reaching the end of a convoluted sentence in technical or bureaucratic German; but I have it on good authority that once you've tasted the Germanic power of compounding you can't help but feel a little hampered thinking in English. Like most forms of power, this is magnetic to the corruptible: having a less restricted vocabulary means you can much more easily form thoughts that don't make any damned sense, and many do abuse it thus. It might actually be the saving grace of the English that their language is less expressive.
I don't know much about the evolution of German, but given that Germanic peoples historically tend to lag behind the rest of Europe by a couple of centuries in most intellectual trends, it's not too surprising if by the 19th century Hegel is still having some problems thinking coherently in an abstract style. Impossible though it may be to believe when you try to read the Logic, Hegel was quite capable of crafting a sound sentence in German the moment he descended to concrete matters. He was, as he went along, making up a style to suit his end -- which was, very roughly, to do for Protestantism what Thomas Aquinas had done for Catholicism six centuries prior, but without the advantages of Latin. Small wonder the product is a bit of a monster.
To get back to the main point, the ways in which English thinking can go wrong are different from those in which German or French or Roman or Greek thinking can go wrong, and so also for individual cases within a common linguistic tradition. These differences are not merely cosmetic, and study of them should sharpen our appreciation of the merits and demerits of the different styles of thinking they enact -- and, perhaps, reveal some invariant features of good thinking. But this kind of study isn't merely logical, as Stove points out; it's also aesthetic and ethical, and necessarily historical -- it's a comparative study of styles. Because thinking is not something that happens merely in the head: our every act is evidence of it.
* * * * *
Addendum:
Since dashing this post off, I came across a dissenting opinion, expressed in the context of what makes for bad code:
'The disease is ignorance of the language's features, not poor programming style. Once the features are fully understood, the correct styles are obvious. An auxiliary theme of this book, one that applies to any programming language, is that in programming, style is not something to pursue directly. Style is necessary only where understanding is missing.' (Doug Hoyte, Let Over Lambda)I'd say this is a distinction without a difference: bad style and ignorance go together like love and marriage, and the upshot is the same in any case -- strive to understand what the language affords and your expression will improve automatically, but the expression itself is a learning experience and good style is the aesthetic confirmation that you've understood.
Subscribe to:
Comments (Atom)