В знаменитом эссе Ричарда Габриэля « Лучше хуже» он противопоставляет карикатурные версии философии дизайна 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 году обработка больших наборов данных или наборов данных с длинными записями или двоичных данных была крайне ненадежной.
источник
/
не является произвольным, необходимо (?) Устранить неоднозначности, как/
и разделитель пути. Я только что создал файл000
, очевидно, что конкретные ограничения исчезли во времена современной GNU / Linux./
был произвольным, только ограничения длины строки и размера файла были произвольными. Однако дело в том, что другой дизайн мог позволить именам файлов содержать косую черту, но разработчики Unix не сделали этого. считаю это важным./
меня, мне любопытно: если путь должен быть закодирован в виде строки, как вы можете это сделать без зарезервированного символа для разделения пути?path
абстрактный тип данных, и используете его в своих интерфейсах вместо предоставления конкретной реализации (строки ascii с нулевым символом в конце).IIRC мой учитель сказал, что неспособность использовать
char *
переменные вswitch
утверждениях на C - это вопрос непоследовательности, но для меня это была проблема общности (полноты). Я думаю, что лучше использовать «согласованность» только в ваших алгоритмах или разработке программного обеспечения, а не в самом языке программирования (по крайней мере, не в таких языках, как C. Возможно, у языка с ошибками есть проблема согласованности), потому что языки программирования имеют твердые стандарты, которые определяют предметную область правил. и работать, применяя ввод к правилам. Так что, если что-то не разрешено в языке, это запланировано, чтобы не было разрешено и не является несоответствием в языке, ИМХО.источник
Лучший пример, который у меня есть, - это плохой пользователь, у которого есть файл с именем
.. -r
и напечатанrm *
.Является ли эта история правдой или нет, она стала классикой ненавистника Unix.
См . Справочник Unix-Haters , в котором есть введение самого Денниса Ритчи, для многих из этих примеров.
Кроме того, я добавлю, что избежание подобных проблем было главной силой при разработке Power Shell от Microsoft.
источник
OTOH, тот факт, что оболочка расширяет глобусы, а не прогаму, устраняет множество раздражающих несоответствий, присутствующих в других системах. Кроме того, вы можете использовать ту же команду для копирования файла из одного места в другое в файловой системе, на дискету или с Zip-диска на ленту.
Так что да, Unix несовместим. Как и другие системы, просто по-другому ;-)
источник
LISP, поддерживающий числа с бесконечной точностью по сравнению с C, поддерживающий только машинные целые числа, не является примером правильности языка. Это простой вопрос, возникающий из-за того, что у языков были очень разные цели дизайна.
Смысл C в том, чтобы быть языком, близким к машине, который можно было бы использовать для реализации операционных систем. Машины (в основном) не поддерживают десятичные числа с бесконечной точностью. Машины (в основном) имеют целые числа фиксированных битов.
источник