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

Поддержка операционной системой Unix множества стилей программных интерфейсов (которая часто рассматривается как недостаток, поскольку увеличивает видимую сложность системы для конечных пользователей) также способствовала развитию гибкости; ни одна программа, которая должна быть просто блоком обработки данных, не несет на себе издержек, связанных со сложностью замысловатого графического пользовательского интерфейса (GUI).

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

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

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

Следует отметить, что это можно сказать далеко не о многих системах. Действительно, напряжение и труд разработчика в других средах часто сравнивают с выталкиванием мертвого кита с мели [7] Первоначально это было сказано Стефаном С. Джонсоном (Stephen С. Johnson), который, вероятно, более известен как автор программы yacc , об оснастке TSO в операционной системе IBM MVS. . Напротив, в мире Unix операционная система скорее вознаграждает усилия, чем вызывает разочарование. Программисты в Unix обычно видят в ней не противника, победа над которым является главной целью, а скорее соратника.

В этом есть реальное экономическое значение. Фактор занимательности, конечно, сыграл свою роль. Людям нравилась Unix, поэтому они разрабатывали для нее больше программ, которые сделали ее использование приятным. В наши дни целые Unix-системы промышленного качества с открытым исходным кодом создаются людьми, которые воспринимают такую свою деятельность как хобби. Для того чтобы понять насколько это удивительно, достаточно попытаться найти людей, которые интереса ради занимаются клонированием операционных систем OS/360, VAX/VMS или Microsoft Windows.

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

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

Unix-программисты аккумулировали десятилетия опыта, пока наступил тот момент, когда функции новаторской операционной системы принимаются как должное. Даже программисты, не работающие с Unix, могут получить пользу от изучения данного опыта Unix. Так как Unix делает применение передовых принципов проектирования и методов разработки сравнительно простым, она является превосходной платформой для их изучения.

Другие операционные системы обычно делают хорошую практику более трудной, однако даже в этом случае можно использовать некоторые из уроков культуры Unix. Большая часть кода Unix (включая все ее фильтры, основные языки сценариев и многие генераторы кода) переносится непосредственно в любую операционную систему, поддерживающую ANSI С (по той причине, что язык С был "порождением" Unix, а библиотека ANSI С охватывает значительную часть Unix-служб).

"Unix-философия" возникла вместе с ранними размышлениями Кена Томпсона о том, как сконструировать небольшую, но совершенную операционную систему с ясным служебным интерфейсом. Она развивалась по мере того, как Unix-культура изучала возможности получения максимального эффекта от проекта Томпсона, и в процессе этого развития впитывала уроки "предыдущей истории".

Философия Unix не является формальным методом проектирования. Она не была та свыше" как способ создания теоретически идеального программного обеспечения. Unix-философия (как удачные народные традиции в других инженерных дисциплинах) прагматична и основывается на опыте. Ее следует искать не в официальных методах и стандартах, а скорее в скрытых почти рефлекторных знаниях и опыте , ко торый передается культурой Unix. Она культивирует чувство меры и достаточный скептицизм.

Дуг Макилрой, изобретатель каналов (pipes) в Unix и один из основателей Unix-традиции, сформулировал постулаты философии Unix следующим образом [52].

(i) Заставьте каждую программу хорошо выполнять одну функцию. Для решения новой задачи следует создавать новую программу, а не усложнять старые программы добавлением новых функций.

(ii) Будьте готовы к тому, что вывод каждой программы станет вводом другой, еще неизвестной программы. Не загромождайте вывод посторонней информацией. Избегайте строгих табличных или двоичных форматов ввода. Не настаивайте на интерактивном вводе.

(iii) Проектируйте и создавайте программное обеспечение, даже операционные системы, которые можно будет проверить в самом начале, в идеальном случае в течение нескольких недель. Без колебаний выбрасывайте громоздкие части и перестраивайте их.

(iv) Вместо неквалифицированной помощи используйте инструменты, облегчающие программирование, даже если инструменты приходится создавать "окольными" путями, зная, что некоторые из них будут удалены по окончании использования.

Позднее он обобщил эти положения (процитировано в книге "A Quarter Century of Unix" [74]).

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

Роб Пайк, который стал одним из великих мастеров языка С, в книге "Notes on С Programming" [62] предлагает несколько иной угол зрения.

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