Why do old C-style method names continue being used in modern languages? [duplicate]
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
I understand that in the earlier days of computing, shorter method names like printf made sense, because storage was limited. But why do modern languages like Python and Go still use the less readable names from the C APIs? Why don't they switch to a more readable form like print_format, the same goes for other names. I wouldn't mind having to write make_directory instead of mkdir in go.
People have suggested that this question has been asked before, but the questions I've found are about whether abbreviated names are bad practice. This question assumes that the answer to this question is usually yes.
Solution
But why do modern languages like python and go still use the less readable names from the C apis?
Because everyone (in their domain) knows the short names. If you made different names, people would question "what makes this different from
mkdir?" and generally get confused that stuff isn't where they expect it.Because without auto-complete in an IDE, long names with generally difficult to type characters like _ annoy skilled programmers. Annoyed programmers limit the adoption of a language, meaning designers don't make the names or you never hear about the languages that used them since they never took off.
These are both kinda flimsy arguments of course.
Readable code is known to be better than writable code these days. And having an IDE with auto-complete handles option 2, though there are still people who argue against IDE's as bloat, or a crutch that hinder programmers' abilities. Having an IDE with intellisense (or the equivalent) helps a bunch with #1 as well, though that has the same arguments and works less well in a non-object oriented environment.
Still, these flimsy arguments (and the vagaries of human taste) are enough momentum to keep the trend going.
OTHER TIPS
Why do we continue to use the old Germanic "Albert" as a boys name and not the modern English translation "Shining Hero"?
Because a name is just a label. It's good to give new stuff a meaningful name, but, after long usage the name itself becomes the meaning.
printf means something very specific to generations of programmers -- a print function with a template that will use %2d to indicate where you want a two digit number printed etc.
On the other hand print_format would indicate a function that will somehow format and print some data and you will need to look up the docs to find out how to use it.
It's simple. Using the traditional names is convenient for millions of experienced programmers. We know what "mkdir" and "printf" mean. It is slightly inconvenient for novices, but they soon get over it.
Similarly, most (all?) LISP dialects continue to use "car" and "cdr" instead of "head" and "tail".
As others have already said, a lot of these keywords have well established meanings and make it very easy to pickup a new language etc. They are usually shorthand for existing words by omitting some letters (mostly vowels), its not like someone mashed random letters and decided, 'eokjgv' is going to be my function for make_directory.
Shorter names do have actual benefits beyond not having to rely on auto complete:
- Can fit more context into fewer lines or a single screen
- No confusion of trying to reconcile strict computer science meaning with the common language meaning
- Faster disambiguation: if you want to distinguish between
print_formatted_string,print_formatted_string_from_file,print_string_with_lineit will take far longer thanprintf,sprintf,println.
Of course, inertia and culture are also massive factors - in common languages, your question is similar to asking: Why don't people switch to Esperanto instead of English with its confusing grammar and huge vocabulary?
You can see verbose programs by reading pseudocode : create pseudocode for some small method and see how much volume is added to it, and remember that human short term memory is also a finite quantity.
Because your assumption that "longer names are better readable" is simply not true!
On the contrary, the shorter a name, the higher the chances (other things being equal), that you can identify the name at once, like an icon.
But there's more: the chances that you confuse identifiers that have only a few differences is greater the longer the names are.
As always, there is a middle ground. A public method in an API should not be a single letter, and a temporary local variable must notbe a poem.
Mandatory xkcd reference:
Let's say you design a language, or a next version of an existing language, and say "let's forget the old C-style names, I have a better idea". You rename mkdir to make_directory. Someone else, following the same way of thinking, invents create_directory, a third one create_dir, the next one new_directory, and so on. Now the programmers have a much harder time learning a new language or a new dialect, because instead of instantly recognizing what a command does and what parameters it expects, they have to read through the manual. By not having the same names and structure, it can be much more likely to have a different use or different order of parameters (if I remember correctly, .NET liked to do this in the beginning, some methods had the parameters like source, destination, others like destination, source). It makes programming either more error-prone, or much slower as the programmer has to read the manual every time he uses a function, because one can never be sure what parameters this function in this language in this version is using.
If ALL language designers could agree to change the C-style names for all future languages in exactly the same way, it might make some sense to do it. Good luck in achieving that!
Common roots and cultural heritage are not there without a reason.
As others have said, it's mainly because these are frequently just wrappers around the C calls. And there is a huge benefit in that being the case (including the short name), basically programmers new to the language know what to expect from it -- what arguments it takes, what side effects it might have, how error conditions are handled.
If I see:
printf ("Width trick: %*d \n", 5, 10)
I know that (a) this is a right justified, and (b) that it can take up to 5 spaces. If I see:
printf_formatted_string("Width trick: %*d \n", 5, 10)
I have no idea what it means, without looking it up.
The shorter C-style names also convey that although this language is not C; the language has a C heritage and this printf is our take on our venerable ancestors printf function adapted for our language.
C is very much a foundation language and new languages can gain a lot by stating that they are "C-style".
Similarly other languages may purposefully embed the Unix way of doing some tasks and reinforce that by adopting Unix names for doing similar (or identical) things. If you are familiar with the Unix chmod command and implement chmod-like functionality in your language with maybe a similar API, then it might be better to call it chmod in your language rather than change_mode or whatever. It means that you can re-use your Unix experience
Some people believe that what you may do often in a language should have a shorter name.
To do anything useful, all languages need to interact with operating systems but not all languages make calls to OS directly because there's no API defined for these languages. POSIX, for example, only defines API with binding to C and Ada.
A very important part of OS is the C library (libc), which implements the OS' API, at least after POSIX was defined. POSIX was basically defined based on existing libcs implementations.
If there's no language specific API for a language, then it has to use functions available in libc. It is up to the language designer then to either rename or reuse libc function names and export that as libraries.
I think languages that run on virtual machine (vm as in jvm) shouldn't have the same problem (if it's really a problem).
