Чому назви системних дзвінків UNIX / POSIX настільки нерозбірливі?

43

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

history posix system-calls

— Бенджойо
джерело

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

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

— R ..

12

Я такий щасливий, що таке. Уявіть , як ls -la | grepбуде виглядати так: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Пуя

61

Це пов'язано з технічними обмеженнями часу. Стандарт POSIX був створений у 1980-х роках і посилався на UNIX, який народився в 1970 році. Деякі компілятори С на той час обмежувалися ідентифікаторами, що мали 6 або 8 символів, так що врегульовано стандарт на довжину змінної та функції імена.

Пов’язані запитання:

— dr01
джерело

5

Я не думаю, що Технічні обмеження застосовуються. Ви можете мати файли більше 6 байт, у вас можуть бути програми, що охоплюють тисячі рядків коду; абстрактні синтаксичні дерева набагато глибші, ніж просто шість рівнів, і з набагато більше вузлів на рівень. По причині обмеження 6 символів не може бути технічним, а швидше спроектованим. І це не пояснює, чому «творити» краще, ніж «творити». Також, чи можете ви назвати ті кілька компіляторів С, про які ви говорите? Ваша відповідь дійсно звучить як "десь колись почута".

— phresnel

41

@phresnel: Він не говорить про розмір файлу, кількість рядків або глибину синтаксичного дерева. Старі версії мови C не вимагали від компіляторів і лінкерів зберігати більше, ніж перші 31 символ символів із внутрішнім зв’язком, або більше 6 для зовнішніх ідентифікаторів . Таким чином, get_current_date()і get_current_time()деякі з цих ранніх ланцюжків інструментів не могли їх розрізнити. Причина полягала в тому, що ці системи працювали на крихітних слідах у кілька кілобайт.

— DevSolar

34

Але ти маєш рацію creat(). Колись Кена Томпсона запитали, що він зробить інакше, якщо він переробив систему UNIX. Його відповідь: "Я б написав творець із e".

— DevSolar

8

@phresnel: Маючи лише обмежену пам’ять, це не є важким обмеженням. Мати обмежену гарантовану підтримувану довжину ідентифікаторів є . Якщо вам гарантовано лише 6 значущих персонажів, це те, з чим ви працюєте, якщо ви варті своєї солі.

— DevSolar

6

FWIW, старі норми Fortran обмежені ідентифікуються до 6 символів. З цієї книги : «Правило Fortran з шести символів в одному ідентифікаторі випливає з того, що шість символів могли бути представлені одним словом IBM 704». Я не можу говорити за С, але я думаю, що обмеження має дуже схоже походження (або, можливо, ідентичне походження)

— tpg2114

26

dr01 вірно, але є й інша причина - зручність використання. У той час у вас не було чогось зручного, як клавіатура для набору. Якщо вам пощастило, у вас було щось схоже на машинку для старої школи. Якщо вам не пощастило, вам довелося мати справу з системами, для роботи яких потрібна фактична фізична робота (як, наприклад, знадобилося чимало сил, щоб натиснути «клавішу»), або ви вручну пробивали дірки в картці.

Це означало, що навіть у межах 6-8 символів ви намагаєтеся зберегти свої команди якомога коротше. Ось чому ви маєте lsзамість list, а creatзамість create. Код з тієї епохи сповнений таких змінних, як a, xі i- звичайно, x2і друзів. Введення тексту було багато роботи - сьогодні ти менше вживаєш від введення тексту, listIndexніж раніше, ніж від "набору тексту" i- і це навіть не все повільніше (особливо з додатковими технологіями, такими як автоматичне завершення).

Справжнє питання - чому так багато ідіом Unix зберігається, хоча вони вже не бажані?

— Луань
джерело

23

Після того, як моє ядро зміниться timeна getCurrentTimeSecsщось подібне, я просто перестану його вдосконалювати. Навіть з моєю зручною клавіатурою та останнім обладнанням ці назви залишаються надзвичайно зручними та простими (простота є однією з основ UNIX). Я дійсно не відчуваю необхідності вводити такі імена Java / C # -style на мову C, не кажучи вже про ядро Linux. ІМО, з точки зору розробника ядра або розробника UNIX загалом, ці ідіоми нічим не близькі до небажаних .

— Джон У. Сміт

11

@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionце некрасиво до мене, і я волів би бути впевнений , що він робить, роблячи man 2 timeніж гадати, що це , здається, робить.

— muru

7

@Benjoyo Ну, хто не звик до цього середовища, в першу чергу не повинен використовувати системні дзвінки, оскільки вони спеціально призначені для тих, хто є. (Стандартні) бібліотеки є тут для інших. UNIX не дотримується цих модних "правил" дизайну, які б зробили його легко зрозумілим на перший погляд. Ті , хто використовує його , незважаючи до будь-який документ протягом багатьох неприємностей, і лише деякі люди в співтоваристві UNIX буде вважати , що проблема повинна бути вирішена.

— Джон У. Сміт

4

@JohnWHSmith впевнені, що розробники режиму ядра будуть знати свою систему та її документи, але це не є причиною для того, щоб не мати стислих і не говорити імен.

— Беньойо

7

@JohnWHSmith Як низький розробник, який лише коли-небудь писав драйвери ядра і віддає перевагу значущим іменам, не повним абревіатур, я не погоджуюся. Але це добре, тому що якщо ви подивитесь, наприклад, на оригінальний вихідний код git, ви знайдете принаймні один розробник ядра, який погодиться зі мною. Хоча , якщо ви скажете , що Лінус його get_Xабо remove_file_from_cache(я б запропонувати rmfc?) Небажані для розробників ядра, будь ласка , зробіть це публічно - я люблю , щоб побачити його реакцію.

— Voo

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 land), перетворило таблиці навіть тоді, але це все одно не було досить переконливим аргументом. (І так, iце добре для індексу, коли ви, скажімо, повторюєте масив. Координати? Використовуйте xі y. Переміщаєте деякі порядкові? Будьте описовими.)

— Луань,

@Luaan LISP машини НЕ передують Unix. Ви провалюєтеся.

— pizdelect

@pizdelect Це технічно правда, але технічна правда не є достатнім приводом, щоб хапати когось.

— zwol

@pizdelect Вибачте, я мав на увазі, що Lisp передує UNIX (і C). Але машини LISP були по суті сучасними, якщо порівнювати їх комерційний вплив (UNIX мав початок близько трьох років, але до моменту появи машин LISP, комерційних машин UNIX було ще мало і далеко між ними; більша частина UNIX була в академічних школах або без підтримки). У будь-якому випадку, це відповідь на загальні технологічні аргументи того часу, що були 80-х, коли люди насправді приймали рішення між машинами UNIX та LISPM, і вони помилялися. Це змінилося з мікрокомп'ютерами, які в будь-якому разі могли запустити LISP швидше.

— Луань

10

Денніс Річі поставив собі обмеження на C, що він не покладався на будь-які функції лінкера, які також не вимагали від Fortran. Звідси обмеження 6 символів для зовнішніх імен.

— user207421
джерело

@downvoter Ви можете не погодитися з Денні Річі з цього приводу, але це він зробив. Ознайомитися з цією відповіддю марно.

— користувач207421