What is the reason to use such untelling system call names like time and creat instead of getCurrentTimeSecs and createFile or, maybe more suitable on Unix get_current_time_secs and create_file. Which brings me to the next point: why should someone want something like cfsetospeed without camel case or at least underscores to make it readable? Of course the calls would have more characters but we all know that readability of code is more important right?
4 Answers
It's due to the technical constraints of the time. The POSIX standard was created in the 1980s and referred to UNIX, which was born in the 1970. Several C compilers at that time were limited to identifiers that were 6 or 8 characters long, so that settled the standard for the length of variable and function names.
Related questions:
-
5I don't think Technical Constraints applies. You could have files larger than 6 bytes, you could have programs spanning thousands of lines of code; abstract syntax trees way deeper than just six-levels, and with way more nodes per level. Just out of reason, the 6 character limit can't be technical, but rather a designed one. And it does not explain why "creat" is better than "create". Also, can you please name those several C compiler you talk about? Your answer really reads like "heard somewhere somewhen".– phresnelCommented Jul 9, 2015 at 11:49
-
42@phresnel: He's not talking about file size, number of lines, or syntax tree depth. Old versions of the C language did not require compilers and linkers to keep more than the first 31 characters of identifiers with internal linkage, or more than 6 for external identifiers. Thus,
get_current_date()andget_current_time()couldn't be told apart by some of these early toolchains. The reason was that these systems were working on tiny footprints of a few kilobytes.– DevSolarCommented Jul 9, 2015 at 12:43 -
34But you're right on
creat(). Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: "I'd spell creat with an e."– DevSolarCommented Jul 9, 2015 at 12:45 -
8@phresnel: Having only limited memory is not a hard limit. Having only a limited guaranteed supported length of identifiers is. If you're only guaranteed 6 significant characters, that's what you're working with if you're worth your salt.– DevSolarCommented Jul 9, 2015 at 14:31
-
6FWIW, the old Fortran standards limited identifies to 6 characters. From this book: "The Fortran rule of six characters in one identifier stems from the fact that six characters could be represented in one IBM 704 word." I can't speak for C, but I imagine the limitation has an very similar origin (or perhaps, identical origin)– tpg2114Commented Jul 9, 2015 at 23:39
dr_ is right, but there's also another reason - usability. Back in the day, you didn't have something as comfortable as a keyboard to type on. If you were lucky, you had something akin to an old-school typewriter. If you were unlucky, you had to deal with systems that required actual physical work to operate (as in, it took a lot of force to press the "key"), or you manually punched holes in a card.
This meant that even within the 6-8 character limit, you tried to keep your commands as short as possible. That's why you have ls instead of list, and creat instead of create. Code from that era is full of variables like a, x and i - and of course, x2 and friends. Typing was a lot of work - today, you're less exerted from typing listIndex than you used to be from "typing" i - and it isn't even all that slower anymore (especially with additional technologies like auto-completion).
The real question is - why do so many Unix idioms persist even though they're no longer desirable?
-
24The day my kernel changes from
timetogetCurrentTimeSecsor something like that, I'll just stop upgrading it. Even with my comfortable keyboard and recent hardware, these names remain extremely convenient and simple (simplicity being one of UNIX's fundamentals). I really don't feel the need to bring that kind of Java/C#-style naming into the C language, let alone in a Linux kernel. IMO, from the perspective of a kernel developer, or UNIX developer in general, these idioms are nothing close to undesirable. Commented Jul 9, 2015 at 16:13 -
11@Benjoyo
unRootlyLongNamed.Packaged.nonsensicalFunctionis ugly to me, and I'd rather be sure what it does by doingman 2 timethan guess at what it seems to do.– muruCommented Jul 9, 2015 at 16:34 -
7@Benjoyo Well, anyone who is not used to this environment isn't supposed to use system calls in the first place, since they are specifically meant for those who are. (Standard) libraries are here for the others. UNIX does not follow these fashionable design "rules" that would make it easily understandable at first glance. Those who use it without looking into any doc are in for a lot of trouble, and few people in the UNIX community would consider that a problem to be solved. Commented Jul 9, 2015 at 16:44
-
5@JohnWHSmith sure kernel mode developers will know their system and its docs but that is no reason for not having concise and telling names.– BenjoyoCommented Jul 9, 2015 at 17:35
-
8@JohnWHSmith As a lowly dev who only ever wrote kernel drivers and prefers meaningful names that are not full of abbreviations I have to disagree. But that's alright, because if you look for example at the original git source code, you'll find at least one kernel dev agreeing with me. Although if you tell Linus that his
get_Xorremove_file_from_cache(might I proposermfc?) are undesirable to kernel developers, please do it publicly - I'd love to see his reaction.– VooCommented Jul 9, 2015 at 18:31
In addition to the other answers, I would like to point out that Unix was developed as a reaction to Multics, CTSS, and other contemporary operating systems, which were significantly more verbose about their naming conventions. You can get a feel for these OSes at http://www.multicians.org/devdoc.html. For example, http://www.multicians.org/mspm-bx-1-00.html gives change_name as the command for renaming a file; compare Unix mv.
Also, the principal reason why the very short system call names persist is backward compatibility. You will notice that newer APIs tend to be more explicit; e.g. gettimeofday and clock_gettime instead of just time.
(Even today, using whateverIndex instead of i for a loop index is an automatic code-review failure in my book ;-)
-
3Yeah. It's funny hearing the technological argument about hardware capabilities when LISP Machines predate UNIX. Sure, UNIX machines were cheaper to buy, but that's about it. Adding maintenance costs (which of course don't count in the *nix land) turned the tables even then, but it wasn't a persuasive enough argument anyway. (And yup,
iis fine for an index when you're, say, iterating an array. Coordinates? Usexandy. Traversing some ordinal? Be descriptive.)– LuaanCommented Jul 9, 2015 at 20:16 -
@Luaan LISP machines do NOT predate Unix. You fail.– user313992Commented Jun 17, 2019 at 20:06
-
@pizdelect That's technically true, but technical truth is not sufficient reason to snap at someone.– zwolCommented Jun 17, 2019 at 20:43
-
@pizdelect Sorry, I meant Lisp predates UNIX (and C). But LISP machines were essentially contemporary, if you compare their commercial impact (UNIX had a head start of about three years, but by the time LISP machines came, the commercial UNIX machines were still few and far between; most of UNIX was in academia or with no support). In any case, it's a response to the common technological arguments at the time, which was the 80s, when people were actually deciding between UNIX machines and LISPMs, and they were wrong. That changed with micro-computers which could run LISP faster anyway.– LuaanCommented Jun 18, 2019 at 6:59
Dennis Ritchie set himself a constraint with C that it wouldn't rely on any linker features that weren't also required by Fortran. Hence the 6 character limit on external names.
-
2@downvoter You may not agree with Denni Ritchie about this, but that's what he did. Taking it out on this answer is futile. Commented Dec 17, 2016 at 23:53
-
First rule of downvotes: don’t talk about downvotes. Commented May 10, 2022 at 9:57
ls -la | grepwould look like:listAllHiddenAndNormalFiles() | globallySearchARegularExpressionAndPrint().