Філософія Unix

Матеріал з Вікіпедії — вільної енциклопедії.
Версія від 01:53, 14 лютого 2022, створена TohaomgBot (обговорення | внесок) (Перекладено дати в примітках з англійської на українську)
Перейти до навігації Перейти до пошуку
Кен Томпсон і Денніс Річі, ключові прихильники філософії Unix

Філософія Unix, заснована Кеном Томпсоном, є набором культурних норм і філософських підходів до мінімалістичної, модульної розробки програмного забезпечення. Вона ґрунтується на досвіді провідних розробників операційної системи Unix. Перші розробники Unix відіграли важливу роль у внесенні концепцій модульності та багаторазового використання у практику розробки програмного забезпечення, породивши рух «програмних інструментів». Згодом провідні розробники Unix (і програм, що працювали на ній) встановили набір норм для розробки програмного забезпечення. Ці норми стали настільки ж важливими та впливовими, як і сама технологія Unix та отримали назву «філософія Unix».

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

Походження

Філософію Unix задокументував Дуглас Макілрой[1] у журналі Bell System Technical 1978 року, яка складалась з 4 пунктів:[2]

  1. Зробіть так, щоб кожна програма добре виконувала одну справу. Щоб виконати нову роботу, створюйте нові програми, а не ускладнюйте старі, додаючи новий функціонал.
  2. Очікуйте, що вихід кожної програми стане вхідним сигналом для іншої, поки невідомої, програми. Не захаращуйте вихідні дані сторонньою інформацією. Уникайте суворо стовпчастих або двійкових форматів введення. Не наполягайте на інтерактивному введенні.
  3. Проектуйте та створюйте програмне забезпечення, навіть операційні системи, які потрібно випробувати завчасно, в ідеалі протягом кількох тижнів. Не соромтеся видаляти незграбні частини та відновлювати їх.
  4. Не використовуйте некваліфіковану допомогу, щоб полегшити виконання завдання, краще скористайтесь інструментами, навіть якщо ви видалите деякі з них після того, як закінчите їх використання.

Пізніше Пітером Х. Салусом узагальнив ці пункти у своїй книзі «A Quarter-Century of Unix» (1994):[1]

  • Пишіть програми, які роблять одну справу і роблять її добре.
  • Пишіть програми з можливістю спільної роботи над ними.
  • Пишіть програми для обробки текстових потоків, тому що це універсальний інтерфейс.

У своїй статті 1974 року, яка була відзначена численними нагородами[3], Річі та Томпсон цитують такі міркування щодо дизайну:[4]

  • Спростіть написання, тестування та запуск програм.
  • Замініть пакетну обробку на інтерактивне використання.
  • Економність та елегантність дизайну через обмеження розмірів («порятунок через страждання»).
  • Самодостатня система: все програмне забезпечення Unix підтримується під Unix.
Вся філософія UNIX, схоже, у тому, щоб триматися подалі від асемблера.

Майкл Шон Махоні

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

У своїй передмові до книги 1984 року «Середовище програмування UNIX» Брайан Керніган і Роб Пайк (обидва з Bell Labs) дають короткий опис дизайну Unix і філософії Unix:[5]

Роб Пайк, співавтор The UNIX Programming Environment
Незважаючи на те, що система UNIX представляє ряд інноваційних програм та методів, жодна програма чи ідея не робить її ефективною. Натомість те, що робить її ефективною, - це підхід до програмування, філософія використання комп'ютера. Хоча цю філософію не можна записати в одному реченні, в її основі лежить ідея про те, що сила системи більшою мірою залежить від відносин між програмами, ніж від самих програм. Багато програм UNIX роблять досить тривіальні речі власними силами, але у поєднанні з іншими програмами стають загальними та корисними інструментами.

Автори пишуть, що мета цієї книги — «повідомити про філософію програмування UNIX». [5]

Розробка програм у середовищі UNIX

Браян Керніган довго писав про філософію Unix

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

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

Автори порівнюють такі інструменти Unix, як cat, з більшими пакетами програм, які використовуються іншими системами.[6]

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

Дуг Макілрой про програмування Unix

Дуглас Макілрой (ліворуч) з Деннісом Річі

Макілрой, тодішній керівник дослідницького центру Bell Labs Computing Sciences і винахідник конвеєра,[7] узагальнив філософію Unix таким чином:[1]

Це філософія Unix: Пишіть програми, які виконують одну роботу та роблять її добре. Пишіть програми для можливості спільної роботи над ними. Пишіть програми для роботи зі стандартними потоками, тому що це універсальний інтерфейс.

Крім цих тверджень, він також наголосив на простоті та мінімалізмі в програмуванні Unix:[1]

Поняття "хитромудрі і красиві складності" - це майже оксиморон. Unix-програмісти змагаються один з одним за звання "простого і красивого" - цей момент мається на увазі у цих правилах, але його варто озвучити.

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

Все було маленьким... і моє серце завмирає, коли бачу розміри Linux сьогодні. [...] Сторінка manual page тепер нагадує невеликий том з тисячею опцій... Ми сиділи і думали: "Що ми можемо видалити? Чому цей функціонал знаходиться там?" Часто це відбувається тому, що в базовому дизайні є якийсь недолік. Замість того, щоб додавати опцію, подумайте про те, що змусило вас додати цю опцію.

Робіть одну річ і робіть її добре

Як стверджує Макілрой, і, як правило, прийнято в Unix-спільноті, від програм Unix завжди очікується дотримання концепції DOTADIW («Do One Thing And Do It Well»). В Інтернеті мало інформації про абревіатуру DOTADIW, але вона докладно обговорювалась під час розробки нових операційних систем, особливо у спільноті Linux.

Патрік Фолькердінг, керівник проекту Slackware Linux, використав цей принцип проектування в критиці архітектури systemd, заявивши, що "спроба контролювати служби, розетки, пристрої, монтування тощо, все в межах одного демона стикається з концепцією Unix: «Робіть одну річ і робіть її добре».[10]

17 правил Unix Еріка Реймонда

У своїй книзі «Мистецтво програмування Unix», яка була вперше опублікована в 2003 році[11] Ерік С. Реймонд, американський програміст і прихильник відкритих кодів, підсумовує філософію Unix як принцип KISS «keep it simple, stupid».[12] Він наводить ряд правил проектування:[1]

  • Створюйте модульні програми
  • Пишіть читабельні програми
  • Використовуйте композицію
  • Пишіть прості програми
  • Пишіть невеликі програми
  • Пишіть прозорі програми
  • Пишіть надійні програми
  • За потреби ускладнюйте дані, а не програму
  • Зважайте на очікувані знання потенційних користувачів
  • Уникайте непотрібного виведення
  • Пишіть програми, які дають збій, так, щоб їх було легко діагностувати
  • Цінуйте час розробника, а не час комп'ютера
  • Пишіть абстрактні програми, які генерують код, замість написання коду вручну
  • Пишіть гнучкі та відкриті програми
  • Зробіть розширюваними програму та її протоколи.

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

У 1994 році Майк Ганкарц (член команди, яка розробила систему X Window), спирався на свій власний досвід роботи з Unix, а також на дискусії з колегами-програмістами та людьми в інших сферах, які залежали від Unix, щоб створити філософію UNIX, яка підсумовує це в дев'яти найважливіших принципах:

  1. Чим менше — тим краще.
  2. Кожна програма має добре виконувати лише одну роботу.
  3. Створіть прототип якомога швидше.
  4. Виберіть портативність, а не ефективність.
  5. Зберігайте дані в плоских текстових файлах .
  6. Використовуйте переваги програмного забезпечення на свою користь.
  7. Використовуйте скрипти середовища, щоб збільшити портативність.
  8. Уникайте неконтрольованих інтерфейсів користувача.
  9. Зробіть кожну програму фільтром .

«Чим гірше, тим краще»

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

Наприклад, на початку Unix використовував монолітне ядро (це означає, що процеси користувача здійснювали системні виклики у стеку користувача). Якщо сигнал був доставлений процесу, коли він був заблокований під час тривалого введення-виведення в ядрі, що робити? Чи слід відкласти сигнал, можливо, на тривалий час (можливо, на невизначений термін), поки введення/виведення не буде завершено? Обробник сигналів не може бути виконаний, коли процес перебував у режимі ядра з конфіденційними даними ядра в стеку. Чи повинне ядро скасувати системний виклик і зберегти його для повторного відтворення та перезапуску пізніше, припускаючи, що обробник сигналу завершиться успішно?

У цих випадках Кен Томпсон і Денніс Річі віддавали перевагу простоті, а не досконалості. Система Unix іноді поверталася раніше після системного виклику з повідомленням про те, що вона нічого не зробила — «Перерваний системний виклик» або помилка номер 4 (EINTR) у сучасних системах. Звичайно, виклик був перерваний, щоб викликати обробника сигналів. Це могло статися лише для кількох тривалих системних викликів, таких як read(), write(), open() і select() . Позитивним є те, що це зробило систему введення-виводу в рази простішою для розробки та розуміння. Більшість користувацьких програм жодним чином від цього не постраждали б, оскільки вони не обробляли інших сигналів окрім SIGINT і відразу б зупинили виконання, якщо б хоч один був піднятий[куди?]. Для кількох інших програм, таких як програмні середовища або текстові редактори, які реагують на натискання клавіш керування завданням, можна було б додати невеликі обгортки до системних викликів, щоб негайно повторити виклик, якщо виникла помилка EINTR.Таким чином, проблему було вирішено простим способом.

Критика

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

Додаткова література

Примітки

 

  1. ↑ а б в г д Raymond, Eric S. (2004). Basics of the Unix Philosophy. The Art of Unix Programming. Addison-Wesley Professional. ISBN 0-13-142901-9. Процитовано 1 листопада 2016. Помилка цитування: Некоректний тег <ref>; назва «taoup-ch1s6» визначена кілька разів з різним вмістом
  2. ↑ Doug McIlroy, E. N. Pinson, B. A. Tague (8 липня 1978). Unix Time-Sharing System: Foreword. The Bell System Technical Journal. Bell Laboratories: 1902—1903.
  3. ↑ ACM - Dennis M. Richie. Архів оригіналу за 26 січня 2021. Процитовано 26 серпня 2021. ACM Programming Systems and Languages Paper Award
  4. ↑ Dennis Ritchie; Ken Thompson (1974), The UNIX time-sharing system (PDF), Communications of the ACM, 17 (7): 365—375, doi:10.1145/361011.361061
  5. ↑ а б Kernighan, Brian W. Pike, Rob. The UNIX Programming Environment. 1984. viii
  6. ↑ а б Rob Pike; Brian W. Kernighan (October 1984). Program Design in the UNIX Environment (PDF). Помилка цитування: Некоректний тег <ref>; назва «design1984» визначена кілька разів з різним вмістом
  7. ↑ Dennis Ritchie (1984), The Evolution of the UNIX Time-Sharing System (PDF), AT&T Bell Laboratories Technical Journal, 63 (8): 1577—1593, doi:10.1002/j.1538-7305.1984.tb00054.x
  8. ↑ Douglas McIlroy. Remarks for Japan Prize award ceremony for Dennis Ritchie, May 19, 2011, Murray Hill, NJ (PDF). Процитовано 19 червня 2014.
  9. ↑ Bill McGonigle. Ancestry of Linux — How the Fun Began (2005). Процитовано 19 червня 2014.
  10. ↑ Interview with Patrick Volkerding of Slackware. linuxquestions.org. 7 червня 2012. Процитовано 24 жовтня 2015.
  11. ↑ Raymond, Eric (19 вересня 2003). The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9. Процитовано 9 лютого 2009.
  12. ↑ Raymond, Eric (19 вересня 2003). The Unix Philosophy in One Lesson. The Art of Unix Programming. Addison-Wesley. ISBN 0-13-142901-9. Процитовано 9 лютого 2009.
  13. ↑ Norman, Don (1981). The truth about Unix: The user interface is horrid (PDF). Datamation. Т. 27, № 12.

Посилання

Посилання

Отримано з https://uk.wikipedia.org/w/index.php?title=Філософія_Unix&oldid=34618636