All your metaphors about computers are wrong | Hacker News Reader

All your metaphors about computers are wrong

blog.scaramanga.co.uk

34 pointscomice16 comments

What's the point ? Of course all metaphors are wrong and none is a demonstration.

But metaphors are great tools, if wisely used, to reuse mental patterns and find ways to use new tools. What would be the computer without the metaphors of the windows, buttons, files, and so on ?

If the computer understood natural language, you wouldn't need most of the GUI elements commonly used today, like windows and buttons.

Our brains also don't use files and folders, these metaphors having a direct analogy to our physical world in which we need to group things for easy access and distribution, however we are limited by the constraints of our world and the way we interact with it, constraints that will sooner or later vanish and pretty soon files and folders won't make much sense anymore.

A computer is a machine for following instructions. At first it only knows a limited set of logical and arithmetical instructions. You can use these instructions to teach it new things to do, and new commands to follow (and if you buy a computer, somebody probably already has). However, if you phrase these instructions wrong, it will do what you say rather than what you mean.

So you could say that programming a computer is like training a new soldier or worker, and using a computer is like being in command.

Computers are an extension of consciousness. What I believe the author is trying to say is that programming is more than just a skill task. It is akin to giving someone hands in a handless world allowing people to manipulate their environment.

Metaphors about computers may be wrong...though the metaphor of architecture seems apt (even in light of my personal bias).

Metaphors using computers as a model for the mind are more interesting, because such metaphors follow a long tradition of equating the mind to technologically advanced systems.

Brain as computer metaphors are just the contemporary version of brain as hydraulics (e.g. Avicenna's humorism) or the more recent brain as mechanics (e.g. Leibniz's mill). Turing's test and Searle's Chinese room are relevant thought experiments pointing out the problems inherent in mapping systems to thought.

Learning to use computers is like learning reading and writing. Learning to program computers is like learning papermaking and typesetting and bookbinding. The metaphor does hold.

I think in these metaphors it's important to draw a line somewhere between "to use" and "to program". That line isn't always clear -- the usual example being an Excel spreadsheet.

Using an application is like programming in its language of pushbuttons and input fields. Programming is like using a compiler.

Since when could books execute computations that their readers don't understand?

You could perhaps argue that books sometimes contain instructions that readers execute but don't necessarily understand.

True, but it misses the central point that books don't execute anything themselves, and so computers are fundamentally different from them.

The metaphors are not fully isomorphic analogies, but they can still be helpful. Framing programming ability as being a form of modern literacy, for instance, conveys more urgency to the public.

When they start actually programming, these metaphors will leave their mind and they'll focus on the concretes, or at least find better metaphors.

I think the only worry comes from basing long term policy decisions on crude metaphors.

Exactly. People - we computer programmer magicians included - understand new things by relating them to other things that they already know. I expect there are readers (or viewers) of the BBC or The Guardian who only know that programmers do things with computers. That is the entire breadth of their knowledge of computer programming. These metaphors help them frame this new information in terms of things they already understand.

As a person in the comments references from Steve Jobs "The computer is a bicycle for the mind."

I think that is the best metaphor for a computer I've ever heard. But I'd say the increase in potential a computer brings is more like from walking to flying via a plane than from walking to cycling. Even so, that really is a quote I'll be keeping in mind.

One of the metaphors that I think is most damaging is inherent in the way most decision-makers think of programming languages-- the decision is treated as comparable to the selection process for natural languages, which is trivial and obvious for natural languages but very complicated for PL.

With natural languages (a) there aren't order of magnitude differences in power or quality, and (b) the switching costs associated with becoming fluent in a new one are very high, so businesses usually default (without conscious choice) to "the standard", which is the language most familiar to the people in that location. (In New York, that's English; in Tokyo, it's Japanese.) For natural languages, this is the obvious right decision.

When this metaphor is taken literally and applied to PL selection, it results in Java and C++ being used, because those languages are "the standard". The difference is that, (a) there are languages that are orders of magnitude better-- just compare Scala against Java-- than mainstream PL, and (b) switching costs are a lot more moderate. Using "the standard" in PL, for a new company, is a horrible decision; you won't even get off the ground if you start in Java or C++.

Oddly enough, the term "programming language" is, technically speaking, completely correct (a PL is a language) but metaphorically detrimental.

"There are 2 hard problems in computer science: caching, naming, and off-by-1 errors."

Is there a better name for "programming language" that avoids the problem of association with natural language?

I would say "platform" in these discussions since that's what we're actually comparing in practice when we're arguing about what technologies to use for business. By 2006, it was obvious that Java-the-language was deficient in comparison to alternatives like Python and Ocaml, but people (and here I include smart people who understand technology) continued to prefer it because it had the best libraries.

Paul Graham argued that language fundamentals matter more than libraries and tooling. This was true in his case (Viaweb) but it's not true in general and for long-term adoption trends, which are dominated by small, part-time projects (innovators and early adopters) for which having to write a bunch of libraries (CSV parsers, for example) that already exist in Java would be a killer.

Java won the late '90s and 2000s because of the platform, not the language. The language sucks, and even by the standards of 2005 (when Scala was immature and Clojure didn't exist) it sucked, but it had the best tooling and therefore won.

Reply on news.ycombinator.com