Neal Stephenson - In the Beginning was the Command Line

Здесь есть возможность читать онлайн «Neal Stephenson - In the Beginning was the Command Line» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Жанр: Фантастика и фэнтези, на английском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

In the Beginning was the Command Line: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «In the Beginning was the Command Line»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

In the Beginning was the Command Line — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «In the Beginning was the Command Line», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

The OS has (therefore) become a sort of intellectual labor-saving device that tries to translate humans' vaguely expressed intentions into bits. In effect we are asking our computers to shoulder responsibilities that have always been considered the province of human beings--we want them to understand our desires, to anticipate our needs, to foresee consequences, to make connections, to handle routine chores without being asked, to remind us of what we ought to be reminded of while filtering out noise.

At the upper (which is to say, closer to the user) levels, this is done through a set of conventions--menus, buttons, and so on. These work in the sense that analogies work: they help Eloi understand abstract or unfamiliar concepts by likening them to something known. But the loftier word "metaphor" is used.

The overarching concept of the MacOS was the "desktop metaphor" and it subsumed any number of lesser (and frequently conflicting, or at least mixed) metaphors. Under a GUI, a file (frequently called "document") is metaphrased as a window on the screen (which is called a "desktop"). The window is almost always too small to contain the document and so you "move around," or, more pretentiously, "navigate" in the document by "clicking and dragging" the "thumb" on the "scroll bar." When you "type" (using a keyboard) or "draw" (using a "mouse") into the "window" or use pull-down "menus" and "dialog boxes" to manipulate its contents, the results of your labors get stored (at least in theory) in a "file," and later you can pull the same information back up into another "window." When you don't want it anymore, you "drag" it into the "trash."

There is massively promiscuous metaphor-mixing going on here, and I could deconstruct it 'til the cows come home, but I won't. Consider only one word: "document." When we document something in the real world, we make fixed, permanent, immutable records of it. But computer documents are volatile, ephemeral constellations of data. Sometimes (as when you've just opened or saved them) the document as portrayed in the window is identical to what is stored, under the same name, in a file on the disk, but other times (as when you have made changes without saving them) it is completely different. In any case, every time you hit "Save" you annihilate the previous version of the "document" and replace it with whatever happens to be in the window at the moment. So even the word "save" is being used in a sense that is grotesquely misleading---"destroy one version, save another" would be more accurate.

Anyone who uses a word processor for very long inevitably has the experience of putting hours of work into a long document and then losing it because the computer crashes or the power goes out. Until the moment that it disappears from the screen, the document seems every bit as solid and real as if it had been typed out in ink on paper. But in the next moment, without warning, it is completely and irretrievably gone, as if it had never existed. The user is left with a feeling of disorientation (to say nothing of annoyance) stemming from a kind of metaphor shear--you realize that you've been living and thinking inside of a metaphor that is essentially bogus.

So GUIs use metaphors to make computing easier, but they are bad metaphors. Learning to use them is essentially a word game, a process of learning new definitions of words like "window" and "document" and "save" that are different from, and in many cases almost diametrically opposed to, the old. Somewhat improbably, this has worked very well, at least from a commercial standpoint, which is to say that Apple/Microsoft have made a lot of money off of it. All of the other modern operating systems have learned that in order to be accepted by users they must conceal their underlying gutwork beneath the same sort of spackle. This has some advantages: if you know how to use one GUI operating system, you can probably work out how to use any other in a few minutes. Everything works a little differently, like European plumbing--but with some fiddling around, you can type a memo or surf the web.

Most people who shop for OSes (if they bother to shop at all) are comparing not the underlying functions but the superficial look and feel. The average buyer of an OS is not really paying for, and is not especially interested in, the low-level code that allocates memory or writes bytes onto the disk. What we're really buying is a system of metaphors. And--much more important--what we're buying into is the underlying assumption that metaphors are a good way to deal with the world.

Recently a lot of new hardware has become available that gives computers numerous interesting ways of affecting the real world: making paper spew out of printers, causing words to appear on screens thousands of miles away, shooting beams of radiation through cancer patients, creating realistic moving pictures of the Titanic. Windows is now used as an OS for cash registers and bank tellers' terminals. My satellite TV system uses a sort of GUI to change channels and show program guides. Modern cellular telephones have a crude GUI built into a tiny LCD screen. Even Legos now have a GUI: you can buy a Lego set called Mindstorms that enables you to build little Lego robots and program them through a GUI on your computer.

So we are now asking the GUI to do a lot more than serve as a glorified typewriter. Now we want to become a generalized tool for dealing with reality. This has become a bonanza for companies that make a living out of bringing new technology to the mass market.

Obviously you cannot sell a complicated technological system to people without some sort of interface that enables them to use it. The internal combustion engine was a technological marvel in its day, but useless as a consumer good until a clutch, transmission, steering wheel and throttle were connected to it. That odd collection of gizmos, which survives to this day in every car on the road, made up what we would today call a user interface. But if cars had been invented after Macintoshes, carmakers would not have bothered to gin up all of these arcane devices. We would have a computer screen instead of a dashboard, and a mouse (or at best a joystick) instead of a steering wheel, and we'd shift gears by pulling down a menu:

PARK --- REVERSE --- NEUTRAL ---- 3 2 1 --- Help...

A few lines of computer code can thus be made to substitute for any imaginable mechanical interface. The problem is that in many cases the substitute is a poor one. Driving a car through a GUI would be a miserable experience. Even if the GUI were perfectly bug-free, it would be incredibly dangerous, because menus and buttons simply can't be as responsive as direct mechanical controls. My friend's dad, the gentleman who was restoring the MGB, never would have bothered with it if it had been equipped with a GUI. It wouldn't have been any fun.

The steering wheel and gearshift lever were invented during an era when the most complicated technology in most homes was a butter churn. Those early carmakers were simply lucky, in that they could dream up whatever interface was best suited to the task of driving an automobile, and people would learn it. Likewise with the dial telephone and the AM radio. By the time of the Second World War, most people knew several interfaces: they could not only churn butter but also drive a car, dial a telephone, turn on a radio, summon flame from a cigarette lighter, and change a light bulb.

But now every little thing--wristwatches, VCRs, stoves--is jammed with features, and every feature is useless without an interface. If you are like me, and like most other consumers, you have never used ninety percent of the available features on your microwave oven, VCR, or cellphone. You don't even know that these features exist. The small benefit they might bring you is outweighed by the sheer hassle of having to learn about them. This has got to be a big problem for makers of consumer goods, because they can't compete without offering features.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «In the Beginning was the Command Line»

Представляем Вашему вниманию похожие книги на «In the Beginning was the Command Line» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «In the Beginning was the Command Line»

Обсуждение, отзывы о книге «In the Beginning was the Command Line» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x