UNIX / POSIX sistem çağrısı adları neden bu kadar okunaksız?

43

Bu tür boğucu olmayan sistemi kullanmanın nedeni, bunun yerine timeve creatyerine getCurrentTimeSecsve createFilebelki de Unix get_current_time_secsve create_file. Bu da beni bir sonraki noktaya getiriyor: neden birisi cfsetospeeddeve kasası olmadan veya en azından okunaklı kılmak için alt çizgi gibi bir şey istemeli ? Tabii ki çağrılar daha fazla karaktere sahip olacak ama hepimiz kodun okunabilirliğinin daha önemli olduğunu biliyoruz.

history posix system-calls

— Benjoyo
kaynak

42

Çünkü Macar gösteriminden on yıl önce icat edildiler, deve davası, yılan davası ve benzerleri moda oldu. Ayrıca, o zamanlar derleyiciler çok az kaynağa sahipti ve tanımlayıcı isimleri (IIRC) 8 karakterle sınırlıydı.

— lcd047

3

@ phresnel Dosya isimleri ve değişken ID'ler arasında ne gibi bir ilişki gördüğünüzden emin değilim, fakat evet, 8, 12 ve 14 arasında tereddüt ediyordum. Belki de değişken ID'ler için limit 14 idi. Kesinlikle 256+ değildi. İşaretlere gelince: lütfen "her zaman" ifadesini tanımlayın. Did Arminius CamelCase kelimeleri kullanmak? Belki de değil. AFAIR, Macar notasyonu 1990'lı yılların başında Windows için tanıtıldı. CamelCase ve sneak_case daha sonra varyasyonlardı. Her ikisi de elbette ondan önce kullanılıyordu. Demek istediğim onların 1990'ların ortalarında popüler hale geldikleri .

— lcd047

6

@ phresnel: Bağlantınızın ilk Unix dosya sisteminin sınırlamaları hakkında konuştuğunu unutmayın . Thompson, Richie ve ark. edildi tasarlarken Unix, onlar zorunda bootstrap makinelerde Unix henüz Unix çalıştırmak vermedi muhtemelen daha da kısıtlı ortamlarda yani.

— DevSolar

11

Neden Almanca yazılmadıklarını da sorabilirsiniz, çünkü bu Java'nın programcılara kabul etmeyi öğrettiği uzun süreli canavarlıklar için düşünebileceğim en yakın doğal dil yaklaşımı ile ilgili ...

— R.

12

Çok mutluyum bu böyle. Bir nasıl hayal ls -la | grepgibi görünecektir: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya,

61

Zamanın teknik kısıtlamaları nedeniyle. POSIX standardı 1980'lerde yaratıldı ve 1970'te doğan UNIX'e atıfta bulundu. O sırada birkaç C derleyicisi, 6 veya 8 karakter uzunluğunda tanımlayıcılarla sınırlıydı, böylece değişken ve fonksiyonun uzunluğu için standardı belirledi. isimler.

İlgili sorular:

— dr01
kaynak

5

Teknik Kısıtların geçerli olduğunu sanmıyorum . 6 bayttan büyük dosyalarınız olabilir, binlerce kod satırını kapsayan programlarınız olabilir; soyut sözdizimi ağaçları sadece altı seviyeden daha derin ve seviye başına daha fazla düğüm ile daha derinde. Sebepsiz olarak, 6 karakter sınırı teknik olamaz, daha ziyade tasarlanmış bir sınırdır. Ve neden “creat” ın “create” den daha iyi olduğunu açıklamıyor. Ayrıca, konuştuğunuz birkaç C derleyicisini adlandırabilir misiniz? Cevabınız gerçekten "bir yerlerde bir yerlerde duydum" gibi görünüyor.

— phresnel

41

@ phresnel: Dosya boyutu, satır sayısı veya sözdizimi ağacı derinliği hakkında konuşmuyor. C dilinin Eski versiyonları vermedi değil derleyiciler ve bağlayıcılar iç bağlantı ile tanımlayıcıları ilk 31 karakterden daha fazla devam ettirecek veya harici tanımlayıcıları için fazla 6 . Böylece, get_current_date()ve get_current_time()bu erken takımlardan bazıları tarafından söylenemezdi. Bunun nedeni, bu sistemlerin birkaç kilobaytlık küçük ayak izleri üzerinde çalışmasıydı .

— DevSolar

34

Ama haklısın creat(). Ken Thompson'a bir kez UNIX sistemini yeniden tasarlayıp tasarlamadığı konusunda ne yapacağı sorulmuştu. Cevabı: "Ben bir e ile creat heceleyeceğim."

— DevSolar

8

@ phresnel: Yalnızca sınırlı belleğe sahip olmak zor bir limit değildir. Tanımlayıcıların sadece sınırlı bir garanti desteklenen uzunluğa sahip olan . Yalnızca 6 önemli karakter garantili iseniz, tuzunuza değiyorsanız bununla birlikte çalışıyorsunuz.

— DevSolar

6

FWIW, eski Fortran standartlarına sınırlı 6 karakterden ibarettir. Gönderen bu kitapta : "altı karakter bir IBM 704 kelimeyle temsil edilebileceği gerçeğinden kaynaklanır tanımlayıcı birinde altı karakter Fortran kuralı" C için konuşamıyorum, ancak sınırlamanın çok benzer bir kökene (veya belki de özdeş kökene) sahip olduğunu tahmin ediyorum

— tpg2114

26

dr01 haklı, ancak başka bir neden daha var - kullanılabilirlik. Gündüzleri yazmak için klavyeniz kadar rahat bir şeyiniz yoktu. Şanslıysanız, eski okuldaki bir daktiloya benzer bir şeyiniz vardı. Şanssızsanız, gerçek fiziksel çalışmayı gerektiren sistemlerle uğraşmak zorunda kaldınız ("tuşa" basması çok fazla güç aldı) ya da bir karta elle delik açtınız.

Bu, 6-8 karakter sınırı dahilinde bile, komutlarınızı mümkün olduğunca kısa tutmaya çalıştığınız anlamına geliyordu. Eğer bu yüzden elimizde lsyerine listve creatyerine create. O dönemin kodu a, xve i- ve tabii ki x2ve arkadaşlarla değişkenlerle doludur . Yazma çok işti - bugün, yazmaya listIndexalışkın olduğunuzdan daha az zorlanıyorsunuz i- ve daha da yavaş (hepsi de otomatik tamamlama gibi ek teknolojilerle).

Asıl soru - neden bu kadar çok Unix deyimi arzu edilmese de devam ediyor?

— Luaan
kaynak

23

Benim çekirdek dan değiştiren gün timeiçin getCurrentTimeSecsveya böyle bir şey, sadece durdurma yükseltme o olacak. Rahat klavyem ve yeni donanımımla bile, bu isimler son derece kullanışlı ve basit kalıyor (basitlik UNIX'in temellerinden biri). Gerçekten bir Linux çekirdeğinde olmasa bile, bu tür Java / C # tarzı adlandırmalarını C diline getirme gereğini hissetmiyorum. IMO, bir çekirdek geliştiricisi veya genel olarak UNIX geliştiricisi perspektifinden bakıldığında, bu deyimler istenmeyen bir şeye yakın değildir .

— John WH Smith,

11

@ Benjoyo bana unRootlyLongNamed.Packaged.nonsensicalFunctionçok çirkin ve ne yaptığını man 2 timetahmin etmekten ziyade ne yaptığından emin olmayı tercih ederim .

— muru

7

@Benjoyo Peki, bu ortama alışkın olmayan hiç kimsenin, sistem çağrıları ilk etapta kullanması gerekmiyor, çünkü onlar özellikle olanlar için. (Standart) kütüphaneler diğerleri için burada. UNIX ilk bakışta kolayca anlaşılabilir kılacak bu şık tasarım "kurallarına" uymuyor . Kullanmak edenler herhangi bir dokümana bakmadan bir için olan çok sorun ve UNIX toplumda az insan sorunun çözülmesi gereken o ele alacak.

— John WH Smith

4

@ JohnWHSmith, çekirdek modu geliştiricilerinin kendi sistemlerini ve belgelerini bileceklerinden emindir, ancak özlü ve isimlendirici olmamak için bir neden yoktur .

— Benjoyo

7

@JohnWHSmith Sadece çekirdek sürücüleri yazan ve kısaltmaları olmayan anlamlı isimleri tercih eden alçak gönüllü bir ekip olarak aynı fikirde değilim. Fakat sorun değil, çünkü örneğin orijinal git kaynak koduna bakarsanız, en azından bir çekirdeği dev ile aynı fikirde olduğunuzu göreceksiniz. Onun yerine o Linus'a söylerseniz rağmen get_Xveya remove_file_from_cache(I önerebiliriz rmfc?) Geliştiriciler çekirdek arzu edilmez, alenen bunu lütfen - Ben istiyorum seviyorum onun tepkisini görmek için.

— Voo,

22

Diğer cevaplara ek olarak, Unix'in Multics, CTSS ve diğer çağdaş işletim sistemlerine bir reaksiyon olarak geliştirildiğini ve adlandırma kuralları hakkında çok daha ayrıntılı olanları belirtmek isterim. Bu işletim sistemleri için http://www.multicians.org/devdoc.html adresinden bir fikir edinebilirsiniz . Örneğin, http://www.multicians.org/mspm-bx-1-00.htmlchange_name bir dosyayı yeniden adlandırmak için komut verir ; Unix'i karşılaştırın mv.

Ayrıca, çok kısa sistem çağrısı adlarının kalıcı olmasının ana nedeni geriye dönük uyumluluktur. Yeni API’lerin daha açık olma eğiliminde olduğunu fark edeceksiniz; örneğin gettimeofdayve clock_gettimesadece yerine time.

(Bugün bile, bir döngü endeksi whateverIndexyerine kullanmak benim kitabımda iotomatik bir kod inceleme hatası ;-)

— Zwol
kaynak

2

Evet. LISP Makineleri UNIX’i seçtiğinde, donanım yetenekleri hakkındaki teknolojik argümanı duymak komik. Tabii ki, UNIX makineleri satın almak daha ucuz , ama bu konuda. Bakım maliyetlerinin eklenmesi (elbette * nix ülkesinde sayılmayan) o zaman bile masaları çevirdi, ama yine de yeterince ikna edici değildi. (Ve, ievet, bir diziyi xy

— yinelediğiniz

@Luaan LISP makineleri Unix'ten daha önce gelmez. Kaybettin.

— pizdelect

@pizdelect Bu teknik olarak doğrudur, ancak teknik gerçek, birine dokunmak için yeterli bir neden değildir.

— zwol

@pizdelect Üzgünüz, demek istediğim Lisp UNIX (ve C) öncesi. Ancak, LISP makineleri esasen çağdaşdı, ticari etkilerini karşılaştırırsanız (UNIX'in yaklaşık üç yıllık bir başlangıcı vardı, ancak LISP makineleri geldiğinde, ticari UNIX makineleri hala çok azdı ve UNIX'in çoğu akademide ya da desteksiz). Her durumda, o zamanlar, insanların UNIX makineleri ve LISPM'ler arasında karar verdikleri 80'li yılların ortak teknolojik argümanlarına bir cevap ve yanılıyorlardı. Bu LISP'yi daha hızlı çalıştırabilen mikro bilgisayarlarla değişti.

— Luaan

10

Dennis Ritchie, Fortran tarafından da gerekli olmayan herhangi bir bağlayıcı özelliğe dayanmayacağına C ile ilgili bir sınır koydu. Bu nedenle harici isimlerdeki 6 karakter sınırı.

— user207421
kaynak

@ downvoter Denni Ritchie ile bu konuda hemfikir olmayabilir, ancak yaptığı şey buydu. Bu cevaba cevap vermek boşuna.

— user207421,