33

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.

bigblind
  • 1,415
  • 1
  • 13
  • 17
  • 1
    tradition and the people designing the APIs are used to the shorter names so don't think to use anything else – ratchet freak Jul 23 '13 at 21:27
  • 20
    Specifically for Python's os module (since you mentioned Python and mkdir), the functions use the same short, cryptic names as C because they are little more than wrappers around the C functions, so it make sense to name them the same way. The function name reminds you that the function isn't doing much more than calling the low level C library functions. – Dan Albert Jul 23 '13 at 23:21
  • 10
    Because they were computer experts for the most part, and they didnt see any advantage to naming it something other than what the *nix command they had been using for 20 years was called? I really hate questions like this. You might have a point for something like Go, but Python is ancient in comparison (older than Java, C#, Go, Dart, Javascript...) – GrandmasterB Jul 24 '13 at 04:03
  • 7
    Its actually a FORTRAN style printf() – James Anderson Jul 24 '13 at 06:23
  • Old habits die hard – BlueRaja - Danny Pflughoeft Jul 24 '13 at 07:58
  • 1
    It's a skeuomorph, like the "save" icon is a floppy disk. – Gaius Jul 24 '13 at 08:05
  • 5
    Python is not modern BTW, it was created 22 years ago. – Den Jul 24 '13 at 08:36
  • 8
    Just switch to a language that has annoyingly long method names. I'd become violent if I had to use print_format instead of "printf". The underscore is especially annoying. Then again, I'm easily annoyed. :D – MetalMikester Jul 24 '13 at 17:13
  • Well, there's a difference between readability and verbosity. – bigblind Jul 24 '13 at 18:31
  • @Den: Do you define modern by the age or by the relevance in the present industry? – Giorgio Jul 24 '13 at 19:33
  • @Giorgio: Neither would make Python particularly stand out in comparison with C. – Den Jul 24 '13 at 21:08
  • 2
    make_directory does not carry any more information to the reader than what mkdir alerady does. Instead, it carries excess weight(as in, information/meaning per character is lower) and is easily confused with other similar words, because it is composed of two common words unlike mkdir which itself has very little chance of being confused with similar words, as such words don't exist. And of course some of us(myself included) simply prefer "unique" names for common entities in the context we operate, it is jargon and makes it easy to communicate with people who are familiar with it. – zxcdw Jul 25 '13 at 05:01
  • 3
    One more issue: those names became parts of the common "language" of programmers a long time ago. And just because a new language becomes dominant, or some linguistic constructs become dated, that doesn't mean they disappear overnight - or at all. – mikołak Jul 25 '13 at 06:47
  • I don't think this is a duplicate. Instead of wondering whether they're bad practice, this question assumes writing them is bad practice, and wonders why they are still used. – bigblind Sep 17 '15 at 15:18

9 Answers9

48

But why do modern languages like python and go still use the less readable names from the C apis?

  1. 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.

  2. 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.

Telastyn
  • 109,398
  • 7
    Not that flimsy when you consider how quickly a proficient programmer picks up a new dialect (after all, most common languages are just a dialect of LISP or C) with the aid of good documentation (and google). Compare this to domain terminology and TLA's that invade all software, and often poor choice of variable names and poor documentation..... The problem of short names like printf is so far down the list...... – mattnz Jul 23 '13 at 23:11
  • 3
    Are you implying that liking long method names negatively correlates with programming skill? – congusbongus Jul 24 '13 at 05:35
  • 1
    I understand that this problem is quite far down the list, although functions with written out names are self documenting. – bigblind Jul 24 '13 at 09:06
  • 2
    @congusbongus - not in general, though in certain domains (systems programming, shell scripting) the correlation tends to hold, since the use of IDEs is non-existent there. – Telastyn Jul 24 '13 at 11:27
  • Of course, good old Cobol is the singular wordy exception (not that Cobol is often seen these days). – Paddy Landau Jul 24 '13 at 15:01
  • 7
    #1 isn't flimsy because many of the short names are enshrined in POSIX, a well-known, well-supported standard. If you're going to mimic the standard's behavior or simply call your system's compliant function by the same name, why not name yours the same way? That also cuts your documentation down to "Implements POSIX mkdir()." – Blrfl Jul 24 '13 at 17:16
  • Some languages can't often be relied on to provide type-dependent autocomplete even in an intelligent IDE (mainly, I'm thinking of Javascript), so in that case I would much rather have shorter methodNames to type out. In C# I'm fine with 'CreateFileAndDirectory'. – Katana314 Jul 24 '13 at 19:50
  • 2
    "Because it's always been done that way" is not such a flimsy argument if you put a lot of effort into learning the "standard" names, only to have someone come along and change all of them just because they think the new ones are prettier. – Robert Harvey Jul 25 '13 at 04:52
  • +1 because your arguments are good, but I completely disagree with your assessment that they are flimsy arguments. I think they are both strong. – Ben Lee Jul 29 '13 at 20:44
  • 1
    If a method uses the same name as a system utility method, it will generally be expected to have the same behaviors and quirks of that method. Use of the existing name is good when the behaviors in fact match; use of a different name is better when the behaviors don't. – supercat Mar 27 '14 at 21:46
44

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.

rszalski
  • 147
  • 9
James Anderson
  • 18,147
  • 1
  • 43
  • 72
  • 9
    I don't think it's a good analogy. With given names, no one cares about the meaning behind the name because it has nothing to do with the actual person. With the method names it's quite the opposite: the closer the function name is tied to what it does, the better. It's not just a label. – Malcolm Jul 24 '13 at 22:18
  • 2
    The point is "Albert" means the guy with freckles who doesn't pay for his beers. The name has been assigned a meaning -- not the other way around! – James Anderson Jul 25 '13 at 02:12
  • 3
    Yes, it works that way with given names. They are given randomly at birth when no one has even a slightest idea what the person is going to be like. You aren't saying that programmers usually pick a random name for the function, and then make it do something, are you? Even if some do, that's obviously a very poor programming style. – Malcolm Jul 25 '13 at 08:51
  • 1
    I'd name my son "Shining Hero". – JesseTG Jul 25 '13 at 20:18
  • 5
    Why stop at print_format when you could do print_using_values_substituted_from_arguments? And how long before someone gets aggravated typing all of that out and shortens it to puvsfa? – Blrfl Jul 26 '13 at 11:59
  • I don't think the analogy is far off. Function names are not given randomly, true, but they are not made fully descriptive either, sort of like referring to a guy you and a friend saw once as "hat guy". And the name printf is much more like a given name than it is like a description. – Owen Jul 29 '13 at 04:02
  • 1
    "a print function with a template that will use %2d" -- don't be ridiculous. Everyone knows that printf is for %0.2f. I mean, seriously :P. (Also, +1) – Ben Lee Jul 29 '13 at 20:50
20

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".

kevin cline
  • 33,670
  • 1
    I see the point, but it seams like a long vs short term benefit. If a language changes those names, generations of programmers to come won't have to overcome those hurdles – bigblind Jul 23 '13 at 22:30
  • 6
    True, but if you want adoption of your language you must cater to current programmers, not future programmers. ;-) – sergut Jul 23 '13 at 23:45
  • 8
    Languages such as C# had opted for the more readable forms of well-known OS method names in their API. Directory.CreateDirectory – rwong Jul 24 '13 at 02:44
  • 2
    @bigblind You're a novice once per language, and experienced for as long as you continue using it after that. So which is long term and which is short? – Useless Jul 24 '13 at 08:15
  • I mean long term in the sense that you make the learning experience easier for generations to come, which is much longer than the span of any programmer's career. – bigblind Jul 24 '13 at 08:37
  • For what it's worth, if I had a dollar for every time I typed car instead of cdr or cdr instead of car, I could have retired before I graduated uni. – corsiKa Jul 24 '13 at 14:43
  • 2
    Rather than pitching it as "long vs short term", I'd say it's a library designer's dare (willpower) to innovate (breaking existing customs). Both choices have pros and cons. – rwong Jul 25 '13 at 03:11
  • first and rest are often used instead of car and cdr, but not enough to invalidate your argument. – Mark Hurd Jul 31 '13 at 03:23
15

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_line it will take far longer than printf, 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.

Alok
  • 498
  • 3
  • 10
11

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.

Ingo
  • 3,921
  • 1
    +1 When skimming, people look at the first and last letters of a word, plus the length. – Vorac Aug 08 '13 at 14:30
  • 1
    @Vorac - Actually, when reading novels translated from Russian, where people often have long names that all end in "-ski", I am often confused. Because my brain constructs a most general pattern (or so it seems) to detect those letter clusters that do not make any sense in my language (German). Hence it may happen that "Domedojewski" and "Dokadojurski" are taken for the same person, until suddenly I ask myself: Wait, didn't this Do.*ski pass away two chapters before? How can he appear now again? Chinese novels, OTOH, are easier, because people there have names like Wong, Hang or Lao. – Ingo Aug 08 '13 at 17:20
8

Mandatory xkcd reference:

how standards proliferate

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.

vsz
  • 1,496
  • 9
  • 17
5

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.

jmoreno
  • 10,853
  • 1
  • 31
  • 48
4

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.

Paddy3118
  • 617
1

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).

imel96
  • 3,518
  • 1
  • 19
  • 28