UNIX way

Философия UNIX — это набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы

Содержание

• 1 МакИлрой: Четверть века UNIX
• 2 Пайк: Стиль программирования на C
• 3 Майк Ганцарз: Философия UNIX
• 4 Реймонд: Искусство программирования в UNIX
• 5 Цитаты
• 6 Критика
• 7 Примечания
• 8 См. также
• 9 Ссылки

МакИлрой: Четверть века UNIX

Дуг МакИлрой, изобретатель каналов UNIX и один из основателей традиции UNIX, обобщил философию следующим образом:

«Философия UNIX гласит:

Пишите программы, которые делают одну вещь и делают её хорошо.

Пишите программы, которые бы работали вместе.

Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс».

Обычно эти высказывания сводятся к одному «Делайте одну вещь, но делайте её хорошо».

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

Пайк: Стиль программирования на C

Роб Пайк (англ. Rob Pike) предложил следующие «правила» в качестве аксиом программирования.^[1] Одновременно эти правила могут выражать точку зрения на философию UNIX:

• Правило 1: Вы не знаете, где программа начнёт тормозить. Узкие места возникают в неожиданных местах, поэтому не стройте догадки и изучайте скорость работы программы до тех пор, пока не удостоверитесь, что узкое место найдено.
• Правило 2: Измерение. Не оптимизируйте скорость до тех пор, пока её не измерите, и даже если вы проверили какую-то часть кода с узким местом, проверьте остальные.
• Правило 3: Изощрённые алгоритмы являются медленными, если n мало, а n обычно мало. В изощрённых алгоритмах присутствуют большие константы. До тех пор, пока вы не убедитесь, что n часто становится большим, избегайте изощрённости (даже если n становится большим, вначале используйте правило 2).
• Правило 4: Изощрённые алгоритмы чаще подвержены ошибкам, чем их простые аналоги, также их гораздо сложнее реализовать. Используйте простые алгоритмы наряду с использованием простых структур данных.
• Правило 5: Данные преобладают. При правильной и хорошо организованной структуре данных, алгоритмы становятся очевидными. Структуры данных, а не алгоритмы, являются центральной частью в программировании.
• Правило 6: Правила 6 нет.

Первое и второе правила Пайка перефразированы Тони Хоаром (англ. Tony Hoare) в известную аксиому «Преждевременная оптимизация — корень всех зол». Кен Томпсон (англ. Ken Thompson) перефразировал 3 и 4 правила Пайка так: «Если сомневаетесь, используйте перебор всех возможных комбинаций». Правила 3 и 4 являются частными положениями философии дизайна KISS: Keep It Simple, Stupid (будь попроще, тупица). Правило 5 было предварительно сформулировано Фредом Бруксом (англ. Fred Brooks) в книге «Мифический человеко-месяц». Правило 5 часто сокращают до «пиши тупой код, который использует умные данные». Правило 6 взято из шутки Брюса, прозвучавшей в «Летающем цирке Монти Пайтона».

Майк Ганцарз: Философия UNIX

В 1994 году Майк Ганцарз (англ. Mike Gancarz) объединил свой опыт работы в UNIX (он является членом команды по разработке системы X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями программистами и людьми из других областей деятельности, так или иначе зависящих от UNIX, для создания Философии UNIX, которая сводится к 9 основным принципам:

1. Маленькое прекрасно.
2. Пусть каждая программа делает одну вещь, но хорошо.
3. Собирайте прототип как можно раньше.
4. Предпочитайте переносимость эффективности.
5. Храните данные в простых текстовых файлах.
6. Используйте программные рычаги для достижения цели.
7. Используйте сценарии командной строки для улучшения функционала и переносимости.
8. Избегайте связывающего программу (captive) пользовательского интерфейса.
9. Делайте каждую программу «фильтром».

Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии UNIX и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):

1. Позвольте пользователю настраивать окружение.
2. Делайте ядра операционной системы маленькими и легковесными.
3. Используйте нижний регистр и придерживайтесь кратких названий.
4. Храните данные древовидно.
5. Молчание — золото.
6. Думайте о параллельности.
7. Объединенные части целого есть нечто большее, чем просто их сумма.
8. Ищите 90-процентное решение.
9. Лучшее — враг хорошего.
10. Думайте иерархически.

Реймонд: Искусство программирования в UNIX

Эрик С. Рэймонд (англ. Eric S. Raymond) в своей книге «Искусство программирования в UNIX» подытожил философию UNIX как широко используемую инженерную философию «Будь попроще, тупица» (Принцип KISS). Затем он описал, как эта обобщенная философия применима в качестве культурных норм UNIX. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии UNIX:

• Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
• Правило ясности: Ясность лучше заумности.
• Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
• Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
• Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
• Правило экономности: Пишите большую программу только когда можно продемонстировать, что другими средствами выполнить необходимую задачу не удастся.
• Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
• Правило надёжности: Надёжность — дитя прозрачности и простоты.
• Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
• Правило наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
• Правило тишины: Если программе нечего сказать, пусть лучше молчит.
• Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
• Правило экономии: Время программиста дорого; сократите его, используя машинное время.
• Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
• Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
• Правило многообразия: Отвергайте все утверждения об «единственно правильном пути».
• Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

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

Цитаты

• «UNIX прост. Но надо быть гением, чтобы понять его простоту» — Деннис Ритчи.
• «UNIX не был разработан так, чтобы отгораживать своих пользователей от глупостей, поскольку это отгородило бы их от делания умных вещей» — Дуг Гвин.
• «UNIX никогда не скажет „пожалуйста“» — Роб Пайк.

Критика

Философия UNIX критиковалась в книге «The UNIX Haters Handsbook», написанной сотрудниками компании Microsoft в начале 1990х годов.

По их мнению, подход UNIX приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.

Так, например, ими критиковалась X Window System за отделение в ней движка от политики, что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.

Приводился ряд примеров, показывающих, что некоторые решения, принятые в ОС VMS, Microsoft Windows и Apple Mac OS, значительно превосходят своих аналогов из мира UNIX.

Примечания

1. ↑ Стиль программирования на C

См. также

• Plan 9 — разработана как наследница UNIX
• Каналы и фильтры
• Разработка программного обеспечения

Ссылки

• Brian Kernighan, Rob Pike. The UNIX Programming Environment 1984
• Rob Pike. Notes on Programming in C 11 сентября 1989
• Richard Gabriel. The Rise of Worse is Better // Lisp: Good News, Bad News, How to Win Big 1991
• Peter H. Salus. A Quarter Century of UNIX. Addison-Wesley, 31 мая 1994. ISBN 0-201-54777-5
• Eric S. Raymond. Philosophy // The Art of UNIX Programming. Addison-Wesley, 17 сентября 2003. ISBN 0-13-142901-9
• M. D. Schroeder, D. D. Clark, J. H. Saltzer, D. H. Wells. Final Report of the Multics Kernel Design Project 1977
• Joel Spolsky. Biculturalism (англ.). Joel on Software (14 декабря 2003). — Взляд Windows‐разработчика на различия двух культур.
• Дмитрий Царьков. Развитие Linux: куда теперь? (рус.) (25 октября 2005).