ทำไมระบบ UNIX / POSIX จึงเรียกการ namings ว่าอ่านไม่ออก?

43

เป็นเหตุผลที่จะใช้ชื่อเรียกระบบ untelling เช่นอะไรtimeและcreatแทนgetCurrentTimeSecsและcreateFileหรืออาจจะเหมาะสมกว่าบน Unix และget_current_time_secs create_fileซึ่งนำฉันไปยังจุดต่อไป: ทำไมบางคนควรต้องการบางสิ่งบางอย่างเช่นcfsetospeedโดยไม่มีกรณีอูฐหรืออย่างน้อยก็ขีดเพื่อให้สามารถอ่านได้? แน่นอนว่าการโทรจะมีตัวอักษรมากขึ้น แต่เราทุกคนรู้ว่าการอ่านโค้ดมีความสำคัญมากกว่าใช่มั้ย

history posix system-calls

— Benjoyo
แหล่งที่มา

42

เพราะพวกเขาคิดค้นมาหลายสิบปีก่อนหน้าสัญกรณ์ฮังการี, กล่องอูฐ, กล่องงูและสิ่งที่คล้ายกันกลายเป็นแฟชั่น และเนื่องจากคอมไพเลอร์ด้านหลังมีทรัพยากรน้อยมากและชื่อตัวระบุถูก จำกัด ไว้ที่ (IIRC) 8 ตัวอักษร

— lcd047

3

@phresnel ไม่แน่ใจว่าคุณเห็นความสัมพันธ์ระหว่างชื่อไฟล์และ ID ตัวแปรอย่างไรใช่ฉันลังเลระหว่าง 8, 12 และ 14 อาจมีข้อ จำกัด ที่ 14 สำหรับ ID ตัวแปร มันไม่ใช่ 256+ แน่นอน สำหรับสัญลักษณ์: โปรดกำหนด "เสมอ" ไม่อาร์มิเนียใช้คำ CamelCase? อาจจะไม่. AFAIR สัญกรณ์ฮังการีได้รับการแนะนำสำหรับ Windows ในต้นปี 1990 CamelCase และ sneak_case เป็นรูปแบบที่เปลี่ยนแปลงในภายหลัง แน่นอนว่าทั้งคู่เคยใช้กันมาก่อน สิ่งที่ฉันพูดคือพวกเขาได้รับความนิยมในช่วงกลางปี 1990

— lcd047

6

@phresnel: โปรดทราบว่าลิงก์ของคุณพูดถึงข้อ จำกัด ของระบบไฟล์Unixแรก เมื่อ ธ อมป์สันริชชี่และคณะ กำลังออกแบบ Unix พวกเขาต้องbootstrap Unix บนเครื่องที่ไม่ได้ใช้ Unix เลยเช่นในสภาพแวดล้อมที่มีข้อ จำกัด มากขึ้น

— DevSolar

11

คุณอาจจะถามว่าทำไมพวกเขาถึงไม่เขียนเป็นภาษาเยอรมันเพราะนั่นเป็นเรื่องเกี่ยวกับการประมาณค่าภาษาธรรมชาติที่ใกล้เคียงที่สุดที่ฉันสามารถนึกได้สำหรับสิ่งที่น่ารังเกียจในระยะยาว Java ได้สอนโปรแกรมเมอร์ให้ยอมรับ ...

— R ..

12

ฉันมีความสุขมากที่มันเป็นอย่างนี้ ลองนึกภาพว่าls -la | grepจะเป็นอย่างไร: listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya

61

มันเป็นเพราะข้อ จำกัด ทางเทคนิคของเวลา มาตรฐาน POSIX ถูกสร้างขึ้นในปี 1980 และอ้างอิงถึง UNIX ซึ่งเกิดในปี 1970 คอมไพเลอร์ C หลาย ๆ ตัวในเวลานั้น จำกัด อยู่ที่ตัวระบุที่มีความยาว 6 หรือ 8 ตัวอักษรดังนั้นจึงตัดสินมาตรฐานสำหรับความยาวของตัวแปรและฟังก์ชัน ชื่อ

คำถามที่เกี่ยวข้อง:

— dr01
แหล่งที่มา

5

ฉันไม่คิดว่าจะมีข้อ จำกัด ทางเทคนิค คุณสามารถมีไฟล์ที่มีขนาดใหญ่กว่า 6 ไบต์คุณสามารถมีโปรแกรมที่ครอบคลุมโค้ดหลายพันบรรทัด ต้นไม้ที่เป็นนามธรรมมีความลึกกว่าแค่หกระดับและมีโหนดมากขึ้นต่อระดับ ด้วยเหตุผลที่ จำกัด จำนวนอักขระ 6 ตัวนั้นไม่สามารถเป็นเรื่องทางเทคนิคได้ แต่เป็นการออกแบบที่ จำกัด และไม่ได้อธิบายว่าทำไม "creat" ดีกว่า "create" นอกจากนี้คุณช่วยบอกชื่อผู้รวบรวม C หลายคนที่คุณพูดถึงได้ไหม? คำตอบของคุณอ่านอย่างเช่น

— phresnel

41

@phresnel: เขาไม่ได้พูดถึงขนาดไฟล์จำนวนบรรทัดหรือความลึกของต้นไม้ไวยากรณ์ รุ่นเก่าของภาษา C ไม่ไม่ต้องใช้คอมไพเลอร์และ Linkers เพื่อให้มากขึ้นกว่า 31 ตัวอักษรแรกของตัวระบุมีความเชื่อมโยงภายในหรือมากกว่า 6 ตัวบ่งชี้สำหรับภายนอก ดังนั้นget_current_date()และget_current_time()ไม่สามารถบอกแยกจากเครื่องมือเริ่มต้นเหล่านี้บางส่วนได้ เหตุผลก็คือระบบเหล่านี้ทำงานบนรอยเท้าขนาดเล็กเพียงไม่กี่กิโลไบต์

— DevSolar

34

creat()แต่คุณขวาบน Ken Thompson เคยถูกถามว่าเขาจะทำอะไรที่แตกต่างกันถ้าเขาออกแบบระบบยูนิกซ์ใหม่ คำตอบของเขา: "ฉันสะกด creat ด้วย e"

— DevSolar

8

@phresnel: การมีหน่วยความจำที่ จำกัด เท่านั้นไม่ใช่ขีด จำกัด มีเพียง จำกัด การรับประกันระยะเวลาในการสนับสนุนของตัวระบุเป็น หากคุณรับประกันตัวละครที่สำคัญเพียง 6 ตัวนั่นคือสิ่งที่คุณกำลังทำงานด้วยหากคุณควรค่ากับเกลือ

— DevSolar

6

FWIW มาตรฐาน Fortran แบบเก่า จำกัด ระบุถึง 6 ตัวอักษร จากหนังสือเล่มนี้ : "กฎ Fortran ของตัวละครหกตัวในตัวระบุเดียวเกิดขึ้นจากข้อเท็จจริงที่ว่าตัวอักษรหกตัวสามารถแสดงได้ในคำ 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 #-style การตั้งชื่อมาเป็นภาษา C ให้อยู่คนเดียวในเคอร์เนล Linux IMO จากมุมมองของนักพัฒนาเคอร์เนลหรือผู้พัฒนาระบบปฏิบัติการยูนิกซ์โดยทั่วไปเหล่านี้สำนวนมีอะไรใกล้เคียงกับที่ไม่พึงประสงค์

— John WH Smith

11

@ Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionเป็นที่น่าเกลียดสำหรับฉันและฉันค่อนข้างแน่ใจว่าสิ่งที่มันทำโดยการทำman 2 timeกว่าเดาในสิ่งที่ดูเหมือนว่าจะทำ

— muru

7

@Benjoyo อืมทุกคนที่ไม่ได้คุ้นเคยกับสภาพแวดล้อมนี้ไม่ควรที่จะใช้การเรียกของระบบในสถานที่แรกเพราะพวกเขามีความหมายเฉพาะสำหรับผู้ที่เป็น (Standard)ไลบรารี่สำหรับคนอื่น ๆ UNIX ไม่ปฏิบัติตาม"กฎ" การออกแบบที่ทันสมัยเหล่านี้ซึ่งจะทำให้เข้าใจได้ง่ายในแวบแรก บรรดาผู้ที่ใช้งานได้โดยไม่ต้องมองเข้าไปในเอกสารใด ๆ ที่อยู่ในการจำนวนมากของปัญหาและไม่กี่คนในชุมชน UNIX จะพิจารณาว่าปัญหาที่จะแก้ไข

— John WH Smith

4

@JohnWHS ด้วยแน่ใจว่าผู้พัฒนาโหมดเคอร์เนลจะรู้ว่าระบบและเอกสารของพวกเขา แต่นั่นเป็นเหตุผลที่ไม่มีชื่อที่รัดกุมและบอกชื่อ

— Benjoyo

7

@ JohnWHSmith ในฐานะนักพัฒนาซอฟต์แวร์ระดับต่ำที่เคยเขียนไดรเวอร์เคอร์เนลและชอบชื่อที่มีความหมายซึ่งไม่ได้เต็มไปด้วยตัวย่อฉันต้องไม่เห็นด้วย แต่ก็ไม่เป็นไรเพราะถ้าคุณดูตัวอย่างที่ซอร์สโค้ด git ดั้งเดิมคุณจะพบเคอร์เนล dev อย่างน้อยหนึ่งตัวที่เห็นด้วยกับฉัน แม้ว่าคุณจะบอก Linus ว่าเขา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คำสั่งเพื่อเปลี่ยนชื่อไฟล์ mvเปรียบเทียบระบบปฏิบัติการยูนิกซ์

นอกจากนี้เหตุผลหลักว่าทำไมชื่อระบบที่สั้นมากยังคงมีอยู่คือความเข้ากันได้แบบย้อนหลัง คุณจะสังเกตเห็นว่า API ที่ใหม่กว่านั้นมีความชัดเจนมากกว่า เช่นgettimeofdayและแทนเพียงclock_gettimetime

(แม้กระทั่งทุกวันนี้การใช้whateverIndexแทนiดัชนีลูปคือความล้มเหลวในการตรวจสอบโค้ดอัตโนมัติในหนังสือของฉัน ;-)

— zwol
แหล่งที่มา

2

ใช่. เป็นเรื่องตลกที่ได้ยินข้อโต้แย้งทางเทคโนโลยีเกี่ยวกับความสามารถของฮาร์ดแวร์เมื่อ LISP Machines มีคุณสมบัติเป็น UNIX แน่นอนว่าเครื่อง UNIX นั้นถูกกว่าที่จะซื้อแต่นั่นเป็นเรื่องของมัน การเพิ่มค่าใช้จ่ายในการบำรุงรักษา (ซึ่งไม่นับในที่ดิน * ระวัง) ก็เปลี่ยนตารางได้ แต่ก็ไม่ได้เป็นข้อโต้แย้งที่น่าเชื่อถือเพียงพอ (และ yup iเป็นสิ่งที่ดีสำหรับดัชนีเมื่อคุณพูดว่าทำซ้ำอาร์เรย์พิกัดใช้xและy. traversing ลำดับที่บางอย่างจะอธิบาย)

— Luaan

@ Luaan LISP เครื่องไม่ได้ลงวันที่ล่วงหน้ากับ Unix คุณล้มเหลว

— pizdelect

@pizdelect นั่นเป็นความจริงทางเทคนิค แต่ความจริงทางเทคนิคนั้นไม่มีเหตุผลเพียงพอที่จะสแน็ปอินใครสักคน

— zwol

@pizdelect ขออภัยฉันหมายถึง Lisp predates UNIX (และ C) ถ้าคุณเปรียบเทียบผลกระทบเชิงพาณิชย์ของพวกเขา (UNIX มีจุดเริ่มต้นประมาณสามปีที่ผ่านมา แต่เมื่อถึงเวลาที่เครื่อง LISP มาถึงเครื่อง UNIX เชิงพาณิชย์ก็ยังมีอยู่ไม่มากนักส่วนใหญ่ UNIX อยู่ในวงการวิชาการหรือ ไม่มีการสนับสนุน) ไม่ว่าในกรณีใดมันเป็นการตอบสนองต่อข้อโต้แย้งทางเทคโนโลยีที่เกิดขึ้นในยุคนั้นซึ่งก็คือยุค 80 เมื่อผู้คนกำลังตัดสินใจระหว่างเครื่อง UNIX กับ LISPM และพวกเขาคิดผิด นั่นเปลี่ยนไปด้วยไมโครคอมพิวเตอร์ที่สามารถรัน LISP ได้เร็วขึ้น

— Luaan

10

Dennis Ritchie ตั้งข้อ จำกัด กับ C ว่าจะไม่พึ่งพาคุณสมบัติลิงเกอร์ใด ๆ ที่ Fortran ไม่ต้องการ ดังนั้นการ จำกัด จำนวนอักขระ 6 ตัวสำหรับชื่อภายนอก

— user207421
แหล่งที่มา

@downvoter คุณอาจไม่เห็นด้วยกับ Denni Ritchie เกี่ยวกับสิ่งนี้ แต่นั่นคือสิ่งที่เขาทำ การตอบคำถามนี้ไร้ประโยชน์

— user207421