Почему именования системных вызовов UNIX / POSIX так неразборчивы?

43

В чем причина использования таких неописуемых имен системных вызовов, как timeи creatвместо getCurrentTimeSecsи, createFileили, возможно, более подходящих для Unix get_current_time_secsи create_file. Что подводит меня к следующему пункту: почему кто-то хочет что-то вроде cfsetospeedбез верблюжьего футляра или, по крайней мере, подчеркивает, чтобы сделать его читабельным? Конечно, в вызовах будет больше символов, но мы все знаем, что читаемость кода важнее, верно?

history posix system-calls Benjoyo
источник
42
Потому что они были изобретены за несколько десятилетий до того, как венгерская нотация, верблюжья, змеиная и тому подобное стали модными. Кроме того, потому что тогда компиляторы имели очень мало ресурсов, а имена идентификаторов были ограничены (IIRC) 8 символами.
lcd047
3
@phresnel Не уверен, какую связь вы видите между именами файлов и идентификаторами переменных, но да, я колебался между 8, 12 и 14. Возможно, ограничение было также 14 для идентификаторов переменных. Это конечно не было 256+. Что касается обозначений: пожалуйста, определите «всегда». Ли Арминий использовать CamelCase слова? Возможно, нет. AFAIR, венгерская нотация была введена для Windows в начале 1990-х годов. CamelCase и sneak_case были более поздними вариантами. Оба были, конечно, использованы до этого. Я говорю о том, что они стали популярными примерно в середине 1990-х годов.
lcd047
6
@phresnel: обратите внимание, что ваша ссылка говорит об ограничениях первой файловой системы Unix . Когда Томпсон, Ричи и соавт. были проектирования Unix, они должны были самонастройки Unix на машинах , которые не работают Unix еще , т.е. , вероятно , еще более стесненных условиях.
DevSolar
11
Вы могли бы также спросить, почему они не написаны на немецком языке, потому что это - самое близкое приближение естественного языка, о котором я могу думать для слишком длинных чудовищ, которые Java научил программистов принимать ...
R ..
12
Я так счастлив, что это так. Представьте , как ls -la | grepбудет выглядеть так: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().
Пуя

Ответы:

61

Это связано с техническими ограничениями времени. Стандарт POSIX был создан в 1980-х годах и относился к UNIX, который родился в 1970-х годах. Несколько компиляторов C в то время были ограничены идентификаторами длиной 6 или 8 символов, так что они соответствовали стандарту для длины переменной и функции. имена.

Смежные вопросы:

dr01
источник
5
Я не думаю, что применяются технические ограничения . У вас могут быть файлы размером более 6 байт, у вас могут быть программы, занимающие тысячи строк кода; деревья абстрактного синтаксиса намного глубже, чем просто шесть уровней, и с гораздо большим количеством узлов на уровень. Просто по причине, ограничение в 6 символов не может быть техническим, а скорее разработанным. И это не объясняет, почему «создавать» лучше, чем «создавать». Кроме того, не могли бы вы назвать несколько компиляторов Си, о которых вы говорите? Ваш ответ действительно звучит как «когда-нибудь слышал».
френел
41
@phresnel: он не говорит о размере файла, количестве строк или глубине синтаксического дерева. Старые версии языка C не требовали, чтобы компиляторы и компоновщики хранили больше, чем первые 31 символ идентификатора с внутренней связью, или более 6 для внешних идентификаторов . Таким образом, get_current_date()и get_current_time()некоторые из этих ранних наборов инструментов не могут быть отличены друг от друга. Причина была в том, что эти системы работали на крошечных отпечатках в несколько килобайт.
DevSolar
34
Но ты прав creat(). Кена Томпсона однажды спросили, что бы он сделал по-другому, если бы он переделывал систему UNIX. Его ответ: «Я произнесу тварь с помощью е».
DevSolar
8
@phresnel: Наличие только ограниченной памяти не является жестким ограничением. Имея только ограниченную гарантированную поддерживаемую длину идентификаторов это . Если вам гарантировано только 6 значимых персонажей, это то, с чем вы работаете, если вы стоите своей соли.
DevSolar
6
FWIW, старые стандарты Fortran ограничены идентифицирует до 6 символов. Из этой книги : «Правило Фортрана шести символов в одном идентификаторе проистекает из того факта, что шесть символов могут быть представлены в одном слове IBM 704». Я не могу говорить за C, но я предполагаю, что ограничение имеет очень похожее происхождение (или, возможно, идентичное происхождение)
tpg2114
26

dr01 прав, но есть и другая причина - удобство использования. Раньше у вас не было такой удобной клавиатуры, чтобы набирать текст. Если вам повезло, у вас было что-то похожее на машинку старой школы. Если вам не повезло, вам приходилось иметь дело с системами, для работы которых требовалась реальная физическая работа (например, для нажатия «клавиши» потребовалось много сил), или вы вручную пробивали отверстия в карточке.

Это означало, что даже в пределах 6-8 символов вы пытались сделать свои команды максимально короткими. Вот почему вы lsвместо list, а creatвместо create. Код из той эпохи полон переменных, как a, xи i- и, конечно, x2и друзей. Печатание было большой работой - сегодня вы меньше listIndexиспытываете необходимость печатать, чем раньше - «печатать» i- и это даже не так уж и медленно (особенно при использовании дополнительных технологий, таких как автозаполнение).

Реальный вопрос - почему так много идиом Unix сохраняется, хотя они больше не желательны?

Luaan
источник
23
В тот день, когда мое ядро ​​изменится timeна getCurrentTimeSecsили что-то в этом роде, я просто перестану его обновлять. Даже с моей удобной клавиатурой и новейшим оборудованием эти названия остаются чрезвычайно удобными и простыми (простота является одной из основ UNIX). Я действительно не чувствую необходимости переводить такого рода имена в стиле Java / C # на язык C, не говоря уже о ядре Linux. IMO, с точки зрения разработчика ядра или разработчика UNIX в целом, эти идиомы ничем близко не нежелательны .
Джон У. С. Смит,
11
@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionэто некрасиво ко мне, и я предпочел бы быть уверен , что он делает, делая man 2 timeчем гадать, что это , кажется, делает.
Муру
7
@ Benjoyo Ну, любой, кто не привык к этой среде , не должен использовать системные вызовы, так как они специально предназначены для тех, кто это делает . (Стандартные) библиотеки здесь для других. UNIX не следует этим модным «правилам» дизайна , которые сделали бы его понятным на первый взгляд. Те, кто использует его, не заглядывая в какой-либо документ, могут столкнуться с большими трудностями, и мало кто из сообщества UNIX посчитает, что проблему нужно решить.
Джон У. С. Смит
4
@JohnWHS - уверен, что разработчики режима ядра будут знать свою систему и ее документы, но это не является причиной отсутствия кратких и чётких имен.
Бенжойо
7
@JohnWHSmith Как непритязательный разработчик, который когда-либо писал только драйверы ядра и предпочитает значимые имена, которые не полны аббревиатур, я должен не согласиться. Но это нормально, потому что если вы посмотрите, например, на оригинальный исходный код git, вы обнаружите, что по крайней мере один разработчик ядра согласен со мной. Хотя , если вы скажете , что Линус его get_Xили remove_file_from_cache(я бы предложить rmfc?) Нежелательны для разработчиков ядра, пожалуйста , сделайте это публично - я люблю , чтобы увидеть его реакцию.
Во
22

В дополнение к другим ответам я хотел бы отметить, что Unix был разработан как реакция на Multics, CTSS и другие современные операционные системы, которые были значительно более многословны в своих соглашениях об именах. Вы можете ознакомиться с этими операционными системами по адресу http://www.multicians.org/devdoc.html . Например, http://www.multicians.org/mspm-bx-1-00.html дает change_nameкоманду для переименования файла; сравнить Unix mv.

Кроме того , основная причина , почему имена очень короткий системного вызова сохраняются является обратная совместимость. Вы заметите, что более новые API имеют тенденцию быть более явными; например, gettimeofdayа clock_gettimeне просто time.

(Даже сегодня использование whateverIndexв iкачестве индекса цикла вместо индекса автоматической проверки кода в моей книге ;-)

zwol
источник
2
Да. Забавно слышать технологический аргумент об аппаратных возможностях, когда LISP Machines предшествовали UNIX. Конечно, машины UNIX были дешевле купить , но это все. Добавление затрат на обслуживание (которые, конечно, не учитываются на земле * nix) перевернуло таблицы даже тогда, но в любом случае это не было достаточно убедительным аргументом. (И да, iэто хорошо для индекса, когда вы, скажем, итерируете массив. Координаты? Использовать xи y. Обращаться к некоторому порядковому
номеру
Машины @Luaan LISP НЕ предшествуют Unix. Ты облажался.
pizdelect
@pizdelect Это технически верно, но техническая правда не является достаточной причиной, чтобы бросаться в глаза.
Звол
@pizdelect Извините, я имел в виду Lisp, предшествующий UNIX (и C). Но машины LISP были по сути современными, если сравнивать их коммерческое влияние (UNIX имел преимущество около трех лет, но к тому времени, когда появились машины LISP, коммерческих машин UNIX было еще немного, и большая часть UNIX была в академических кругах или без поддержки). В любом случае, это ответ на общепринятые технологические аргументы того времени, когда 80-е годы люди фактически выбирали между машинами UNIX и LISPM, и они ошибались. Это изменилось с микрокомпьютерами, которые в любом случае могли запускать LISP быстрее.
Луан
10

Деннис Ритчи ограничил себя тем, что C не будет полагаться на какие-либо функции компоновщика, которые также не требуются Фортрану. Отсюда ограничение в 6 символов для внешних имен.

user207421
источник
@ downvoter Вы можете не согласиться с Денни Ричи по этому поводу, но именно это он и сделал. Извлекать его из этого ответа бесполезно.
user207421