Философия Unix - Unix philosophy

Кен Томпсон и Деннис Ричи, ключевые сторонники философии Unix

В Философия Unix, созданный Кен Томпсон, представляет собой набор культурных норм и философских подходов к минималист, модульный разработка программного обеспечения. Он основан на опыте ведущих разработчиков Unix Операционная система. Ранние разработчики Unix сыграли важную роль в внедрении концепций модульности и возможности повторного использования в практику разработки программного обеспечения, что породило "программные инструменты "движение". Со временем ведущие разработчики Unix (и программ, которые работали на нем) установили набор культурных норм для разработки программного обеспечения; эти нормы стали такими же важными и влиятельными, как и сама технология Unix; это было названо "Unix философия ".

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

Источник

Философия Unix задокументирована Дуг Макилрой[1] в Техническом журнале Bell System с 1978 г .:[2]

  1. Пусть каждая программа хорошо выполняет одну задачу. Чтобы выполнить новую работу, создавайте заново, а не усложняйте старые программы, добавляя новые «функции».
  2. Ожидайте, что выходные данные каждой программы станут входными данными для другой, еще неизвестной программы. Не загромождайте вывод посторонней информацией. Избегайте строго столбчатых или двоичных форматов ввода. Не настаивайте на интерактивном вводе.
  3. Проектируйте и создавайте программное обеспечение, даже операционные системы, которое следует опробовать на раннем этапе, в идеале в течение нескольких недель. Не бойтесь выбросить неуклюжие детали и собрать их заново.
  4. Используйте инструменты, а не неквалифицированную помощь, чтобы облегчить задачу программирования, даже если вам приходится обходить стороной, чтобы создать инструменты, и вы ожидаете выбросить некоторые из них после того, как закончите их использовать.

Позже это было резюмировано Питер Х. Салус в "Четверть века Unix" (1994):[1]

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

В своей отмеченной наградами статье о Unix 1974 года Ричи и Томпсон цитируют следующие конструктивные соображения:[3]

Кажется, что вся философия UNIX остается вне ассемблер.

— Майкл Шон Махони[4]

Среда программирования UNIX

В предисловии к книге 1984 г. Среда программирования UNIX, Брайан Керниган и Роб Пайк, оба из Bell Labs дайте краткое описание конструкции Unix и философии Unix:[5]

Роб Пайк, соавтор Среда программирования UNIX

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

Авторы далее пишут, что их цель в этой книге - «передать философию программирования UNIX».[5]

Разработка программ в среде UNIX

Брайан Керниган много писал о философии Unix

В октябре 1984 года Брайан Керниган и Роб Пайк опубликовали статью под названием Разработка программ в среде UNIX. В этой статье они критикуют расширение программных опций и функций, обнаруженных в некоторых новых системах Unix, таких как 4.2BSD и Система V и объяснить философию программных средств Unix, каждый из которых выполняет одну общую функцию:[6]

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

Авторы противопоставляют такие инструменты Unix, как Кот, с более крупными наборами программ, используемыми в других системах.[6]

Дизайн Кот типичен для большинства программ UNIX: он реализует одну простую, но общую функцию, которая может использоваться во многих различных приложениях (включая многие, не предусмотренные первоначальным автором). Другие команды используются для других функций. Например, есть отдельные команды для задач файловой системы, таких как переименование файлов, их удаление или определение их размера. Другие системы вместо этого объединяют их в одну команду «файловой системы» со своей внутренней структурой и языком команд. (Программа копирования файлов PIP, которую можно найти в таких операционных системах, как CP / M или же RSX-11 является примером.) Такой подход не обязательно хуже или лучше, но он определенно противоречит философии UNIX.

Дуг Макилрой о программировании под Unix

Дуг Макилрой (остался с Деннис Ричи

Макилрой, затем глава Исследовательского центра компьютерных наук Bell Labs и изобретатель Труба Unix,[7] резюмировал философию Unix следующим образом:[1]

Это философия Unix: писать программы, которые делают одно и делают это хорошо. Напишите программы для совместной работы. Напишите программы для обработки текстовые потоки, потому что это универсальный интерфейс.

Помимо этих заявлений, он также подчеркнул простоту и минимализм в программировании Unix:[1]

Понятие «замысловатые и красивые сложности» - почти оксюморон. Программисты Unix соперничают друг с другом за «простые и красивые» почести - пункт, который подразумевается в этих правилах, но его стоит сделать явным.

Напротив, Макилрой критиковал современные Linux как имеющий раздувание программного обеспечения, отмечая, что "обожающие поклонники накормили Linux лакомствами до неутешительного состояния ожирение."[8] Он противопоставляет это подходу, применявшемуся ранее в Bell Labs при разработке и пересмотре Исследование Unix:[9]

Все было маленьким ... и мое сердце замирает для Linux, когда я вижу его размер. [...] страница руководства, который раньше был руководством страница, теперь это небольшой том с тысячей вариантов ... Раньше мы сидели в Unix Room и говорили: «Что мы можем выбросить? Почему есть этот вариант? » Часто это происходит из-за того, что в базовом дизайне есть какой-то недостаток - вы действительно не достигли нужной точки проектирования. Вместо добавления опции подумайте о том, что заставляло вас добавлять эту опцию.

Делай одно дело и делай это хорошо

Как заявил Макилрой и общепринято во всем сообществе Unix, всегда ожидалось, что программы Unix будут следовать концепции DOTADIW, или «Делай одно дело и делай это хорошо». В Интернете есть ограниченные источники аббревиатуры DOTADIW, но она подробно обсуждается во время разработки и упаковки новых операционных систем, особенно в сообществе Linux.

Патрик Фолькердинг, руководитель проекта Slackware Linux, ссылался на этот принцип дизайна в критике systemd архитектура, заявив, что "попытки управлять службами, сокетами, устройствами, средствами монтирования и т. д., все в одном демон бросает вызов концепции Unix: делать что-то одно и делать это хорошо ".[10]

17 правил Unix Эрика Раймонда

В его книге Искусство программирования под Unix это было впервые опубликовано в 2003 году,[11] Эрик С. Раймонд, американский программист и сторонник открытого исходного кода, резюмирует философию Unix как Принцип KISS из «Будь проще, глупо».[12] Он предоставляет ряд правил проектирования:[1]

  • Строить модульный программы
  • Пишите читаемые программы
  • Использовать состав
  • Отделить механизмы от политики
  • Пишите простые программы
  • Пишите небольшие программы
  • Пишите прозрачные программы
  • Пишите надежные программы
  • При необходимости усложняйте данные, а не программу
  • Опирайтесь на ожидаемые знания потенциальных пользователей
  • Избегайте ненужного вывода
  • Пишите программы, которые не работают так, чтобы их было легко диагностировать
  • Цените время разработчика по сравнению с машинным временем
  • Написать абстрактные программы, которые генерируют код вместо того, чтобы писать код вручную
  • Прототип программное обеспечение перед полировкой
  • Пишите гибкие и открытые программы
  • Сделайте программу и протоколы расширяемыми.

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

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

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

«Чем хуже, тем лучше»

Основная статья: Чем хуже, тем лучше

Ричард П. Габриэль предполагает, что ключевым преимуществом Unix было то, что он воплощал в себе философию проектирования, которую он назвал «хуже - лучше», в которой простота интерфейса и реализация более важна, чем любые другие атрибуты системы, включая правильность, последовательность и полноту. Габриэль утверждает, что этот стиль дизайна имеет ключевые эволюционные преимущества, хотя сомневается в качестве некоторых результатов.

Например, в первые дни Unix использовала монолитное ядро (что означает, что все пользовательские процессы выполняли системные вызовы ядра в пользовательском стеке). Если сигнал был доставлен процессу, когда он был заблокирован на длительное время Ввод / вывод в ядре, что тогда делать? Следует ли задержать сигнал, возможно, на долгое время (возможно, на неопределенное время), пока ввод-вывод завершен? Обработчик сигнала не мог быть запущен, когда процесс находился в режиме ядра с конфиденциальными данными ядра в стеке. Должно ли ядро ​​отменить системный вызов и сохранить его для повторного воспроизведения и перезапуска позже, предполагая, что обработчик сигнала завершился успешно?

В этих случаях Кен Томпсон и Деннис Ричи предпочитал простоту совершенству. Система Unix иногда рано возвращалась из системного вызова с ошибкой, указывающей, что она ничего не сделала - «Прерванный системный вызов» или с номером ошибки 4 (EINTR) в сегодняшних системах. Конечно, вызов был прерван, чтобы вызвать обработчик сигнала. Это могло произойти только для нескольких длительных системных вызовов, таких как читать(), записывать(), открыто(), и Выбрать(). С другой стороны, это во много раз упростило проектирование и понимание системы ввода-вывода. Подавляющее большинство пользовательских программ никогда не подвергалось воздействию, потому что они не обрабатывали и не воспринимали другие сигналы, кроме SIGINT и умрет сразу, если вырастет. Для нескольких других программ, таких как оболочки или текстовые редакторы, которые реагируют на нажатие клавиш управления заданиями, к системным вызовам можно добавить небольшие оболочки, чтобы сразу же повторить вызов, если это EINTR возникла ошибка. Таким образом, проблема решилась просто.

Критика

В статье 1981 г., озаглавленной «Правда о Unix: Пользовательский интерфейс ужасен"[13] опубликовано в Датамация, Дон Норман критиковал философию дизайна Unix за то, что она не уделяла внимания пользовательскому интерфейсу. Писая, опираясь на свой опыт работы в когнитивной науке и с точки зрения современной философии когнитивная инженерия,[4] он сосредоточился на том, как конечные пользователи понимают и формируют личные когнитивная модель систем - или, в случае Unix, непонимание, в результате чего катастрофические ошибки (например, потеря часа работы) становятся слишком легкими.

Смотрите также

Примечания

  1. ^ а б c d е Раймонд, Эрик С. (2003-09-23). «Основы философии Unix». Искусство программирования под Unix. Эддисон-Уэсли Профессионал. ISBN  0-13-142901-9. Получено 2016-11-01.
  2. ^ Дуг Макилрой, Э. Н. Пинсон, Б. А. Тейг (8 июля 1978 г.). "Система разделения времени Unix: предисловие". Технический журнал Bell System. Bell Laboratories. С. 1902–1903.CS1 maint: несколько имен: список авторов (связь)
  3. ^ Деннис Ричи; Кен Томпсон (1974), «Система разделения времени UNIX» (PDF), Коммуникации ACM, 17 (7): 365–375, Дои:10.1145/361011.361061
  4. ^ а б "Устная история Unix". Университет Принстона История науки.
  5. ^ а б Керниган, Брайан В. Пайк, Роб. Среда программирования UNIX. 1984. viii
  6. ^ а б Роб Пайк; Брайан В. Керниган (октябрь 1984 г.). «Разработка программ в среде UNIX» (PDF).
  7. ^ Деннис Ричи (1984), «Эволюция системы разделения времени UNIX» (PDF), Технический журнал AT&T Bell Laboratories, 63 (8): 1577–1593, Дои:10.1002 / j.1538-7305.1984.tb00054.x
  8. ^ Дуглас Макилрой. «Примечания к церемонии вручения премии Японии Деннису Ричи, 19 мая 2011 г., Мюррей Хилл, Нью-Джерси» (PDF). Получено 2014-06-19.
  9. ^ Билл МакГонигл. «Происхождение Linux - Как начиналось веселье (2005)». Получено 2014-06-19.
  10. ^ «Интервью с Патриком Фолькердингом из Slackware». linuxquestions.org. 2012-06-07. Получено 2015-10-24.
  11. ^ Раймонд, Эрик (2003-09-19). Искусство программирования под Unix. Эддисон-Уэсли. ISBN  0-13-142901-9. Получено 2009-02-09.
  12. ^ Раймонд, Эрик (2003-09-19). «Философия Unix в одном уроке». Искусство программирования под Unix. Эддисон-Уэсли. ISBN  0-13-142901-9. Получено 2009-02-09.
  13. ^ Норман, Дон (1981). «Правда о Unix: ужасный пользовательский интерфейс» (PDF). Датамация (27(12)).

Рекомендации

внешняя ссылка