Для установки нажмите кнопочку Установить расширение. И это всё.

Исходный код расширения WIKI 2 регулярно проверяется специалистами Mozilla Foundation, Google и Apple. Вы также можете это сделать в любой момент.

4,5
Келли Слэйтон
Мои поздравления с отличным проектом... что за великолепная идея!
Александр Григорьевский
Я использую WIKI 2 каждый день
и почти забыл как выглядит оригинальная Википедия.
Статистика
На русском, статей
Улучшено за 24 ч.
Добавлено за 24 ч.
Что мы делаем. Каждая страница проходит через несколько сотен совершенствующих техник. Совершенно та же Википедия. Только лучше.
.
Лео
Ньютон
Яркие
Мягкие

Из Википедии — свободной энциклопедии

Философия 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.

Ссылки

Эта страница в последний раз была отредактирована 22 мая 2023 в 15:11.
Как только страница обновилась в Википедии она обновляется в Вики 2.
Обычно почти сразу, изредка в течении часа.
Основа этой страницы находится в Википедии. Текст доступен по лицензии CC BY-SA 3.0 Unported License. Нетекстовые медиаданные доступны под собственными лицензиями. Wikipedia® — зарегистрированный товарный знак организации Wikimedia Foundation, Inc. WIKI 2 является независимой компанией и не аффилирована с Фондом Викимедиа (Wikimedia Foundation).