Три заблуждения теории вычислительной техники

From The Joel on Software Translation Project

Jump to: navigation, search

Автор: Joel Spolsky

В оригинале статья называлась "Three Wrong Ideas From Computer Science" и была написана 22 августа 2000 года

Не хочу омрачать ничьей радости, но есть три важные идеи из теории вычислительной техники, которые, прямо скажем, ошибочны, и люди начинают это замечать. Можете пренебрегать ими на ваш страх и риск.

Я уверен, что заблуждений больше, но эти три больше всего сводят меня с ума:

  1. Самая сложная часть в поиске - найти побольше результатов.
  2. Сглаженный (anti-aliased) текст выглядит лучше
  3. Программы для работы с сетью должны представлять удалённые ресурсы так, как будто они являются локальными.

Хорошо, всё, что я могу сказать, это

  1. Неверно
  2. Неверно
  3. Неверно !

Давайте коротко пройдёмся по этим вопросам.

Поиск

Большинство академических работ о поиске прямо-таки одержимы проблемами, типа "что случится, если вы ищете 'машина', а документ, который вам нужен содержит 'автомобиль'".

Конечно, существует ужасное количество академических исследований по концепциям, вроде "морфологический поиск", где для слова, по которому вы ищете находится начальная форма (de-conjugated), так что поиск по слову "поиск" находит также документы содержащие слова "искомое" и "искал".

Так что, когда в Интернете появились первые крупные поисковики, типа Альтависты (Altavista), они хвастались несметными мириадами найденных ссылок. Поиск в Альтависте по "Joel on Software" выдаёт 1,033,555 страниц (прим. перев.: это было давно, в день редакции таких страниц было 11,000,000, но оригинальный сайт был на втором месте после ссылки на его же книгу на Amazon, хотя раньше всё было не так хорошо). Что, разумеется, бесполезно. Интернет, возможно, содержит миллиарды страниц. Сократив поиск с одного миллиарда страниц до одного миллиона, Альтависта абсолютно ничего мне не дала. Реальная проблема поиска заключается в том, как упорядочить результаты. В защиту computer science (прим. перев.: кто знает адекватный перевод?) следует заметить, что никто даже не замечал такой проблемы, пока не начали индексировать такой гигант как Интернет. Хотя кто-то всё же заметил. Ларри Пейдж (Larry Page) и Сергей Брин (Sergey Brin) основатели Google осознали, что правильное ранжирование страниц гораздо важнее, чем просто обработка каждой доступной страницы. Их алгоритм PageRank огромный шаг вперёд на пути упорядочивания мириад результатов так, что тот, который вам нужен, вероятно будет в первой десятке. Действительно, поищите Joel on Software в Google, и вы увидите, что он является первым. В Альтависте он даже не на первых пяти страницах (см. примечание выше), после которых я забросил поиск. 36088069933363186858555

Сглаживание текста

Идея сглаживания (anti-aliasing) текста была придумана в далёком 1972 году в MIT (Massachusetts Institute of Technology) в Architecture Machine Group, которая позже стала основной частью знаменитой Media Lab. Идея заключалась в том, что если у вас есть цветной дисплей с низким разрешением, то с помощью оттенков серого можно создавать иллюзию большего разрешения. Это выглядит примерно так:

Antialiasing.gif

Заметьте, что нормальный текст слева контрастный и чёткий, а сглаженный текст справа кажется размытым на краях. Если вы прищуритесь или немного отойдёте, то нормальный текст будет иметь явную "лесенку" по краям из-за низкого разрешения. А сглаженный текст будет выглядеть более гладким и приятным. Вот почему все были в восторге от сглаживания. Сейчас оно везде. Microsoft даже включило в Windows специальный переключатель, позволяющий включить сглаживание во всей системе. Проблемы? Если вы попытаетесь прочитать абзац сглаженного текста, то заметете, что он выглядит слегка размыто. И я ничего не могу поделать с этим - это правда. Сравните эти два абзаца:

Antialised_Paragraph.gif

Абзац слева без сглаживания; абзац справа сглажен в Corel PHOTO-PAINT. Честно говоря, сглаженный текст выглядит хуже. В конце-концов кое-кто это заметил: Microsoft Typography group. Они создали несколько отличных шрифтов таких как Verdana или Georgia, которые "созданы специально для удобства чтения с экрана". Вместо создания шрифтов с высоким разрешением и попыток всунуть их в решётку пикселей, они просто приняли решётку пикселей как данность и разработали шрифты, которые чётко ей соответствуют. А кто-то не заметил этого: Microsoft Reader group, которая использует разновидность сглаживания, которую они называют "ClearType", разработанную для ЖК-мониторов, и которая, вы меня извините, всё равно выглядит размытой даже на цветных ЖК-мониторах.

(Пока я ещё не начал получать кучу гневных откликов от профессионалов графики среди моих читателей, я должен заметить, что сглаживание действительно отличная штука для двух вещей: заголовков и логотипов, где общее впечатление важнее удобства длительного чтения; и рисунков. Сглаживание - отличный способ масштабировать рисунки с уменьшением размеров.)

Прозрачность сети

С самого начала создания первой сети, Святым Граалем сетевых вычислений было предоставления программных интерфейсов для доступа к удалённым сетевым ресурсам таким же образом, как к локальным. Сеть становится "прозрачной".

Один пример прозрачности сети - знаменитый RPC (удалённый вызов процедур, remote procedure call), система разработанная для того, чтобы вы могли вызывать процедуры (подпрограммы), выполняющиеся на другом компьютере, по сети точно так же, как если бы они выполнялись локально. На это угробили чёртову пропасть энергии. Другой пример, основанный на RPC, это Distributed COM от Microsoft (DCOM), благодаря которому вы можете иметь доступ к объектам, которые исполняются на другом компьютере так, как будто они выполняются на этом компьютере.

Звучит логично, правильно?

Неправильно.

Существует 3 значительных отличия между доступом к удалённым и к локальным ресурсам:

  1. Доступность
  2. Латентность
  3. Надёжность

Когда вы обращаетесь к другому компьютеру по сети, существует немаленькая вероятность того, что этот компьютер будет недоступен или сеть будет недоступна. А скорость передачи по сети означает, что весьма вероятно запрос займёт порядочно времени: ведь вы можете работать через 28.8kb/s модем. Или удалённая машина может "упасть" или может пропасть сетевое соединение, пока вы обращаетесь к другому компьютеру (когда кошка будет ходить по телефонному проводу). Любое надёжное ПО, которое работает по сети, обязательно должно явно это учитывать. Использование программных интерфейсов, которые скрывают все эти особенности - отличный путь, чтобы написать никуда не годную программу. Простенький пример: представьте, что мне нужна программа, которая копирует файлы по сети с одного компьютера на другой. В платформе Windows старый добрый "прозрачный" способ сделать это - это вызвать стандартную функцию CopyFile, использую UNC-имя файлов, например \\SERVER\SHARE\Filename. Если с сетью всё в порядке, то это работает просто замечательно. Но, если файл имеет мегабайтовые размеры, а доступ к сети осуществляется с помощью модема, то всё идёт неправильно. Всё приложение зависает на время передачи. При этом нет никакого способа сделать индикатор прогресса потому, что, когда CopyFile разрабатывалась, то рассчитывали на то, что она всегда будет "быстрой". Кроме того, нет способа возобновить передачу, если телефонное соединение разорвалось. На самом деле, если вы хотите передавать файлы по сети, лучше использовать API вроде FtpOpenFile и других сопутствующих функций. Нет, это не то же самое, как копировать файлы локально, это труднее использовать, но эти функции были созданы со знанием того, что сетевое программирование отличается от локального, и он (API) предоставляет ловушки (hooks) для создания индикатора прогресса, для обработки неудач, если сеть недоступна или упадёт, и для асинхронной работы.

Заключение: В следующий раз, когда кто-то попытается продать вам программный продукт, который позволяет вам обращаться к сетевым ресурсам также как к локальным, убегайте как только можете в противоположном направлении.

---

Personal tools