Tại sao các cuộc gọi hệ thống UNIX / POSIX lại không thể đọc được?

43

Lý do để sử dụng các tên gọi hệ thống chưa được gọi như vậy như thế nào timevà creatthay vì getCurrentTimeSecsvà, createFilehoặc có thể phù hợp hơn trên Unix get_current_time_secsvà create_file. Điều này đưa tôi đến điểm tiếp theo: tại sao một người nào đó muốn một cái gì đó như cfsetospeedkhông có vỏ lạc đà hoặc ít nhất là dấu gạch dưới để làm cho nó có thể đọc được? Tất nhiên các cuộc gọi sẽ có nhiều ký tự hơn nhưng tất cả chúng ta đều biết rằng khả năng đọc mã là quan trọng hơn phải không?

history posix system-calls

— Benjoyo
nguồn

42

Bởi vì chúng được phát minh trong nhiều thập kỷ trước khi ký hiệu Hungary, vỏ lạc đà, vỏ rắn và những thứ tương tự trở thành mốt. Ngoài ra bởi vì trước đó trình biên dịch có rất ít tài nguyên và tên định danh được giới hạn ở (IIRC) 8 ký tự.

— lcd047

3

@phresnel Không chắc bạn thấy mối quan hệ nào giữa tên tệp và ID biến, nhưng vâng, tôi đã do dự giữa 8, 12 và 14. Có lẽ giới hạn cũng là 14 đối với ID biến. Nó chắc chắn không phải là 256+. Đối với các ký hiệu: vui lòng xác định "luôn luôn". Đã Arminius sử dụng các từ CamelCase? Có thể không. AFAIR, ký hiệu Hungary đã được giới thiệu cho Windows vào đầu những năm 1990. CamelCase và sneak_case là những biến thể sau này. Cả hai đều được sử dụng trước đó. Điều tôi đang nói là chúng đã trở nên phổ biến vào giữa những năm 1990.

— lcd047

6

@phresnel: Lưu ý rằng liên kết của bạn nói về những hạn chế của hệ thống tệp Unix đầu tiên . Khi Thompson, Richie et al. đang thiết kế Unix, họ phải bootstrap Unix trên các máy chưa chạy Unix , tức là trong các môi trường thậm chí còn bị hạn chế hơn.

— DevSolar

11

Bạn cũng có thể hỏi tại sao họ không được viết bằng tiếng Đức, bởi vì đó về xấp xỉ ngôn ngữ tự nhiên gần nhất tôi có thể nghĩ ra cho các sinh vật quái dị quá dài Java đã dạy lập trình để chấp nhận ...

— R ..

12

Tôi rất vui vì nó như thế này. Hãy tưởng tượng một người ls -la | grepsẽ trông như thế nào : listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().

— Pouya

61

Đó là do những hạn chế kỹ thuật của thời gian. Tiêu chuẩn POSIX được tạo ra vào những năm 1980 và được gọi là UNIX, ra đời vào năm 1970. Một số trình biên dịch C tại thời điểm đó được giới hạn ở các định danh dài 6 hoặc 8 ký tự, do đó, đã giải quyết tiêu chuẩn về độ dài của biến và hàm tên.

Câu hỏi liên quan:

— dr01
nguồn

5

Tôi không nghĩ rằng các ràng buộc kỹ thuật được áp dụng. Bạn có thể có các tệp lớn hơn 6 byte, bạn có thể có các chương trình trải dài hàng ngàn dòng mã; cây cú pháp trừu tượng cách sâu hơn chỉ sáu cấp độ, và với nhiều nút hơn cho mỗi cấp độ. Không có lý do, giới hạn 6 ký tự không thể là kỹ thuật, mà là một thiết kế. Và nó không giải thích tại sao "creat" tốt hơn "tạo". Ngoài ra, bạn có thể vui lòng đặt tên cho một số trình biên dịch C mà bạn nói đến không? Câu trả lời của bạn thực sự đọc như "nghe ở đâu đó".

— phresnel

41

@phresnel: Anh ấy không nói về kích thước tệp, số lượng dòng hoặc độ sâu của cây cú pháp. Các phiên bản cũ của ngôn ngữ C không yêu cầu trình biên dịch và trình liên kết giữ nhiều hơn 31 ký tự đầu tiên của số nhận dạng có liên kết bên trong hoặc hơn 6 cho số nhận dạng bên ngoài . Do đó, get_current_date()và get_current_time()không thể được phân biệt bởi một số các công cụ ban đầu này. Lý do là các hệ thống này đang hoạt động trên những dấu chân nhỏ của vài kilobyte.

— DevSolar

34

Nhưng bạn đã đúng creat(). Ken Thompson đã từng được hỏi anh sẽ làm gì khác đi nếu thiết kế lại hệ thống UNIX. Anh trả lời: "Tôi đánh vần người tạo với một e."

— DevSolar

8

@phresnel: Chỉ có bộ nhớ giới hạn không phải là giới hạn cứng. Chỉ có một chiều dài được bảo đảm giới hạn được xác định là . Nếu bạn chỉ đảm bảo 6 ký tự quan trọng, đó là những gì bạn đang làm việc nếu bạn xứng đáng với muối của mình.

— DevSolar

6

FWIW, các tiêu chuẩn Fortran cũ giới hạn xác định là 6 ký tự. Từ cuốn sách này : "Quy tắc Fortran của sáu ký tự trong một mã định danh bắt nguồn từ thực tế là sáu ký tự có thể được biểu thị trong một từ 704 của IBM." Tôi không thể nói cho C, nhưng tôi tưởng tượng giới hạn có nguồn gốc rất giống nhau (hoặc có lẽ, nguồn gốc giống hệt nhau)

— tpg2114

26

dr01 là đúng, nhưng cũng có một lý do khác - khả năng sử dụng. Trước đây, bạn không có thứ gì thoải mái như bàn phím để gõ. Nếu bạn may mắn, bạn có một cái gì đó giống với một máy đánh chữ trường học cũ. Nếu bạn không may mắn, bạn phải xử lý các hệ thống yêu cầu hoạt động thể chất thực tế để hoạt động (như trong, phải mất rất nhiều lực để bấm "phím") hoặc bạn tự bấm lỗ vào thẻ.

Điều này có nghĩa là ngay cả trong giới hạn 6-8 ký tự, bạn đã cố gắng giữ các lệnh của mình càng ngắn càng tốt. Đó là lý do tại sao bạn có lsthay vì list, và creatthay vì create. Mã từ thời đại đó có đầy đủ các biến như a, xvà i- và tất nhiên, x2và bạn bè. Việc gõ là rất nhiều công việc - ngày nay, bạn ít phải sử dụng thao tác gõ listIndexhơn so với trước đây là "gõ" i- và nó thậm chí còn không chậm hơn nữa (đặc biệt là với các công nghệ bổ sung như tự động hoàn thành).

Câu hỏi thực sự là - tại sao rất nhiều thành ngữ Unix vẫn tồn tại mặc dù chúng không còn được mong muốn nữa?

— Luaan
nguồn

23

Ngày hôm hạt nhân của tôi thay đổi từ timetới getCurrentTimeSecshoặc một cái gì đó như thế, tôi sẽ chỉ dừng nâng cấp nó. Ngay cả với bàn phím thoải mái và phần cứng gần đây của tôi, những cái tên này vẫn cực kỳ tiện lợi và đơn giản (đơn giản là một trong những nguyên tắc cơ bản của UNIX). Tôi thực sự không cảm thấy cần phải đưa kiểu đặt tên Java / C # đó vào ngôn ngữ C, chứ đừng nói gì đến nhân Linux. IMO, từ quan điểm của một nhà phát triển hạt nhân, hay nhà phát triển UNIX nói chung, những thành ngữ này không có gì là không mong muốn .

— John WH Smith

11

@Benjoyo unRootlyLongNamed.Packaged.nonsensicalFunctionlà xấu xí đối với tôi, và tôi muốn chắc chắn những gì nó làm bằng cách làm man 2 timehơn là đoán những gì nó dường như làm.

— muru

7

@Benjoyo Chà, bất cứ ai không quen với môi trường này đều không được phép sử dụng các cuộc gọi hệ thống ngay từ đầu, vì chúng đặc biệt dành cho những người này. (Tiêu chuẩn) thư viện ở đây cho những người khác. UNIX không tuân theo các "quy tắc" thiết kế thời trang này mà có thể dễ hiểu ngay từ cái nhìn đầu tiên. Những người sử dụng nó mà không xem xét bất kỳ tài liệu nào cũng gặp nhiều rắc rối và rất ít người trong cộng đồng UNIX sẽ coi đó là một vấn đề cần giải quyết.

— John WH Smith

4

@JohnWHSmith chắc chắn các nhà phát triển chế độ kernel sẽ biết hệ thống và tài liệu của họ nhưng đó không phải là lý do để không súc tích và nói tên.

— Benjoyo

7

@JohnWHSmith Là một nhà phát triển thấp, người chỉ viết trình điều khiển hạt nhân và thích những cái tên có ý nghĩa không đầy đủ các từ viết tắt, tôi phải không đồng ý. Nhưng điều đó không sao, bởi vì nếu bạn tìm ví dụ về mã nguồn git ban đầu, bạn sẽ tìm thấy ít nhất một nhà phát triển hạt nhân đồng ý với tôi. Mặc dù nếu bạn nói với Linus rằng mình get_Xhay remove_file_from_cache(tôi có thể đề nghị rmfc?) Là không mong muốn tới kernel nhà phát triển, xin vui lòng làm điều đó công khai - Tôi muốn yêu để xem phản ứng của mình.

— Voo

22

Ngoài các câu trả lời khác, tôi muốn chỉ ra rằng Unix được phát triển như một phản ứng đối với Multics, CTSS và các hệ điều hành đương đại khác, dài hơn đáng kể về quy ước đặt tên của chúng. Bạn có thể cảm nhận về các HĐH này tại http://www.multologists.org/devdoc.html . Ví dụ: http://www.multologists.org/mspm-bx-1-00.html đưa ra change_namelàm lệnh đổi tên tệp; so sánh Unix mv.

Ngoài ra, lý do chính tại sao các tên gọi hệ thống rất ngắn vẫn tồn tại là khả năng tương thích ngược. Bạn sẽ nhận thấy rằng các API mới hơn có xu hướng rõ ràng hơn; ví dụ gettimeofdayvà clock_gettimethay vì chỉ time.

(Ngay cả ngày nay, sử dụng whateverIndexthay vì ichỉ mục vòng lặp là một lỗi tự động xem lại mã trong cuốn sách của tôi ;-)

— zwol
nguồn

2

Vâng. Thật buồn cười khi nghe cuộc tranh luận về công nghệ về khả năng phần cứng khi LISP Machines có trước UNIX. Chắc chắn, các máy UNIX đã rẻ hơn để mua , nhưng đó là về nó. Thêm chi phí bảo trì (tất nhiên không được tính vào vùng đất * nix) đã biến các bảng ngay cả sau đó, nhưng dù sao đó cũng không phải là một lý lẽ đủ thuyết phục. (Và yup, isẽ tốt cho một chỉ mục khi bạn nói, lặp đi lặp lại một mảng. Tọa độ? Sử dụng xvà y. Đi qua một số thứ tự? Hãy mô tả.)

— Luaan

@Luaan Máy LISP KHÔNG có trước Unix. Bạn thất bại.

— pizdelect

@pizdelect Điều đó đúng về mặt kỹ thuật, nhưng sự thật kỹ thuật không đủ lý do để chộp lấy ai đó.

— zwol

@pizdelect Xin lỗi, ý tôi là Lisp có trước UNIX (và C). Nhưng các máy LISP về cơ bản là hiện đại, nếu bạn so sánh tác động thương mại của chúng (UNIX đã khởi đầu được khoảng ba năm, nhưng vào thời điểm các máy LISP xuất hiện, các máy UNIX thương mại vẫn còn rất ít, hầu hết UNIX đều ở trong học viện hoặc không có sự hỗ trợ). Trong mọi trường hợp, đó là phản ứng đối với các lập luận công nghệ phổ biến vào thời điểm đó, đó là những năm 80, khi mọi người thực sự quyết định giữa các máy UNIX và LISPM, và họ đã sai. Điều đó đã thay đổi với các máy vi tính có thể chạy LISP nhanh hơn.

— Luaan

10

Dennis Ritchie tự đặt ra một ràng buộc với C rằng nó sẽ không phụ thuộc vào bất kỳ tính năng liên kết nào mà Fortran không yêu cầu. Do đó giới hạn 6 ký tự cho tên bên ngoài.

— người dùng207421
nguồn

@downvoter Bạn có thể không đồng ý với Denni Ritchie về điều này, nhưng đó là những gì anh ấy đã làm. Lấy nó ra câu trả lời này là vô ích.

— dùng207421