<p>A language that I use (<a href="https://en.wikipedia.org/wiki/MUMPS" rel="nofollow noreferrer">M</a>) has this nifty feature that allows you to abbreviate most keywords to a single letter. For instance, the following code:</p>
<pre><code>myTag()
  new x
  for x=1:1:5 do
  . write !,x
</code></pre>
<p>is equivalent to this code:</p>
<pre><code>myTag()
  n x
  f x=1:1:5 d
  . w !,x
</code></pre>
<p>Most languages that I'm aware of this do not allow this. You have to spell &quot;if&quot; as &quot;if&quot; every time. What are the pros and cons of allowing users the choice of writing keywords &quot;the long way&quot; or abbreviating them?</p>

<syntax><keywords>
What are the pros and cons of allowing keywords to be abbreviated?
CC BY-SA 4.0
2023-07-04T01:34:07.340Z
Atari BASIC did something similar, but the abbreviations were an *editing* shortcut, and didn't affect the in-memory tokenized code format.  You could *type* `G.50`, but `LIST`ing the program expanded it to `GOTO 50`.
dan04
CC BY-SA 4.0
2023-07-04T09:47:55.540Z
Do you intend that your keywords are case-sensitive? Can an abbreviation be to any substring or only to the designated first or first few characters? I worked on a generalised SCPI parser a few months ago which resulted in a lot of "fun" caused by the standards apparent ignoring of some of the consequences of case/length issues.
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-04T18:41:10.977Z
Spectrum BASIC did it both ways: every keyword was (in the early versions at least) a keyboard key or chord, though you COULD type them out manually. However you entered them, each keyword was stored in a single byte in memory. Sort of like a simplified version of today's bytecode compilation.
Dewi Morgan
CC BY-SA 4.0
2023-07-05T14:12:14.477Z
In the time I type `n`, I can just as well type `new`. The same goes for `f`/`for`, `i`/`if`, etc. These short keywords are memorized patterns of keystrokes to my brain, and no more effort to type than any single letter/symbol. I think the word, and it appears right in front of my eyes. It is plain amazing how fast you can get at typing oft-repeated words, even when they are much longer. So, I'd say that anyone who feels the need for such abbreviations should consider some touch type training instead.
cmaster - reinstate monica
CC BY-SA 4.0
2023-07-07T23:16:50.177Z
In C, you could `#define i if` and `#define f for`.
CPlus
<p>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 <code>print</code>) may save a lot of time for the programmer.</p>
<p>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.</p>

CC BY-SA 4.0
2023-07-04T00:16:05.230Z
2023-07-04T00:16:05.230Z
Redz
CC BY-SA 4.0
2023-07-05T12:22:17.230Z
Given abbreviations are limited to keywords, they won't help with long variable names.
Matthieu M.
<p><strong>Pro: Code Golf</strong></p>
<p>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.</p>
<p><strong>Con: Readability</strong></p>
<p>Depending on how familiar you are with the language, it may not be obvious what each letter stands for.</p>
<p><strong>Con: Ambiguity</strong></p>
<p>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.</p>

CC BY-SA 4.0
2023-07-04T00:12:29.050Z
2023-07-04T00:12:29.050Z
Bbrk24
CC BY-SA 4.0
2023-07-04T09:04:16.297Z
The ambiguity point is huge from a diachronic perspective--even if you get all the keywords lined up nice for abbreviations in the first version, what if you want to add more? And then, what happens to old abbreviated code?
Unrelated String
CC BY-SA 4.0
2023-07-04T10:54:52.567Z
Another way that abbreviations reduce readability: the more ways there are to express a construct, the more effort it takes to read. (When every loop looks the same, you can recognise it at a glance; but when every loop looks different, the more time and brainpower it takes to identify.)
gidds
CC BY-SA 4.0
2023-07-04T14:48:51.190Z
@UnrelatedString In part that can be handled by limiting abbreviations. (For example, you can abbreviate "while" down to "w", but require that "wait" be at least "wa".) Or contextual clues (e.g. "while" is attached to a sub-block, while "wait" is not). -- Of course, this is just a different type of ambiguity, pushed onto the programmer & reader.
R.M.
<p>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 <code>for </code> as <code>f </code>, and substitute <code>f </code> with <code>for </code> when entered.</p>

CC BY-SA 4.0
2023-07-04T09:37:34.703Z
2023-07-04T09:37:34.703Z
Philipp
CC BY-SA 4.0
2023-07-05T13:43:55.903Z
This is in fact one advantage of projectional editing.
Polygnome
<p><strong>How do you differentiate identifiers from keywords?</strong></p>
<p>This can be a con, depending on how you have your language. Consider an if-expression:</p>
<pre class="lang-py prettyprint-override"><code>x=if cond do
   foo()
else
   bar()
fi
</code></pre>
<p>How will you differentiate a variable called <code>i</code> and an if expression?</p>
<pre class="lang-py prettyprint-override"><code>x=i cond d foo(); e bar(); fi
</code></pre>

CC BY-SA 4.0
2023-07-04T02:01:12.907Z
2023-07-04T02:01:12.907Z
bigyihsuan
CC BY-SA 4.0
2023-07-04T02:08:52.283Z
+1. Specifically, the parser doesn't know whether `i` is a keyword or an identifier until it looks further ahead. Essentially, it makes most of the language's keywords into [contextual keywords](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/#contextual-keywords), except that parsers for most languages with contextual keywords can determine keywordness from already-known context, without requiring lookahead in the parser.
kaya3
CC BY-SA 4.0
2023-07-05T12:20:18.353Z
@kaya3-supportthestrike: Does it, though? I mean, the obvious "fix" is to treat any prefix of a keyword as a keyword, immediately forbidding variables of that spelling. Not sure I'd want to code in such a language, but the parser would remain straightforward.
Matthieu M.
<p>Furcadia's DragonSpeak (aka &quot;DS&quot;: <a href="https://cms.furcadia.com/creations/dreammaking/dragonspeak/dragonspeak-reference#parser" rel="nofollow noreferrer">https://cms.furcadia.com/creations/dreammaking/dragonspeak/dragonspeak-reference#parser</a>) 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.</p>
<p>DS lines look like:</p>
<pre><code># 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.
</code></pre>
<p>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.</p>
<p>But this can become very verbose to read.</p>
<p>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 &quot;WhenSomeoneTurns&quot; might have the abbreviated form &quot;Wst&quot;, so in DS, you can abbreviate the command &quot;(0:4) When someone turns,&quot; down to just &quot;(0:4)&quot;.</p>
<p>So if you have written a block, and now want a large number of similar blocks, you can do something like:</p>
<pre><code># 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!}
</code></pre>
<p>The variations need only a word or so to call out differences between them and the fully-annotated block.</p>
<p>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.</p>
<p>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)</p>
<p>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 (<a href="http://forums.furcadia.com/200" rel="nofollow noreferrer">http://forums.furcadia.com/200</a>) was 1169 commands, but was reduced down to 334 lines (273 of code, plus whitespace and comments).</p>
<p>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.</p>
<p>It should be immediately obvious that there many MUCH BETTER WAYS to reduce this repetition in any normal programming language. Methods, functions, loops, etc.</p>
<p>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.</p>
<p>Other than deliberate code golfing, the only exception I can think of where such brevity is useful is the <em>very</em> 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.</p>

CC BY-SA 4.0
2023-07-04T20:00:12.217Z
2023-07-04T21:38:07.190Z
2023-07-04T21:38:07.190Z
Dewi Morgan
CC BY-SA 4.0
2023-07-04T20:30:09.783Z
I'm trying to understand this language as much as I can from the link you provided, apologies if I'm getting something wrong. Are you saying that you can omit "and they are" and such, because the parser will understand the instructions without them? If so, then I wouldn't agree it's at all similar to what the OP is describing, those structures in Dragonspeak act more like optional comments, not keywords.
Reverent Lapwing
CC BY-SA 4.0
2023-07-04T20:42:27.427Z
@ReverentLapwing Yes, all text is merely syntactic sugar for humans, ignored by the parser. Only the numbers (and in later versions of the language which supported them {strings in curlies} and @variables) are parsed. The rest can be removed to reduce the pain of repetition. In a similar way, a language could allow most text of keywords to be collapsed for brevity, but that only helps if variable and method names are similarly terse. So I'm very far from convinced it'd be an advantage in non-golfing languages with loops, variables, classes, etc.
Dewi Morgan
<p>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.</p>
<p>For instance, in this language, it's &quot;idiomatic&quot; to write loops that traverse an array in the following manner:</p>
<pre><code>  f  s index=$O(myArray(index)) q:index=&quot;&quot; d
  . ; Insert body of loop
</code></pre>
<p>Compare this with the version with the keywords written out:</p>
<pre><code>  for  set index=$ORDER(myArray(index)) quit:index=&quot;&quot; do
  . ; Insert body of loop
</code></pre>
<p>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 &quot;done&quot; variable or similar to do, so it's nicer to do it on one line.</p>
<p>Now, some of you may be thinking, &quot;Isn't it harder to read the one-letter version?&quot; 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.</p>

CC BY-SA 4.0
2023-07-04T00:31:17.563Z
2023-07-04T00:31:17.563Z
Isaiah
CC BY-SA 4.0
2023-07-04T17:05:01.677Z
Tastes vary, but to me both versions are horrible. Why would a `for` construct need _four_ separate keywords in the first place? That's excessive and of very dubious merit. The only reason why such a high keyword density could be benefitial is to ease readability to people unfamiliar with the language, but that goes completely out of the window if you then shorten them away.
leftaroundabout
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-07-04T19:22:31.623Z
2023-07-04T19:22:31.623Z
Reverent Lapwing
<p>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.</p>
<p>But, this comes at a steep penalty to <em>readability</em>.</p>
<p>There is an old adage for programmers, which is &quot;Code is more often read than written&quot; (<a href="https://devblogs.microsoft.com/oldnewthing/20070406-00/?p=27343" rel="noreferrer">attributed sometimes to Raymond Chen</a> or Guido van Rossum, inventor of Python).</p>
<p>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.</p>
<p>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.</p>
<p>Developers spend most time thinking about the code and finding solutions. The time to actually <em>type</em> the program is only small fraction of the work that goes into developing it.</p>
<p>But code is quite often <em>read</em> 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.</p>
<p>That is why most languages focus on <em>readability</em>. 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.</p>
<p>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.</p>

CC BY-SA 4.0
2023-07-04T14:55:14.470Z
2023-07-04T14:55:14.470Z
Polygnome
# What are the pros and cons of allowing keywords to be abbreviated?
Posted by: username_0 on 2023-07-04
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?
**Tags:** syntax keywords
> **Comments:**
> **username_1**: Atari BASIC did something similar, but the abbreviations were an *editing* shortcut, and didn't affect the in-memory tokenized code format.  You could *type* `G.50`, but `LIST`ing the program expanded it to `GOTO 50`.  
> **username_2**: Do you intend that your keywords are case-sensitive? Can an abbreviation be to any substring or only to the designated first or first few characters? I worked on a generalised SCPI parser a few months ago which resulted in a lot of "fun" caused by the standards apparent ignoring of some of the consequences of case/length issues.  
> **username_3**: Spectrum BASIC did it both ways: every keyword was (in the early versions at least) a keyboard key or chord, though you COULD type them out manually. However you entered them, each keyword was stored in a single byte in memory. Sort of like a simplified version of today's bytecode compilation.  
> **username_4**: In the time I type `n`, I can just as well type `new`. The same goes for `f`/`for`, `i`/`if`, etc. These short keywords are memorized patterns of keystrokes to my brain, and no more effort to type than any single letter/symbol. I think the word, and it appears right in front of my eyes. It is plain amazing how fast you can get at typing oft-repeated words, even when they are much longer. So, I'd say that anyone who feels the need for such abbreviations should consider some touch type training instead.  
> **username_5**: In C, you could `#define i if` and `#define f for`.  
---
## 8 answers
### Answer by username_8 on 2023-07-04. Score: 23 | Accepted answer
**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.
> **Comments:**
> **username_9** (2023-07-04): The ambiguity point is huge from a diachronic perspective--even if you get all the keywords lined up nice for abbreviations in the first version, what if you want to add more? And then, what happens to old abbreviated code?  
> **username_10** (2023-07-04): Another way that abbreviations reduce readability: the more ways there are to express a construct, the more effort it takes to read. (When every loop looks the same, you can recognise it at a glance; but when every loop looks different, the more time and brainpower it takes to identify.)  
> **username_11** (2023-07-04): @UnrelatedString In part that can be handled by limiting abbreviations. (For example, you can abbreviate "while" down to "w", but require that "wait" be at least "wa".) Or contextual clues (e.g. "while" is attached to a sub-block, while "wait" is not). -- Of course, this is just a different type of ambiguity, pushed onto the programmer & reader.  
---
### Answer by username_12 on 2023-07-04. Score: 18
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.
> **Comments:**
> **username_13** (2023-07-05): This is in fact one advantage of projectional editing.  
---
### Answer by username_14 on 2023-07-04. Score: 15
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
> **Comments:**
> **username_15** (2023-07-04): +1. Specifically, the parser doesn't know whether `i` is a keyword or an identifier until it looks further ahead. Essentially, it makes most of the language's keywords into [contextual keywords](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/#contextual-keywords), except that parsers for most languages with contextual keywords can determine keywordness from already-known context, without requiring lookahead in the parser.  
> **username_7** (2023-07-05): @kaya3-supportthestrike: Does it, though? I mean, the obvious "fix" is to treat any prefix of a keyword as a keyword, immediately forbidding variables of that spelling. Not sure I'd want to code in such a language, but the parser would remain straightforward.  
---
### Answer by username_16 on 2023-07-04. Score: 8
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 by username_13 on 2023-07-04. Score: 7
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](https://devblogs.microsoft.com/oldnewthing/20070406-00/?p=27343) 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 by username_3 on 2023-07-04. Score: 4
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.
> **Comments:**
> **username_16** (2023-07-04): I'm trying to understand this language as much as I can from the link you provided, apologies if I'm getting something wrong. Are you saying that you can omit "and they are" and such, because the parser will understand the instructions without them? If so, then I wouldn't agree it's at all similar to what the OP is describing, those structures in Dragonspeak act more like optional comments, not keywords.  
> **username_3** (2023-07-04): @ReverentLapwing Yes, all text is merely syntactic sugar for humans, ignored by the parser. Only the numbers (and in later versions of the language which supported them {strings in curlies} and @variables) are parsed. The rest can be removed to reduce the pain of repetition. In a similar way, a language could allow most text of keywords to be collapsed for brevity, but that only helps if variable and method names are similarly terse. So I'm very far from convinced it'd be an advantage in non-golfing languages with loops, variables, classes, etc.  
---
### Answer by username_0 on 2023-07-04. Score: 4
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.
> **Comments:**
> **username_17** (2023-07-04): Tastes vary, but to me both versions are horrible. Why would a `for` construct need _four_ separate keywords in the first place? That's excessive and of very dubious merit. The only reason why such a high keyword density could be benefitial is to ease readability to people unfamiliar with the language, but that goes completely out of the window if you then shorten them away.  
---
### Answer by username_6 on 2023-07-04. Score: 3
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.
> **Comments:**
> **username_7** (2023-07-05): Given abbreviations are limited to keywords, they won't help with long variable names.  
---
