— Вчера попробовал
сигареты с фильтром.
— Ну, и как они?
— Сначала куришь фильтр,
а затем — как обычно.
Грустный анекдот
Только вряд ли она, эта замечательная черта, хороша в одном из своих крайних
проявлений — в ситуации, когда забываются идеи, заложенные в инструмент изначально.
Вот тогда различные высокие технологии (вроде модульной программной архитектуры
или колеса) используются хоть и по назначению, но зачастую — слишком неэффективным
образом, что нередко сводит на нет все достоинства воплощенных концепций. Это
неизменно происходит, когда различные продукты полета инженерной мысли несутся
в массы, которые не желают знакомиться с предлагаемыми парадигмами и предпочитают
им односложные оценки "хорошо/плохо".
"While in Rome, do as Romans do"
Есть такой философский принцип: не создавать лишних сущностей. Концепция
конструктора, изначально заложенная разработчиками в Unix, многими считается
одним из самых удачных продуктов полета мысли, присутствующих в современных
ОС. Дробление инструментария до уровня команд, выполняющих простые действия,
с последующим построением из них нужных программных конфигураций позволяет избавиться
от дублирования уже реализованной функциональности. Вы когда-нибудь ловили себя
на мысли о том, что инструментальная среда Unix в чем-то повторяет концепцию
аналоговых вычислительных машин со всеми достоинствами такой модели?
Позволю себе привести небольшой пример из жизни: как-то раз появилась необходимость
сделать копии трех десятков статей из последнего номера "Компьютерного
Обозрения", чтобы обеспечить себя чтением на пару недель отпуска. Используя
любой модный на сегодняшний день броузер или менеджер загрузок, пришлось бы
ровно 30 раз набирать URL вида "https://itc.ua/print.phtml?ID=X", где
"X" — номер статьи с различными числовыми значениями, либо поработать
мышью (кстати, еще неизвестно, что проще). Времени на это, понятное дело, ушло
бы достаточно много, и спасти от скуки и разочарования в таком случае может
лишь упорство либо гибкость инструментария. Последний аспект неплохо иллюстрирует
следующая команда:
jot 30 6013 | xargs -i echo https://itc.ua/print.phtml?ID=itc_drupal_ | wget -x |
Результат ее выполнения аналогичен результату 30 команд вида:
wget -x -p -k https://itc.ua/print.phtml?ID=6013 |
Я нарочно опустил один аргумент программы wget, делающий подобную загрузку именно
с сайта ITC Online возможной, поскольку этот пример был приведен лишь для того,
чтобы показать, насколько выгодно сохранять целостность всей системы при разработке
новых ее составляющих (а устанавливая приложение на компьютер, вы в любом случае
делаете его компонентом всей системы).
"Перловая каша" Ларри Уолла
Вне зависимости от того, чем является язык Perl в настоящее время, изначально
Ларри Уолл "поплыл против течения" — он написал программу, повторяющую
возможности двух уже имеющихся в системе (а именно — sed и awk), вместо того,
чтобы реализовать только нужную функциональность. Не исключено, что можно было
бы вообще ограничиться совершенствованием уже существующих компонентов. Сейчас
же Perl представляет собой "систему в системе" — многообразие модулей
обеспечивает язык достаточно мощными инструментами, но ограничивает область
их применения только самим Perl. При этом многие программисты признают, что
используют Perl лишь для выполнения небольших задач — таких, для которых вполне
хватило бы связки shell+sed+ awk, и, при необходимости, нескольких дополнительных
(но уже существующих в системе, а зачастую — стандартных) инструментов.
Примерно та же картина наблюдается и с языком Python, а в последнее время (к
сожалению) — и с Tcl, который изначально задумывался как "клей" для
инструментария Unix. Но в последнем случае, в отличие от Perl и, особенно, Python,
огромное количество расширяющих функциональность модулей не включается в базовую
поставку языка, что позволяет при желании получить чистый "клей" без
лишних "примесей".
Полковник, вам пакет…
Очень забавной является полная неспособность людей воспринимать
отсутствие проблем. В таком случае проблемы придумываются.
Еще забавней мне кажется способность искренне наслаждаться жизнью дальше после
того, как нужное количество проблем было изобретено.
Квинт Моррис
На написание этого раздела меня натолкнула давно бросающаяся в глаза ситуация
с системами бинарных пакетов для современных Unix-подобных ОС. Это еще одна
область, в которой разработчики следуют порывам "юношеского максимализма",
подвигающим их делать "Yet-Another-Нечто", не несущее в себе ничего
нового, оригинального, более эффективного (кроме, конечно, ублажения собственного
эго). Номинантом на "премию Дарвина" в этом случае является система
Fink для Mac OS X/Darwin. Видимо, ее авторы просто не пожелали знакомиться с
уже существующими в "десятке" инструментами.
Попробуйте распаковать пакет формата RPM, скажем, в Debian Linux. Или, что еще
нагляднее, — в NetBSD, не устанавливая новых программ, не плодя лишних сущностей
в виде инструментов, принадлежащих к категории third-party. С другой стороны,
система пакетов Net/Open/FreeBSD, не ушедшая от формата tar(.gz), не привносит
подобных несовместимостей с прочими Unix-подобными ОС.
Простая, эффективная и, что самое главное, лаконичная и строго следующая идеям
Unix система бинарных пакетов строится с помощью средств самой Unix, "в
миниатюре" — это find, xargs, sed и tar. Создается пакет одной командой,
из "родного" каталога, устанавливается и удаляется — тоже, распаковывается
практически на любой (в том числе и не-Unix) системе. Идеи, в чем-то родственные
этой, реализованы в ОС Solaris, QNX и Plan9 (причем в двух последних — достаточно
изящно) и при переносе в Unix избавляют от необходимости использовать sed и
переменные окружения, применяя вместо них mount и псевдофайловые системы loopback
и union. Хотя ни в одной из них подсистема пакетов не является даже близкой
к совершенству.
Итого…
Создается впечатление, что девизом большинства современных "Unix-тусовок"
является фраза "зачем просто, если можно сложно". При этом весьма
грустно смотреть, как спорит молодежь на форумах по вопросу: "Годится ли
Linux (Unix) для десктопов?", используя в качестве аргумента наличие программ
с GUI-интерфейсом (следующим концепции WYSIWYG) и даже способных (!) открыть
файл, созданный в ПО от фирмы Microsoft. При этом напрочь забывается тот факт,
что программам, не имеющим полноценного интерфейса командной строки, как это
ни грустно, нет места в достаточно стройной парадигме Unix-систем.
Но Unix — отнюдь не единственная область, где активно предаются забвению начальные
концепции. Обратите внимание, скажем, на современных Web-дизайнеров, HTML-кодеров
и прочих сайтостроителей, оперирующих информацией в формате HyperText Markup
Language. Этот язык изначально задумывался для логической разметки, и стандарт
HTML 4.0 вместе с CSS был призван окончательно разделить текст и оформление.
Что получилось в результате — видно почти на каждом сайте. CSS сразу был воспринят
всеми как отличное оформительское средство, но о первоначальной идее многие
позабыли. Например, зачастую встречается ситуация, когда в онлайновых документах
для полей "автор" и "тип" используется один и тот же CSS-класс.
В результате, скажем, при автоматическом анализе страниц с помощью скриптов
очень сложно отличить одно от другого. Два поля оказываются связанными по оформлению,
что возвращает нас к WYSIWYG-системам, к которым язык HTML не имеет отношения.
Куда логичней было бы, например, сделать два класса — "author" и
"type", раз и навсегда разграничив поля по смыслу. Но это уже — чистая
лирика…
E-mail автора: [email protected]