Technological change is ecological

From Neil Postman:

Technological change is neither additive nor subtractive. It is ecological. … One significant change generates a total change. If you remove the caterpillars from a given habitat, you are not left with the same environment minus caterpillars: you have a new environment … In the year 1500, fifty years after the printing press was invented, we do not have old Europe plus the printing press. We had a different Europe. After television, the United States was not America plus television; television gave a new coloration to every political campaign, to every home, to every school, to every church, to every industry.


C. S. Lewis’ description of George MacDonald from his introduction to Phantastes:

His resignation to poverty was at the opposite pole from that of the stoic. He appears to have been a sunny, playful man, deeply appreciative of all really beautiful and delicious things that money can buy, and no less deeply content to do without them.

Advantages of everything-is-text

In a typical Windows program, some output text can be copied as text but some is only an image. For example, the text in the body of a document is text, but the words on the menus are not. The text in a dialog box may or may not be.

In Emacs, text is just text, no matter where you see it. This means that Emacs is less visually interesting because there is less variety. But this also has several advantages that may not be immediately obvious. I’ll give a couple examples.

The Emacs directory editor dired lists files in a text buffer. The output is essentially the output of ls. (On Windows, Emacs emulates ls.) That means you can do anything to the output you could do to text: copy, paste, search, etc. No text is off-limits. And in editable mode, you can rename files just by editing their names. You could, for example, rename many files at once using regular expressions.

Dired also lets you navigate the file system with the same commands you use to edit files. In particular, you can keep your hands on the keyboard. (It’s possible to use the Windows file explorer without a mouse, but it’s limited and awkward.)

Another advantage of everything simply being text is that you can run a shell inside Emacs. Why not? A shell is just text output. In an ordinary shell, editing commands are mostly limited to the current line. Not all text is created equal. But when you’re running a shell inside an editor, all text is equal: current line, previous lines, and text on either side of the command prompt. And if you want a transcript of a shell session, just save the buffer displaying the session.

If you’re shopping for a text editor and spend an hour trying each one out, Emacs may not look very promising. It has odd terminology, weird key strokes, etc. But if you try Emacs long enough, and particularly if you have someone to help you get started, you start to appreciate the advantages of subtle features such as everything simply being a text buffer.

Related posts:

Flannery O’Connor’s accent

When Flannery O’Connor went to the University of Iowa for graduate school, her mentor Paul Engle could not understand her Georgian accent. Engle later recalled his reaction when she asked to attend his workshop.

Embarrassed, I asked her to write down what she had just said on a pad. …

Like Keats, who spoke Cockney but wrote the purest sounds in English, Flannery spoke a dialect beyond instant comprehension but on the page her prose was imaginative, tough, alive: just like Flannery herself.

Source: Flannery O’Connor: The Complete Stories.

Here is a recording of O’Connor reading her story A Good Man is Hard to Find. I don’t find her at all hard to understand. The recording was made 13 years after her first encounter with Engle, and perhaps her accent had moderated. Or perhaps my ears are simply accustomed to Southern speech.

Most popular non-technical posts of 2011

These were my most popular blog posts this year that were not about math or programming.

The music post was from 2009, but it still gets a lot of hits.

If you’re interested in the non-technical posts here, check out the Facebook page for the blog. There I announce new posts of general interest and link to some previous posts.


Maker’s desiderata

A few years ago Make Magazine posted The Maker’s Bill of Rights. I like the list, though I don’t like the name.

  • Meaningful and specific parts lists shall be included.
  • Cases shall be easy to open.
  • Batteries should be replaceable.
  • Special tools are allowed only for darn good reasons.
  • Profiting by selling expensive special tools is wrong and not making special tools available is even worse.
  • Torx is OK; tamperproof is rarely OK.
  • Components, not entire sub-assemblies, shall be replaceable.
  • Consumables, like fuses and filters, shall be easy to access.
  • Circuit boards shall be commented.
  • Power from USB is good; power from proprietary power adapters is bad.
  • Standard connecters shall have pinouts defined.
  • If it snaps shut, it shall snap open.
  • Screws better than glues.
  • Docs and drivers shall have permalinks and shall reside for all perpetuity at
  • Ease of repair shall be a design ideal, not an afterthought.
  • Metric or standard, not both.
  • Schematics shall be included.

I don’t like calling this a “bill of rights” because of the moral and legal overtones. The things in this list are not rights. They are generally desirable characteristics, and that’s what desiderata means.

Calling the list a maker‘s bill of rights is a little curious. It’s a list of things that some consumers look for in suppliers, namely consumers who call themselves “makers.” But suppliers are literally makers: they make things that makers want to open and tinker with.

Propaganda and chocolate

In his book China Road, Rob Gifford mentions the odd mixture of government propaganda and commercial advertising he saw flashed on the side of a building in Shanghai every five seconds.

  • Welcome to Shanghai. Tomorrow will be even more beautiful.
  • 1,746 days until the Shanghai World Expo.
  • Sexual equality is a basic policy in our country.
  • Eat Dove chocolate.

Convention versus compulsion

An alternate title for this post could be “Software engineering wisdom from a lecture on economics given in 1945.”

F. A. Hayek gave a lecture on December 17, 1945 entitled “Individualism: True and False.” A transcript of the talk is published in his book Individualism and Economic Order. In this talk Hayek argues that societies must decide between convention and compulsion as means to coordinate activity. The former is preferable, in part because it is more flexible. Individualism depends on

… traditions and conventions which evolve in a free society and which, without being enforceable, establish flexible but normally observed rules that make behavior of other people predictable in a high degree.

Of course Hayek wasn’t thinking of software development, but his comments certainly are applicable to software development. Software engineers are fond of flexibility, but suspicious of rules that cannot be enforced by a machine. And yet there are some kinds of flexibility that require traditions and conventions rather than enforceable rules. Hayek looks beyond the letter of the law to the spirit: the purpose of rules in software engineering is to make the behavior of software (and software engineers) “predictable in a high degree.”

I’ve written a couple blog posts on this theme. One was Software architecture as a function of trust:

If you trust that your developers are highly competent and self-disciplined, you’ll organize your software differently than if you assume developers have mediocre skill and discipline. One way this shows up is the extent that you’re willing to rely on convention to maintain order. … In general, I see more reliance on convention in open source projects than in enterprise projects.

Another was a post on the architecture of Emacs:

In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.

The quotation from Hayek above continues:

The willingness to submit to such rules, not merely so long as one understands the reason for them but so long as one has no definite reason to the contrary, is an essential condition for the gradual evolution and improvement of rules of social intercourse … an indispensable condition if it is to be possible to dispense with compulsion.

Imagine a rookie programmer who joins a new team and only follows those conventions he fully understands. That’s not much better than the rookie doing whatever he pleases. The real benefit comes from his following the conventions he doesn’t yet understand (provided he “has no definite reason to the contrary”) because these distill the ideas of more experienced developers.

It takes time to pass on a set of traditions and conventions, especially to convey the rationale behind them. Machine-enforceable rules are a shortcut to establishing a culture.

Every project will be somewhere along a continuum between total reliance on convention and total reliance on rules a computer can check. Emacs is pretty far toward the conventional end of the spectrum, and enterprise Java projects are near the opposite end. If you want to move away from the compulsion end of the spectrum, you need more emphasis on convention.

Related post: Style and understanding


Many so-called leadership positions are followship positions.

One way musicians learn to conduct is by conducting recordings. We did this at drum major camp back in the days of vinyl albums and cassette tapes. That’s OK for teenagers who are just learning the basic motions of conducting, but it’s not how real conductors are trained.

When you conduct a recording, you’re not leading, you’re following. Conducting recordings teaches you implicitly to expect to be ignored. Real conductors train by conducting a pianist or a small ensemble. They expect to be followed, and they learn the consequences of their actions.

I use followship to describe inverted leadership. This happens when someone appears to be leading when in fact they’re following. Conducting a CD is followship. So is managing a team by keeping records of what the team has done rather than giving direction. Supposed leadership positions in business are often followship positions.

Followship is reactive, not interactive. Imagine an orchestra recording a CD. The musicians in the studio follow the conductor in a fundamentally different way than the music student following the CD. The musicians interact with the conductor. The student doesn’t interact with the CD.

Followship is not simply bad leadership. Followship is passive. Bad leadership is active.

When I was drum major in high school, one night I started our half time show way too fast. The color guard dropped their rifles several times during the performance and it was my fault. Their routine could not be performed at the tempo I had set. That was bad leadership on my part, but it was genuine leadership because the band followed my lead.

Leadership mistakes are embarrassing, but followship is even more embarrassing. It’s easier to admit a mistake than to admit being ineffectual.

Related post: Engineering route to accounting

Most popular programming posts of 2011

These have been my most popular programming-related posts this year.

My favorite on the list is #5.

Post #4 was written in 2009, but it got a lot of traffic this year.

Thanks to everyone who shared these posts on Hacker News, Reddit, Twitter, etc.

How to know it all

The way to know it all is to change the definition of “all.” Schools do this, for example, by defining “all” to mean everything on a test. Then it’s possible for someone to know it all. Schools create the illusion that the world is finite. You may not know everything, but someone does.

The desire to know it all is pernicious. The only way to accomplish it is to shrink your world. That may be OK for a while to focus your attention. The danger is that you can succeed and forget that you started by drawing arbitrary boundaries.

When I was very young, I thought that if I read every volume of the World Book Encyclopedia, I’d know everything. Of course I wouldn’t know everything, only what the editors of the encyclopedia chose to include.

If you want to learn English by first learning all the vocabulary, you’ll never speak English. Even if you learn every word in a particular dictionary, you still haven’t learned every word in the language.

Computer languages are orders of magnitude simpler than human languages, but they’re still too complex to learn exhaustively. If you want to learn every nuance of C++ before writing programs, you’ll never write a program. And if you think this is because C++ is a large language, it’s hardly possible to understand C exhaustively either if you take into account all the subtleties of how features are actually implemented on various platforms.

A common problem in math is how to select a finite sample from an infinite space. Maybe you have a function defined at an infinite number of points and you want to approximate it by sampling it at a carefully chosen finite set of points. This is a good metaphor for life.

Even when things are finite, it’s often very practical to think of them as being infinite. (See Infinite is easier than big.) Many aspects of life are effectively infinite.

Related post: Evaluate people at their best or at their worst?