Философия Unix
Источник: https://ru.wikipedia.org/wiki/%D0%A4%D0 ... D1%8F_Unix
Философия Unix
Философия Unix — набор культурных норм и философских подходов к разработке программного обеспечения, основанных на опыте ведущих разработчиков операционной системы Unix. Существуют разные формулировки принципов, объясняющих нормы и традиции.
Три принципа Макилроя
Дуг Макилрой — изобретатель каналов Unix и один из основателей традиции Unix — обобщил философию следующим образом:
пишите программы, которые делают что-то одно и делают это хорошо;
пишите программы, которые бы работали вместе;
пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
Обычно эти высказывания сводятся к одному «Делайте что-то одно, но делайте это хорошо». Из этих трёх принципов только третий является специфичным для Unix, хотя разработчики Unix чаще других акцентируют внимание на всех трёх принципах.
Принципы Ганкарца
В 1994 году Майк Ганкарц (англ. Mike Gancarz) объединил свой опыт работы над X Window System) с высказываниями из прений, в которых он участвовал со своими приятелями-программистами и людьми из других областей деятельности, так или иначе зависящих от Unix, и вывел в книге «Философия Unix» 9 основных принципов:
красиво — небольшое;
пусть каждая программа делает что-то одно, но хорошо;
стройте прототип программы как можно раньше;
предпочитайте переносимость эффективности;
храните данные в простых текстовых файлах;
извлекайте пользу из уже существующих программных решений;
используйте сценарные языки для уменьшения трудозатрат и улучшения переносимости;
избегайте пользовательских интерфейсов, ограничивающих возможности пользователя по взаимодействию с системой;
делайте каждую программу «фильтром».
Менее важные 10 принципов не снискали всеобщего признания в качестве частей философии Unix и в некоторых случаях являлись предметом горячих споров (монолитное ядро против микроядра):
позвольте пользователю настраивать окружение;
делайте ядра операционной системы маленькими и легковесными;
используйте нижний регистр и придерживайтесь кратких названий;
не храните тексты программ в виде распечаток («спасите деревья!»);
не сообщайте пользователю об очевидном («молчание — золото»);
разбивайте сложные задачи на несколько простых, выполняемых параллельно («мыслите „параллельно“»);
объединённые части целого есть нечто большее, чем просто их сумма;
ищите 90-процентное решение;
если можно не добавлять новую функциональность, не добавляйте её («чем хуже, тем лучше»);
мыслите иерархически.
Тезисы Рэймонда
Эрик Рэймонд (англ. Eric S. Raymond) в книге «Искусство программирования в Unix» подытожил философию Unix как широко используемую инженерную философию «Делай это проще, глупец» (принцип KISS). Затем он описал, как эта обобщённая философия применима в качестве культурных норм Unix. И это несмотря на то, что несложно найти несколько нарушений в следующей текущей философии Unix:
правило модульности: пишите простые части, соединяемые понятными интерфейсами;
правило ясности: ясность лучше заумности;
правило композиции: разрабатывайте программы так, чтобы их можно было соединить с другими программами;
правило разделения: отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine);
правило простоты: нацельтесь на простоту; добавляйте сложность, только где необходимо;
правило экономности: пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся;
правило прозрачности: разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки;
правило надёжности: надёжность — дитя прозрачности и простоты;
правило представления: храните знания в данных так, чтобы логика программы была тупой и надёжной;
правило наименьшего удивления: при разработке интерфейса всегда делайте так, чтобы привычные элементы интерфейса выполняли привычные функции;
правило тишины: если программе нечего сказать, пусть лучше молчит;
правило восстановления: если программа должна аварийно завершиться, делайте это шумно и как можно быстрее;
правило экономии: время программиста дорого; сократите его, используя машинное время;
правило генерации: избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы;
правило оптимизации: сначала — опытный образец, потом — «причесывание»; добейтесь стабильной работы, только потом оптимизируйте;
правило многообразия: отвергайте все утверждения о «единственно правильном пути»;
правило расширяемости: разрабатывайте для будущего — оно наступит быстрее, чем вы думаете;
Большинство из этих норм принимается вне сообщества Unix — даже если это было не так во времена, когда они впервые были применены в Unix, то впоследствии это стало так. К тому же много правил не являются уникальными или оригинальными для сообщества Unix. Тем не менее, приверженцы программирования в Unix склоняются к тому, чтобы принять сочетание этих идей в качестве основ для стиля Unix.
Цитаты
Некоторые широко известные высказывания, характеризующие культуру разработки Unix:
«Unix прост. Но надо быть гением, чтобы понять его простоту» — Деннис Ритчи;
«Unix не предназначен для ограждения своих пользователей от глупостей, поскольку это оградило бы их и от умных вещей» — Дуг Гвин;
«Unix никогда не говорит „пожалуйста“» — Роб Пайк;
Критика
Философия UNIX критиковалась в книге «The UNIX-HATERS Handbook», изданной в начале 1990-х годов.
По мнению редакторов книги, подход Unix приводит к появлению решений, сделанных наспех, без должного продумывания архитектуры, после чего данные решения канонизируются (enshrined), то есть объявляются вечной классикой. Например, таким решением, по их мнению, являются lock files — временные файлы без содержимого, создаваемые как пометка того факта, что какая-то программа находится в процессе исполнения.
X Window System была подвергнута критике за отделение в ней механизма (engine) от политики (policy), что привело к отсутствию в UNIX стандарта на политики управления пользовательским интерфейсом и большим затруднениям при разработке приложений, использующих GUI.
NFS была подвергнута критике за изначально порочный подход к архитектуре — попытку создать stateless файл-сервер при том, что это принципиально невозможно. Когда же невозможность поддержки некоторых важных вещей стала очевидной, к NFS прикрутили «костыль» под названием процесса lockd.
Но, в то же время, критикуемые в этой книге подходы, начатые в *NIX, плавно обосновываются и в операционных системах семейств Windows и унаследованы macOS.