Каковы примеры несоответствия и неполноты в Unix / C?

В знаменитом эссе Ричарда Габриэля « Лучше хуже» он противопоставляет карикатурные версии философии дизайна MIT / Stanford (Lisp) и New Jersey (C / Unix) по осям простоты, правильности, согласованности и полноты. Он приводит пример «проблемы с загрузкой ПК» ( обсуждаемой в другом месте Джошем Хаберманом ), чтобы доказать, что Unix отдает приоритет простоте реализации над простотой интерфейса.

Еще один пример, который я привел, - это разные подходы к числам. Lisp может представлять произвольно большие числа (вплоть до объема памяти), в то время как C ограничивает числа фиксированным числом битов (обычно 32-64). Я думаю, что это иллюстрирует ось правильности.

Каковы некоторые примеры последовательности и полноты? Вот все описания Габриэля (которые он признает карикатурами):

MIT / Стэнфордский подход

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

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

• Простота - дизайн должен быть простым, как по реализации, так и по интерфейсу. Для реализации важнее быть простым, чем интерфейс. Простота является наиболее важным фактором в дизайне.
• Правильность - дизайн должен быть правильным во всех наблюдаемых аспектах. Немного лучше быть простым, чем правильным.
• Согласованность - дизайн не должен быть чрезмерно непоследовательным. В некоторых случаях согласованность может быть принесена в жертву для простоты, но лучше отбросить те части проекта, которые имеют дело с менее распространенными обстоятельствами, чем вводить либо сложность реализации, либо несогласованность.
• Полнота - дизайн должен охватывать столько важных ситуаций, сколько это практически возможно. Все разумно ожидаемые случаи должны быть покрыты. Полнота может быть принесена в жертву в пользу любого другого качества. Фактически, полнота должна быть принесена в жертву всякий раз, когда простота реализации находится под угрозой. Последовательность может быть принесена в жертву для достижения полноты, если простота сохраняется; Особенно бесполезна последовательность интерфейса.

Обратите внимание, я не спрашиваю, прав ли Габриэль (этот вопрос не подходит для StackExchange), но привожу примеры того, на что он мог ссылаться.

Название вопроса предполагает, что некоторые основные несоответствия пользовательского интерфейса могут вас заинтересовать:

Команды Unix не следуют конкретному синтаксису для указания опций и флагов. Например, большинство команд используют одиночные буквы, перед которыми стоит «-», как flag:, 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», но такие устройства, как звуковые карты, даже не очень хорошо подходят.

консистенция

Лисп имеет очень согласованный синтаксис, все языковые расширения могут быть встроены естественным образом через макросы и тому подобное. C, с другой стороны, имеет довольно синтаксический код, который позволяет использовать несколько «горячих клавиш», поэтому в некоторых случаях код на C действительно выглядит проще.

завершенность

В Лиспе, если у вас нет нужной вам языковой функции, вы можете реализовать ее самостоятельно с помощью макросов. C тоже имеет препроцессор, но это довольно сложно.

Строки C не могут содержать символ 0, а его библиотечные функции не подходят для работы с двоичными данными.

Имена файлов в системах Unix не могут содержать символ 0 или символ 47 (косая черта).

В оригинальной реализации Unix имена файлов были ограничены 14 символами. Более поздние версии только ослабили это ограничение; они не устранили это.

Добавлено : состояние E2BIGсистемной ошибки, когда пытались execиспользовать список аргументов, который имел слишком много аргументов, или занимал слишком много памяти, или среда была слишком большой.

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

IIRC мой учитель сказал, что неспособность использовать char *переменные в switchутверждениях на C - это вопрос непоследовательности, но для меня это была проблема общности (полноты). Я думаю, что лучше использовать «согласованность» только в ваших алгоритмах или разработке программного обеспечения, а не в самом языке программирования (по крайней мере, не в таких языках, как C. Возможно, у языка с ошибками есть проблема согласованности), потому что языки программирования имеют твердые стандарты, которые определяют предметную область правил. и работать, применяя ввод к правилам. Так что, если что-то не разрешено в языке, это запланировано, чтобы не было разрешено и не является несоответствием в языке, ИМХО.

1. Я использовал общность как полноту. Я думаю, что это одно и то же. может я ошибаюсь
2. Это не ответ. может быть, предложение или мое мнение.

Лучший пример, который у меня есть, - это плохой пользователь, у которого есть файл с именем .. -rи напечатан rm *.

Является ли эта история правдой или нет, она стала классикой ненавистника Unix.

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

Кроме того, я добавлю, что избежание подобных проблем было главной силой при разработке Power Shell от Microsoft.

• Конечно, несметное количество одинаковых (коротких) флагов для команд является несоответствием.
• Каждая программа, использующая регулярные выражения, имеет собственный синтаксис для них.
• Все файлы конфигурации для сервисов имеют разный синтаксис (его можно частично простить, ваш демон почтовой программы имеет мало общего с вашим веб-сервером или загрузкой системы, но все же)
• Есть разные редакторы! Пользователи используют разные оболочки !! Почему так много окружений рабочего стола?!?

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

Так что да, Unix несовместим. Как и другие системы, просто по-другому ;-)

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

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