Dlaczego nazwy systemowe wywołań UNIX / POSIX są tak nieczytelne?

43

Jaki jest powód używania takich nienazwanych nazw wywołań systemowych, takich jak timei creatzamiast getCurrentTimeSecsi createFilelub, a może bardziej odpowiednich w systemach Unix get_current_time_secsi create_file. Co prowadzi mnie do następnej kwestii: dlaczego ktoś miałby chcieć czegoś takiego cfsetospeedbez futerału na wielbłąda lub przynajmniej podkreśla, aby był czytelny? Oczywiście wywołania miałyby więcej znaków, ale wszyscy wiemy, że czytelność kodu jest ważniejsza, prawda?

history posix system-calls

— Benjoyo
źródło

42

Ponieważ zostały wynalezione kilkadziesiąt lat przed notacją węgierską, sprawa wielbłąda, sprawa węża i tym podobne stały się modne. Również dlatego, że wtedy kompilatory miały bardzo mało zasobów, a nazwy identyfikatorów były ograniczone do (IIRC) 8 znaków.

— lcd047,

3

@ phresnel Nie jestem pewien, jaki widzisz związek między nazwami plików a identyfikatorami zmiennych, ale tak, wahałem się między 8, 12 i 14. Być może limit wynosił również 14 dla zmiennych ID. Na pewno nie było 256+. Co do notacji: proszę zdefiniować „zawsze”. Czy Arminius używał słów CamelCase? Może nie. AFAIR, węgierski zapis wprowadzono dla systemu Windows na początku lat 90. CamelCase i sneak_case były późniejszymi odmianami. Oba były oczywiście wcześniej używane. Mówię, że stały się popularne około połowy lat 90.

— lcd047,

6

@phresnel: Zauważ, że twój link mówi o ograniczeniach pierwszego systemu plików Uniksa . When Thompson, Richie i in. były projektowaniu systemów z rodziny Unix, musieli bootstrap Unix na maszynach , które nie prowadzą jeszcze Unix , czyli prawdopodobnie w jeszcze bardziej ograniczonych środowiskach.

— DevSolar,

11

Równie dobrze możesz zapytać, dlaczego nie są napisane w języku niemieckim, ponieważ jest to najbliższe przybliżenie w języku naturalnym, jakie mogę wymyślić dla zbyt długich potworności, które Java nauczyła programistów akceptować ...

— R ..

12

Cieszę się, że tak jest. Wyobraź sobie, jak ls -la | grepbędzie wyglądać następująco: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya,

61

Wynika to z technicznych ograniczeń czasu. Standard POSIX został stworzony w latach 80. XX wieku i dotyczył UNIX, który narodził się w 1970 r. Kilka kompilatorów C w tym czasie było ograniczone do identyfikatorów o długości 6 lub 8 znaków, dzięki czemu ustalono standard długości zmiennej i funkcji nazwy.

Powiązane pytania:

— dr01
źródło

5

Nie sądzę, żeby obowiązywały ograniczenia techniczne . Możesz mieć pliki większe niż 6 bajtów, możesz mieć programy obejmujące tysiące wierszy kodu; abstrakcyjne drzewa składniowe znacznie głębsze niż tylko sześciopoziomowe i ze znacznie większą liczbą węzłów na poziom. Nie bez powodu limit 6 znaków nie może być techniczny, ale raczej zaprojektowany. I nie wyjaśnia, dlaczego „kreacja” jest lepsza niż „tworzenie”. Czy możesz również wymienić kilka kompilatorów C, o których mówisz? Twoja odpowiedź brzmi jak „gdzieś słyszałem”.

— fresnel

41

@phresnel: Nie mówi o rozmiarze pliku, liczbie linii ani głębokości drzewa składniowego. Stare wersje języka C nie wymagały od kompilatorów i konsolidatorów przechowywania więcej niż pierwszych 31 znaków identyfikatorów z wewnętrznym powiązaniem lub więcej niż 6 dla identyfikatorów zewnętrznych . Tak więc, get_current_date()i get_current_time()nie mogą być od siebie powiedział przez niektóre z tych wczesnych toolchains. Powodem było to, że systemy te działały na małych śladach o wielkości kilku kilobajtów.

— DevSolar

34

Ale masz rację creat(). Ken Thompson został kiedyś zapytany, co zrobiłby inaczej, gdyby przeprojektował system UNIX. Jego odpowiedź: „przeliteruję kreację za pomocą e”.

— DevSolar

8

@phresnel: Posiadanie ograniczonej pamięci nie jest trudnym ograniczeniem. Posiadanie ograniczonej gwarantowanej obsługiwanej długości identyfikatorów wynosi . Jeśli masz zagwarantowane tylko 6 znaczących postaci, z tym pracujesz, jeśli jesteś wart swojej soli.

— DevSolar

6

FWIW, stare ograniczone normy Fortran identyfikują do 6 znaków. Z tej książki : „Reguła sześciu znaków Fortrana w jednym identyfikatorze wynika z faktu, że w jednym słowie IBM 704 można przedstawić sześć znaków”. Nie mogę mówić w C, ale wyobrażam sobie, że ograniczenie ma bardzo podobne pochodzenie (a może identyczne pochodzenie)

— tpg2114

26

dr01 ma rację, ale jest też inny powód - użyteczność. Wcześniej nie było czegoś tak wygodnego jak klawiatura do pisania. Jeśli miałeś szczęście, miałeś coś podobnego do oldschoolowej maszyny do pisania. Jeśli miałeś pecha, musiałeś poradzić sobie z systemami, które wymagały faktycznej pracy fizycznej (ponieważ wciśnięcie klawisza wymagało dużej siły) lub ręcznie wybiłeś dziury w karcie.

Oznaczało to, że nawet w granicach 6-8 znaków starałeś się, aby polecenia były jak najkrótsze. Dlatego masz lszamiast listi creatzamiast create. Kod z tamtej epoki jest pełna zmiennych, takich jak a, xi i- i oczywiście, x2i przyjaciół. Pisanie na klawiaturze było bardzo pracochłonne - dzisiaj jesteś mniej obciążony pisaniem listIndexniż kiedyś „pisaniem na klawiaturze” i- i nie jest już wcale tak wolniejszy (szczególnie w przypadku dodatkowych technologii, takich jak automatyczne uzupełnianie).

Prawdziwe pytanie brzmi - dlaczego tak wiele idiomów uniksowych utrzymuje się, mimo że nie są już pożądane?

— Luaan
źródło

23

Dzień mój jądro zmienia się od timecelu getCurrentTimeSecsczy coś takiego, ja po prostu przestać to modernizacja. Nawet przy mojej wygodnej klawiaturze i najnowszym sprzęcie nazwy te pozostają niezwykle wygodne i proste (prostota jest jedną z podstaw UNIX-a). Naprawdę nie odczuwam potrzeby wprowadzania tego rodzaju nazw w stylu Java / C # do języka C, nie mówiąc już o jądrze Linuksa. IMO, z perspektywy programisty jądra lub ogólnie programisty UNIX, te idiomy są niczym niepożądanym .

— John WH Smith,

11

@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionjest dla mnie brzydka i wolę być pewna, co robi, man 2 timeniż zgadywać, co się wydaje.

— muru

7

@Benjoyo Cóż, nikt , kto nie jest przyzwyczajony do tego środowiska, nie powinien przede wszystkim używać wywołań systemowych, ponieważ są one przeznaczone specjalnie dla tych, którzy są. (Standardowe) biblioteki są dostępne dla innych. UNIX nie przestrzega tych modnych „zasad” projektowania , które sprawiłyby, że byłby łatwo zrozumiały na pierwszy rzut oka. Ci, którzy używają go bez przeglądania jakiegokolwiek dokumentu, mają wiele kłopotów, a niewiele osób w społeczności UNIX uznałoby ten problem za rozwiązany.

— John WH Smith,

4

@JohnWHSmith na pewno programiści trybu jądra znają swój system i jego dokumenty, ale to nie jest powód, dla którego nie ma zwięzłych i wymawiających nazw.

— Benjoyo,

7

@JohnWHSmith Jako skromny deweloper, który pisał tylko sterowniki jądra i preferuje znaczące nazwy, które nie są pełne skrótów, nie mogę się zgodzić. Ale to w porządku, ponieważ jeśli spojrzysz na przykład na oryginalny kod źródłowy git, znajdziesz co najmniej jednego programistę jądra, który się ze mną zgadza. Chociaż, jeśli powiem, że jego Linus get_Xlub remove_file_from_cache(mogę zaproponować rmfc?) Są niepożądane deweloperów jądra, zrób to publicznie - będę kochać , aby zobaczyć jego reakcję.

— Voo,

22

Oprócz innych odpowiedzi chciałbym zauważyć, że Unix został opracowany jako reakcja na Multics, CTSS i inne współczesne systemy operacyjne, które były znacznie bardziej gadatliwe na temat swoich konwencji nazewnictwa. Możesz zapoznać się z tymi systemami operacyjnymi na stronie http://www.multicians.org/devdoc.html . Na przykład http://www.multicians.org/mspm-bx-1-00.html podaje change_namejako polecenie zmiany nazwy pliku; porównaj Unix mv.

Głównym powodem utrzymywania się bardzo krótkich nazw wywołań systemowych jest również zgodność wsteczna. Zauważysz, że nowsze interfejsy API są bardziej wyraźne; np. gettimeofdayi clock_gettimezamiast po prostu time.

(Nawet dzisiaj użycie whateverIndexzamiast iindeksu pętli jest automatycznym błędem przeglądu kodu w mojej książce ;-)

— zwol
źródło

2

Tak. Zabawne jest słyszenie argumentu technologicznego o możliwościach sprzętowych, gdy maszyny LISP są wcześniejsze niż UNIX. Jasne, maszyny UNIX były tańsze w zakupie , ale o to chodzi. Dodanie kosztów utrzymania (które oczywiście nie liczą się w kraju * nix) obróciło tabele nawet wtedy, ale i tak nie był to wystarczająco przekonujący argument. (I tak, nadaje isię do indeksu, gdy, powiedzmy, iterujesz tablicę. Współrzędne? Użyj xi y. Przechodząc przez porządek porządkowy? Bądź opisowy.)

— Luaan

@Luejskie maszyny LISP NIE wyprzedzają Uniksa. Przegrywasz

— pizdelect

@pizdelect To technicznie prawda, ale prawda techniczna nie jest wystarczającym powodem, aby na kogoś zaskoczyć.

— zwolnienie

@pizdelect Przepraszam, miałem na myśli, że Lisp poprzedza UNIX (i C). Ale maszyny LISP były zasadniczo współczesne, jeśli porównać ich wpływ komercyjny (UNIX miał przewagę około trzech lat, ale zanim pojawiły się maszyny LISP, komercyjne maszyny UNIX były wciąż bardzo odległe; większość UNIX była w środowisku akademickim lub bez wsparcia). W każdym razie jest to odpowiedź na typowe argumenty technologiczne w tym czasie, czyli w latach 80., kiedy ludzie faktycznie decydowali między maszynami UNIX a LISPM i byli w błędzie. Zmieniło się to w przypadku mikrokomputerów, które i tak mogłyby szybciej uruchamiać LISP.

— Luaan

10

Dennis Ritchie nałożył na C ograniczenie, że nie będzie polegać na żadnych funkcjach linkera, które nie byłyby również wymagane przez Fortran. Stąd limit 6 znaków w nazwach zewnętrznych.

— użytkownik207421
źródło

@downvoter Możesz nie zgadzać się z Denni Ritchie w tej sprawie, ale właśnie to zrobił. Wyciągnięcie tego z tej odpowiedzi jest daremne.

— user207421,