Які приклади неузгодженості та неповноти в Unix / C?

У відомому нарисі Річарда Габріеля «Rise of Worse is Better Better» він протиставляє карикатурні версії дизайнерських філософій MIT / Stanford (Lisp) та New Jersey (C / Unix) уздовж осей простоти, правильності, послідовності та повноти. Він наводить приклад "проблеми програвача ПК" ( обговорюваної в іншому місці Джошем Хаберманом ), щоб стверджувати, що Unix надає пріоритет простоті реалізації та простоті інтерфейсу.

Ще один приклад, який я придумав - це різні підходи до чисел. Lisp може представляти довільно великі числа (до розміру пам'яті), тоді як C обмежує числа фіксованою кількістю бітів (як правило, 32-64). Я думаю, що це ілюструє вісь правильності.

Наведіть декілька прикладів послідовності та повноти? Ось усі описи Габріеля (які він визнає, є карикатурами):

Підхід MIT / Stanford

• Простота - дизайн повинен бути простим, як в реалізації, так і в інтерфейсі. Для інтерфейсу важливіше бути простим, ніж реалізація.
• Правильність - дизайн повинен бути правильним у всіх спостережуваних аспектах. Неправильність просто не допускається.
• Консистенція - дизайн не повинен бути непослідовним. Дизайн дозволяється бути трохи менш простим і менш повним, щоб уникнути невідповідності. Послідовність так само важлива, як і правильність.
• Повнота - дизайн повинен охоплювати стільки важливих ситуацій, скільки є практичним. Усі обґрунтовано очікувані справи повинні бути висвітлені. Простота не дозволяється надмірно знижувати повноту.

Підхід Нью-Джерсі

• Простота - дизайн повинен бути простим, як в реалізації, так і в інтерфейсі. Важливо, щоб реалізація була простою, ніж інтерфейс. Простота - це найважливіша увага в дизайні.
• Правильність - дизайн повинен бути правильним у всіх спостережуваних аспектах. Трохи краще бути простим, ніж правильним.
• Консистенція - дизайн не повинен бути надмірно непослідовним. Послідовність може бути принесена в жертву для простоти в деяких випадках, але краще відмовитися від тих частин конструкції, які стосуються менш поширених обставин, ніж вводити або складність в реалізації, або невідповідність.
• Повнота - дизайн повинен охоплювати стільки важливих ситуацій, скільки є практичним. Усі обґрунтовано очікувані справи повинні бути висвітлені. Повноту можна принести в жертву на користь будь-якої іншої якості. Насправді, повнота повинна бути принесена у жертву, коли піддається небезпеці простота впровадження. Послідовність може бути принесена в жертву, щоб досягти повноти, якщо простота зберігається; Особливо марною є послідовність інтерфейсу.

Зауважте, я не запитую, чи правильно Габріель (це питання не підходить для StackExchange), а про приклади того, про що він, можливо, мав на увазі.

Назва запитання говорить про те, що деякі невідповідності базового інтерфейсу можуть вас зацікавити:

Команди Unix не дотримуються певного синтаксису для вказівки параметрів та прапорів. Наприклад, більшість команд використовують окремі літери, перед якими "-" як прапор:, cat -n some_fileале винятки люблять tar tf some_file.tarі dd in=some_file out=some_other_file count=2існують у загальновживаних командах.

У Unix та його нащадках та родичах є декілька синтаксисів регулярного вираження, що мають декілька дещо різних. Оболонки використовують "*" там, де інші програми (grep, egrep, vi) використовують ". *". egrep має "+" та "|" як оператори, grep не робить.

Основний інтерфейс системного виклику "все є файлом" може розглядатися як неповний: читання / запис / пошук / закриття не відповідає кожному пристрою вводу-виводу. Надзвичайно потрібні винятки потрапляють у виклики "ioctl", але пристрої на зразок звукових карт навіть не дуже добре підходять.

Послідовність

У Lisp дуже стійкий синтаксис, усі розширення мови можуть бути вбудовані природним шляхом за допомогою макросів тощо. C, з іншого боку, має досить синтаксис коду, який дозволяє зробити деякі "ярлики", тому в деяких випадках код C фактично виглядає простіше.

Повнота

У Lisp, якщо у вас немає певної потрібної мовної функції, ви можете реалізувати її самостійно за допомогою макросів. У C теж є препроцесор, але це досить неприємно.

Рядки C не можуть містити символ 0, а його функції бібліотеки непридатні для роботи з бінарними даними.

Імена файлів у системах Unix не можуть містити символів 0 або символу 47 (косою рисою).

У оригінальній реалізації Unix, імена файлів обмежувались 14 символами. Пізніші версії лише зменшили це обмеження; вони не ліквідували її.

Додано : E2BIGУмова системної помилки, коли намагалися execзі списком аргументів, який мав занадто багато аргументів, або зайняв занадто багато пам'яті, або занадто велике середовище.

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

Мій викладач IIRC сказав, що неможливість використання char *змінних у switchвисловлюваннях на С є питанням невідповідності, але для мене це було питанням загальності (повноти). Я думаю, що краще використовувати "узгодженість" лише у своїх алгоритмах або дизайні програмного забезпечення, а не в самій мові програмування (принаймні, не на таких мовах, як C. Можливо, у мови баггі є відповідність), оскільки мови програмування мають чіткі стандарти, що визначають область правил і працювати, застосовуючи введення до правил. Тож якщо щось не дозволено в мові, планується не допустити і це невідповідність мові, ІМХО.

1. Я використовував загальність як повноту. я думаю, що вони однакові. можливо я помиляюся
2. Це не відповідь. можливо, пропозиція чи моя думка.

Найкращий приклад, який я маю, - це поганий користувач, у якого був ім’я .. -rта набраний файлrm * .

Невже ця історія правдива чи ні, вона стала класикою ненависників Unix.

Дивіться підручник з Unix-Haters , який містить вступ самого Деніса Річі, про багато таких прикладів.

Додам ще, що уникнення подібних проблем було головною силою в дизайні Power Shell від Microsoft.

• Звичайно, безліч значень одних і тих же (коротких) прапорів командам є непослідовністю.
• Кожна програма, яка використовує регулярні вирази, має для них власний синтаксис
• Файли конфігурації для служб - це різний синтаксис (який частково можна пробачити. Демон демона має мало спільного з запуском веб-сервера чи системи, але все ж)
• Є різні редактори! Користувачі використовують різні оболонки !! Чому так багато середовищ на робочому столі?!?

ОТОХ, той факт, що оболонка розширює глобуси, а не прогам, усуває безліч подразливих невідповідностей, присутніх в інших системах. Визначте той факт, що ви можете використовувати одну і ту ж команду, щоб скопіювати файл з одного місця в інше у файлі файлів, на дискету або з диска Zip на стрічку.

Отже, так, Unix непослідовний. Так само і в інших системах, інакше ;-)

LISP, що підтримує нескінченні точні числа порівняно з C, що підтримує лише цілі числа машин, не є прикладом правильності мови. Це проста справа, що виникає через те, що мови мали дуже різні цілі дизайну.

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