What are the pros and cons of allowing keywords to be abbreviated?

Question

A language that I use (M) has this nifty feature that allows you to abbreviate most keywords to a single letter. For instance, the following code:

myTag()
  new x
  for x=1:1:5 do
  . write !,x

is equivalent to this code:

myTag()
  n x
  f x=1:1:5 d
  . w !,x

Most languages that I'm aware of this do not allow this. You have to spell "if" as "if" every time. What are the pros and cons of allowing users the choice of writing keywords "the long way" or abbreviating them?

Answer 1

Pro: Code Golf

Most modern golfing languages have their common tokens as a single byte, if that. This is a very niche use case, but a use case nonetheless.

Con: Readability

Depending on how familiar you are with the language, it may not be obvious what each letter stands for.

Con: Ambiguity

From the perspective of the language designer, you have to be careful that each keyword starts with a distinct letter, or else these abbreviations could be ambiguous.

Answer 2

You don't need to explicitly allow this, because it is a feature that could easily be implemented on the level of the development environment if it is desired. Programmers could configure their editor to automatically display for as f , and substitute f with for when entered.

Answer 3

How do you differentiate identifiers from keywords?

This can be a con, depending on how you have your language. Consider an if-expression:

x=if cond do
   foo()
else
   bar()
fi

How will you differentiate a variable called i and an if expression?

x=i cond d foo(); e bar(); fi

Answer 4

I'll disagree with all the positive comments and say that there is no serious benefit at all. Your line of code might be 6 characters shorter and far less readable. If you are using descriptive variable names (like you should), you will sacrifice maybe 60 characters in a line to fit 3 variables. Character count in a line is not a big issue ever since monitors replaced terminals and as the screens became bigger, it became even less of an issue.

Linux kernel developers would sacrifice 8 characters just for the indentation to discourage nesting - that is more space wasted than you save in the for statement you gave as an example. When you need to sacrifice either readability or 80 character width limit, I don't see a situation in which you would ever choose to sacrifice readability.

Answer 5

Programming languages are optimized for their specific use case. There are a few programming languages that try to be as dense as possible. These are mainly languages intended for code golf, where length comes as a premium and it is of utmost importance to actually save every last bite.

But, this comes at a steep penalty to readability.

There is an old adage for programmers, which is "Code is more often read than written" (attributed sometimes to Raymond Chen or Guido van Rossum, inventor of Python).

It doesn't really matter for the compiler if the keywords are short or not. Typical code-bases do not grow so large that it makes an appreciable difference. Assets (images, audio, video etc.) will typically exceed the size of the code-base by many, many magnitudes. And once interpreted or compiled, it doesn't matter anymore, anyways.

So for the execution of the program, it does not matter. What matters is when humans interact with the text. But programs are not written linearly, and usually done supported with an IDE which will offer code completion anyways.

Developers spend most time thinking about the code and finding solutions. The time to actually type the program is only small fraction of the work that goes into developing it.

But code is quite often read to gain understanding. Old parts of the codebase, code examples in tutorials, code written a few days ago, code written years ago. We read code all the time.

That is why most languages focus on readability. Because that is what we mostly do with the code as humans, what we spent the most time doing, and what needs to be as easy as possible for most mainstream, general purpose languages.

Unless you are in a niche field like a golfing language, optimizing for readability will be a core concern. And readable keywords, not cryptic one-letter combinations, are a big part of that.

Answer 6

As someone who uses a language like this almost every day and where the norm is to use single letters for keywords, one of the pros is that it really helps with line length. While 1-3 characters may not seem like a lot, it does add up, and in a language where you can't extend lines to the next line, it really helps with cutting out noise.

For instance, in this language, it's "idiomatic" to write loops that traverse an array in the following manner:

  f  s index=$O(myArray(index)) q:index="" d
  . ; Insert body of loop

Compare this with the version with the keywords written out:

  for  set index=$ORDER(myArray(index)) quit:index="" do
  . ; Insert body of loop

Some loops might have more complicated ending conditions, and while it's sometimes feasible to move it inside the loop body, it generally requires an extra "done" variable or similar to do, so it's nicer to do it on one line.

Now, some of you may be thinking, "Isn't it harder to read the one-letter version?" It is, but only when you are first learning the language. Over time, you get used to the one-letter version until it becomes as natural as the other version. In fact, I can read the one-letter variant more easily than the version with the long form keywords.

Answer 7

Furcadia's DragonSpeak (aka "DS": https://cms.furcadia.com/creations/dreammaking/dragonspeak/dragonspeak-reference#parser) was one fun language I've used where something similar was used by advanced coders. Not exactly the same, but the principle of brevity holds, and it shows some possible advantages.

DS lines look like:

# Dance pole crowd responses.
(0:4) When someone turns,
 (1:36) and they are male,
 (1:29) and they are a Squirrel,
      (5:200) emit message {Show us your nuts!} to the triggering furre.

Each line is added with a click in the editor, rather than by writing a keyword, and lines are stacked to create complex if/where/and/or clauses and their effects.

But this can become very verbose to read.

And in fact (as the link above says) you can modify the text of the commands: all that matters to the parser for any line is the numbers, and any strings in {curlies}. So just as in a language where commands are single keywords, the command "WhenSomeoneTurns" might have the abbreviated form "Wst", so in DS, you can abbreviate the command "(0:4) When someone turns," down to just "(0:4)".

So if you have written a block, and now want a large number of similar blocks, you can do something like:

# Dance pole crowd responses to male scuirine dancer.
(0:4) When someone turns,
 (1:19) and they are standing at position (68,70)
 (1:36) and they are male,
 (1:29) and they are a Squirrel,
      (5:200) emit message {Show us your nuts!} to the triggering furre.

# Variations (abbreviated versions of the above)
(0:4)(1:19)68,70(1:37)Female(1:29)Squirl(5:200){Show us that tail!}
(0:4)(1:19)68,70(1:38)Unspec(1:29)Squirl(5:200){Work it, squirl!}
(0:4)(1:19)68,70(1:36)Male  (1:23)Canine(5:200){Go, hound dawg!}
(0:4)(1:19)68,70(1:37)Female(1:24)Canine(5:200){Shake it, biyatch!}
(0:4)(1:19)68,70(1:38)Unspec(1:23)Canine(5:200){Wag that tail!}
(0:4)(1:19)68,70      Any   (1:26)Dragon(5:200){Flame out!}

The variations need only a word or so to call out differences between them and the fully-annotated block.

Because the blocks are now written as oneliners, adjacent and aligned, we can see at a glance how they differ. It's clear even to someone unfamiliar with the language that they all relate to the same coordinate (68,70: likely containing the dance pole), and that this is a list of lines displaying text depending on the gender and species of the pole's dancer.

By allowing this adjacent alignment, the abbreviation makes the code easier to read, and typos easier to spot. The above code has one typo, which you MIGHT have spotted because of this arrangement, but would have been essentially invisible to even experienced DS coders with the code expanded. (Spoiler, reversed: rebmun seiceps s'eninac dnoces ehT)

In code with several thousand lines this can also make a huge difference to sharability. In fact, the first DS code I shared in a forum post, using an early and limited version of DS (http://forums.furcadia.com/200) was 1169 commands, but was reduced down to 334 lines (273 of code, plus whitespace and comments).

Something similar could be done with a language that permits single-character commands. The downside is that variable names would then also have to be short.

It should be immediately obvious that there many MUCH BETTER WAYS to reduce this repetition in any normal programming language. Methods, functions, loops, etc.

Encouraging brevity just so that people can have easily-debugged code repetition feels to me like an antipattern: it encourages the type of repetition I show above, AND it discourages readable-length variable names because they would harm the brevity.

Other than deliberate code golfing, the only exception I can think of where such brevity is useful is the very specific case of a programming language like DS, which deliberately avoids any form of looping to avoid the possibility of shooting oneself in the foot with infinite loops.

Answer 8

One pro is that it saves space, which is helpful for code-golfers and may help with readability in the case of long variable names (think resulting-weather-data-analysis-dataframe) or long lines of code. In these cases, having abbreviations for well-known operations (such as print) may save a lot of time for the programmer.

However, there are a few cons to this approach. There aren't an infinite number of letters in the alphabet, so ambiguity will be a problem with abbreviations - it may be hard to choose unique identifiers. In addition, new users may not understand what the letters stand for or have knowledge of the common abbreviations for operations.