Эрик Реймонд - Искусство программирования для Unix

Рассмотрим, например, разработку программы захвата изображений для цифровой камеры. Зачем создавать собственный формат для сохранения изображений или покупать коммерческий код, когда (как было сказано в главе 5) существует многократно проверенная, полнофункциональная библиотека для записи PNG-изображений, реализованная в открытом исходном коде?

Создание (или воссоздание) открытого исходного кода также оказало значительное влияние на процесс стандартизации. Несмотря на то, что это не является официальным требованием, IETF приблизительно с 1997 года все больше сопротивляется превращать в стандарты документы RFC, которые не имеют по крайней мере одной эталонной реализации с открытым исходным кодом. В будущем кажется вполне вероятным, что степень соответствия любому определенному стандарту будет все больше измеряться соответствием реализациям с открытым исходным кодом, которые были одобрены авторами стандарта.

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

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

До конца 90-х годов данная рекомендация была бы невыполнимой. Несколько альтернатив частных операционных систем и средств разработки были "благородными экспериментами", подтверждениями академических идей или "игрушками". Но Internet изменил все. В середине 2003 года Linux и другие Unix-системы с открытым исходным кодом доказали свою стойкость как платформы для создания программного обеспечения промышленного качества. В настоящее время разработчики имеют лучшую альтернативу, чем зависимость от краткосрочных бизнес- решений, направленных на защиту чужой монополии. Применяйте защищенные конструкции — создавайте программы на основе открытого исходного кода и вы не попадете в безвыходное положение.

Первым применением Unix в 1971 году была платформа для компоновки документов — Bell Labs использовала ее для подготовки патентных документов в целях составления картотеки. Фотонабор, управляемый компьютером, все еще оставался тогда новой идеей, и на несколько лет после своего дебюта в 1973 году форматер, который создал Джо Оссана (Joe Ossana), troff(1), определил уровень техники.

С тех пор сложные форматеры документов, программное обеспечение для набора, а также различные программы макетирования страниц занимают важное место в традициях Unix. Хотя troff(1) доказал свою удивительную долговечность, в Unix также поддерживается значительная работа в данной прикладной области. Сегодня Unix-разработчики и Unix-инструменты находятся на передовом рубеже далеко идущих перемен в практике создания документов, началом которой послужило появление World Wide Web.

На уровне пользовательских представлений с середины 1990-х годов практика сообщества Unix быстро смещается в направлении идеи "все документы — HTML, все ссылки — URL". Более того, современные программы для просмотра справочной информации в Unix являются просто Web-браузерами, которые способны осуществлять синтаксический анализ определенных видов URL-адресов (например, URL "man:ls(1)" интерпретирует man-страницу ls(1) в HTML-страницу). Это облегчает проблемы, вызванные существованием множества различных форматов для главных документов, но не решает их полностью. Составители документов до сих пор вынуждены решать проблему выбора главного формата, который удовлетворит их специфические потребности.

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

В первую очередь необходимо определить различия между WYSIWYG-программами (WYSIWYG, "What You See Is What You Get" — "что видишь, то и получаешь") и инструментами разметки (Markup-Centered Tools) . Большинство настольных издательских программ и текстовых процессоров входят в первую категорию; они имеют GUI-интерфейсы, в которых вводимый пользователем текст вставляется непосредственно в экранное представление документа, которое задумано как наиболее точное подобие окончательной печатаемой версии. Напротив, в системе, ориентированной на разметку, документ обычно является простым текстовым документом, содержащим явные, видимые управляющие теги и вообще не имеет сходства с ожидаемой выходной версией. Размеченный исходный документ можно модифицировать с помощью обычного текстового редактора, но необходимо передать программе-форматеру, создающей визуализированный вывод для печати или отображения на экране.

Визуальный интерфейс, или WYSIWYG-стиль, был чрезмерно затратным для ранних компьютеров и использовался редко вплоть до появления в 1984 году персонального компьютера Macintosh. В настоящее время этот стиль полностью доминирует в не-Unix операционных системах. С другой стороны, собственные инструменты форматирования документов в Unix почти все основаны на разметке. Unix-программа troff(1) 1971 года была форматером разметки и, вероятно, является старейшей из подобных программ, которая используется до сих пор.

Инструменты разметки до сих пор играют значительную роль, поскольку имеющиеся реализации WYSIWYG часто приводят к различным сбоям — некоторые из них поверхностные, а некоторые глубокие. WYSIWYG-процессоры имеют одну общую проблему с GUI-интерфейсами, которая рассматривалась в главе 11. Тот факт, что пользователь может визуально манипулировать любым объектом, часто означает то, что пользователь должен управлять всем. Данная проблема осталась бы, даже если WYSIWIG-соответствие между экранным выводом и распечаткой было бы идеальным, но это почти всегда не так.