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

20

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

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

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

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

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

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

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

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

Эллен Спертус
источник
6
Если вам любопытно, это не домашнее задание. Я учитель :-) Если подумать, может быть, это делает мою домашнюю работу.
Эллен Спертус
4
Я изо всех сил пытаюсь понять, почему этот вопрос не касается Unix и Linux (или, может быть, Software Engineering ?). Можете ли вы уточнить, каким образом вам нужен взгляд CS по этому вопросу? Также уточните, хотите ли вы положительных или отрицательных примеров.
Рафаэль
Разве этот вопрос больше не подходит для programmers.stackexchange.com ?
Василий Старынкевич,
Я опубликовал это в CS, потому что считаю языковой дизайн одной из фундаментальных глубоких областей информатики, охватывающих вычислимость, сложность, архитектуру, удобство использования и т. Д. Я мог бы опубликовать это в Unix / Linux, хотя я искал более широкую Посмотреть. Что касается программистов, люди почти всегда враждебны ко мне, когда я пишу там, даже когда я думаю, что я нахожусь по теме, поэтому я держусь от этого подальше.
Эллен Спертус

Ответы:

15

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

Команды 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», но такие устройства, как звуковые карты, даже не очень хорошо подходят.

Брюс Эдигер
источник
Хороший ответ. Когда я увидел заголовок, я сразу подумал «ioctl» (и fcntl), но теперь мне не нужно вводить ответ.
Луи
1
шаблоны глобуса не являются регулярными выражениями
.
8

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

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

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

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

Daniil
источник
8

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

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

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

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

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

Марк Доминус
источник
Запрещение /не является произвольным, необходимо (?) Устранить неоднозначности, как /и разделитель пути. Я только что создал файл 000, очевидно, что конкретные ограничения исчезли во времена современной GNU / Linux.
Рафаэль
Я не хотел сказать, что запрет /был произвольным, только ограничения длины строки и размера файла были произвольными. Однако дело в том, что другой дизайн мог позволить именам файлов содержать косую черту, но разработчики Unix не сделали этого. считаю это важным.
Марк Доминус
Я уверен, что в то время эти ограничения были введены из соображений производительности; неразвитые методы могут играть в это тоже. С сегодняшней точки зрения они кажутся сомнительными, это точно. Что касается /меня, мне любопытно: если путь должен быть закодирован в виде строки, как вы можете это сделать без зарезервированного символа для разделения пути?
Рафаэль
Я не понимаю, в чем ваша точка зрения. Вопрос требует «примеров непоследовательности и неполноты в Unix / C»; это не касается производительности.
Марк Доминус
1
@Raphael: Вы избавляетесь от глупых проблем с разделителями, определяя pathабстрактный тип данных, и используете его в своих интерфейсах вместо предоставления конкретной реализации (строки ascii с нулевым символом в конце).
Блуждающая логика
4

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


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

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

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

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

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

С. Роберт Джеймс
источник
Я прочитал эссе Ричарда Габриэля в конце Руководства Unix-Haters. :-)
Эллен Спертус
3
  • Конечно, несметное количество одинаковых (коротких) флагов для команд является несоответствием.
  • Каждая программа, использующая регулярные выражения, имеет собственный синтаксис для них.
  • Все файлы конфигурации для сервисов имеют разный синтаксис (его можно частично простить, ваш демон почтовой программы имеет мало общего с вашим веб-сервером или загрузкой системы, но все же)
  • Есть разные редакторы! Пользователи используют разные оболочки !! Почему так много окружений рабочего стола?!?

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

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

vonbrand
источник
2

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

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

Дейв
источник