# Nominations for Language of the Month, 2021 edition

We've decided to revive the Language of the Month event. We've also decided to start a new post for nominations. (You can see the old nominations post here.) So let's get to nominating!

## Procedure

A language can be nominated for Language of the Month by posting an answer to this thread. We all vote on the languages we'd like to see featured. At the beginning of each month, the nomination with the highest net vote total is chosen as the Language of the Month. (This nomination process was modeled after Lit.SE's reading challenges.)

The person who nominated the language will post a new question on meta, declaring that language to be Language of the Month, with an answer to collect all related golf submissions, tips, and challenges during the month. (See the previous posts, linked below, for a good format to follow.)

• If the person who nominated the language is not able to make the post by the 3rd of the month, anyone else can make the post.
• If there is a tie in the voting, the tied language that was nominated earlier will be Language of the Month.

The chosen language will have a chatroom created for it, if it doesn't already have one. During the month, everyone who wants to participate will:

• Learn the basics of the language (if they don't know it already)
• Answer challenges in it (new ones or old ones, doesn't matter)
• Try to outgolf each other's answers
• Discuss all of the above in the language's chatroom

Past Languages of the Month will be added to a list at the bottom of this post. Their nomination posts should be deleted (preferably by the person who made the post) to reduce clutter.

## What sort of languages should I nominate?

We hope to see a wide variety! But not every language is a good choice for Language of the Month. Some things to consider before nominating, and when voting on nominations:

• It should be somewhat general-purpose and possible to program in. Bubblegum isn't a good choice, because it's only capable of solving a small subset of challenges. Neither is Malbolge a good choice, because it's prohibitively hard to create a working program in it at all.
• It should not be one of our most commonly used languages on PPCG. The point of this event is to bring attention to lesser-known languages. We don't need to bring more attention to Python or JavaScript. Suggested rule of thumb: if there are fewer than 10 PPCG users who regularly golf in this language, it's a good nomination.*
• It should have a freely available implementation. This can be TIO, some other online source, or a downloadable interpreter/compiler.
• It should be fairly stable. Most languages change over time, even well-established ones, so this is a subjective criterion. But if a language is likely to experience significant modifications in the next month, don't nominate it yet.
• It can be either esoteric or practical. Of course we like our esolangs around here, but it's also cool to study lesser-known "real" languages.

* Better rules of thumb are welcome. Here are a couple SEDE queries for estimating how commonly a language is used: a strict version (useful for languages with short names that could show up as false positives within other languages' names or URLs) and and a loose version (useful for languages whose headers frequently mention a flavor or version number with the name).

## What should I include in a nomination post?

At a minimum, your nomination must include:

• The language's name.
• A link to a free implementation (or more than one, if available).
• A short description of the language, for those unfamiliar with it.
• Why you think this would make a good Language of the Month.

Ideally, your nomination should also include:

• Some links to documentation and other good resources for learning the language.
• A link to the language's question, if it has one.

You can also include ideas for one or more language-specific challenges that will provide an interesting experience beyond answering regular challenges in this language. These can be , , , ... you name it. Good language-specific challenges will focus on some aspect of the language that makes it unique, such as an ability or a weakness that most other languages don't have.

Feel free to re-nominate a language that was nominated last time but never won. You can copy over the old nomination post if you like. Languages that have previously been Language of the Month are not eligible.

## List of past and current Languages of the Month

### 2021

Don't forget to keep nominating and voting on languages for next month!

• By the way, the top few languages have been downvoted, so make sure you look at the upvotes. – user Dec 1 '20 at 17:41
• Now that it's Dec 2020, should it be renamed to 2020+ edition? Or will there be a new one for 2021? – val is still with Monica Dec 4 '20 at 17:55

# Red

Red is a next-gen language, strongly inspired by REBOL.

## Why Red?

• Red is meant to be a full-stack language. This means it includes a high-level dialect (dynamic, interpreted, but can be also compiled) and Red/system, a low level dialect for perfomance when necessary (always compiled).
• Red ephasizes the paradigm "Code is data". Red doesn't have reserved words, instead blocks (arrays / lists of arbitrary values) are used as arguments to functions.
• Red is language-oriented and includes several DSLs, including a gui description language (VID and View), 2d drawing dialect (Draw) and a parsing dialect (Parse).
• Red has a rich set of built-in datatypes - over 50.

## Caveats

• Red is still under development. Rebol is pretty stable, so you can try that out too.
• Red's syntax is very readable, but not made for golfing. I think it will do well compared with other general-purpose languages, because it's like lisp, but with many parentheses removed or replaced with brackets[], and a good amount of builtins.

# Plumber

Plumber is an esolang I made, based upon packets moving around in a 2d space. This space consists of a grid of 2-character wide units, of which there are 16.

It has no stack, queue, or tape. Information is only stored and moved by pushing, pulling, and dropping these packets between parts of the program.

## Reasons

• There are only four answers in it
• People I talked about it with in TNB seemed to like it
• It's very different to use compared to most other 2d languages:
• There is no instruction pointer or stack
• Rather than a linear order of operations, you can have multiple parts of an operation running next to each other to save time or space
• It can be really fun to get a Plumber program working
• The many ways to use each unit makes interesting golfing much more possible than in some of the more straightforward languages

## ARM

ARM is probably the most successful architecture for the digital world. From mobile phones to supercomputers, ARM is everywhere!

As of 2013 more than 10 billion ARMs were shipped, as compared to 0.3 billion 80x86s. -- ISSBF

## Reasons

• ARM has a much better design than e.g. x86. It involves a lot less concepts, making it more beginner-friendly.
• ARM has a very low learning curve. Due to its RISC nature, ARM has less than 100 highly generalized assembler directives that perform tasks in a very compact way.
• To some extent, it makes ARM easier to learn than its competitors.
• The RISC architecture also makes programs faster to execute, since it takes less time on decoding the instruction opcodes.
• The ARM instruction set is very compact.
• Most instructions allow for conditional execution. This saves instruction cycles since no conditional jumps are necessary around conditional blocks.
• ARM also has the barrel shifter (which means that you can perform bitshifts to some value before using it).

The following shows an example:

ARM (8 Bytes)

cmp   r0,r1


x86 (11 Bytes)

cmp eax,ebx
jna skip
mov eax,edx
shr eax,4
skip:


• ARM has a much better design than e.g. x86: this is probably opinion-based. Also, ARM is not a language; the proposal seems to refer to ARM assembly – Luis Mendo Nov 15 '20 at 16:46

## jq

jq is a lightweight practical language for querying JSON files. It's like sed for JSON files.

## Reasons

• Streams in jq can be very powerful. Operators see individual items in strings when applied:
range(4) -> 0, 1, 2, 3
range(4) + 2 -> 1, 2, 3, 4

# Sometimes, a cartesian-product-like output can be produced with

range(2) + range(4) -> 0,1, 1,2, 2,3, 3,4

• Piping - Outputs of the previous expression can be piped.
3 | .+2  #  -> 5

[3, 4, 5] | max   # -> 5

• Compact syntax
[1, 2, 3] | map( . + 1 ) # -> [2, 3, 4]

# (This could also be achieved as [1, 2, 3][]|.+1)

• It has grown out of interest of the Code Golf community.

# Arn

Arn is a rather new J-like language I designed back in mid-August (2020). It's designed to beat out its inspiration and also be competitive against other, older golfing languages.

## Reasons

• it does well at what’s it meant to, consistently beating J and APL. I’ve also seen it do better than languages such as Vyxal.
• The tutorial has been finished, making it easy to start.
• Done with a major rewrite. TLDR new features, adding new ones easier
• Has entered a semi stable state. I have a feeling a few larger changes are due in the future, but for now I’ll probably just be adding a few new symbols every once in a while.
• There are very few (if any, other than me) people who use this language (as far as I'm aware) so this will help spread the language around.

## Caveats

• Does not currently have a chatroom, as I don't believe there are enough people to warrant one.
• The online version is out of date and has some bugs.
• I believe there’s a bug in the lexer that shows when using symbols that take multiple expressions on the same side, which I’m looking into.

## Resources

Add++ is a language that combines both short commands and other golfing features with general usability and practical language features. For example, I've written a programming language in Add++, and most solutions in Add++ are easy to understand for users of both practical and golfing languages.

## Reasons

• There aren't many languages like it. In my experience on the site, I don't recall seeing any languages with a similar model to Add++
• It is widely usable. I would describe Add++ as a practical language with one- or two-byte commands, so it's easily accessible to all golfers
• It's somewhat used across the site. Primarily by me, but there are multiple answers by other users, and we already have a chatroom
• Due to it's wide range of builtins, it is very powerful, and so can complete most challenges competitively with other golfing languages.
• Closer to Pyth and CJam rather than Jelly and 05AB1E however
• It has version tracking, and each version can be run via command-line flags
• It's docs are fairly comprehensive, thanks to Razetime

## Caveats

The docs do not contain a comprehensive list of commands, and it is somewhat strict in its syntax, which can lead to a lot of errors. Furthermore, Add++ still has some bugs in the code, along with some confusing behaviours.

I'm currently writing the latest version (v6) in order to someone mitigate the biggest problems I have with Add++

## Resources

• I think MUMPS is a much better candidate than this - syntax shorthands, competitive, comprehensive docs. I haven't used MUMPS yet though, not sure about other potential reasons. – user99151 Jan 19 at 7:23

# Lean

Lean is a relatively new theorem proving language. It is very user-friendly and it has a comprehensive math library which is "slowly eating away mathematics", as Kevin Buzzard puts it.

## Reasons

• Can be used as a programming language with formal verification support. The upcoming stable release (Lean 4) will make it even easier to program in Lean.
• Strong focus on approachability and soundness.

## Caveats

• Intimidating documentation. It's much faster to ask a question in the Zulip chat than trying to parse the (often very complex and dense) mathlib docs and Lean reference.
• You can't really Google anything about Lean. Lean is relatively obscure. But hey, the same goes for other theorem proving languages, right?

# Zsh

Zsh is a Bourne shell derivative which apparently specialises in having far too many ways to do some things, of which the shortest is always inconvenient, and no obvious way to do a lot of other things. Thanks to its liberal forgiveness of errors, it is very abusable, which is a great feature for code golf and makes competing in it particularly fun.

## Reasons

• It is easy to learn, but difficult to master
• By learning it, you will be able to write shell scripts much better and gain more experience with a practical interactive shell where you (should) spend a lot of your time
• It does surprisingly well in many text and pattern matching-based challenges, so you will be able to compete amongst even some golfing languages
• It's very good at restricted source, especially for a non-esoteric language
• I am the currently only active user, and I'd like to change that