# 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

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

# 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?

# 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

# Knight

Knight is a new programming language created back in April by sampersand.

### Interpreters

There is a list of interpreters on the official GitHub page. It has been ported to many languages, even itself.

Here is an interpreter on TIO, a patch to a previous commit to c/golf which updates and fixes some conformance issues. (Note that it memory leaks like crazy and segfaults on malformed inputs).

However, the "preferred" interpreter is c/ast, which is the fastest, most up-to-date interpreter and has actual error checking.

### Description

Knight is a Polish notation language (meaning x + y is + x y, and everything has fixed arity) which is relatively simple. It has some useful string manipulation tools, eval, shell commands, and type coercion.

### Reasoning

• It is a new language which deserves some attention.
• It is simple and very easy to pick up.
• It is surprisingly golfable despite not being a dedicated golfing language.
• Knight has some qualities/quirks that make it very unique to golf.
• Polish notation
• Tokens are separated by their character class. So, for example, WX is WX, while Wx is W x. This makes ordering very important.
• Only the first statement is executed, everything must be chained (typically using ;).

I have posted some solutions here already.

### Resources:

• Food for thought: maybe we have a golfing challenge where people golf knight? – Sampersand Jun 9 at 20:09
• Usually they don't do that here, what some people like to do is create a bounty for the first programs in that language – EasyasPi Jun 9 at 22:59

# tinylisp

A minimalist Lisp dialect that I invented for an interpreter golf challenge. Because Lisp is powerful, tinylisp's small set of builtins can be combined to solve a wide variety of tasks.

## Reasons

• The core builtins are one character each, contributing to golfiness.
• There is a standard library that implements a bunch of more-complex functions.
• Being a Lisp dialect, tinylisp is pretty good at functional programming and list manipulation.
• I'm basically the only one who uses it.

## Caveats

• The only documentation is the GitHub readme, which gives a decent introduction to the syntax and builtins but doesn't cover the library at all.
• String operations are supported, but not very thoroughly. All numbers are integers--no rationals or floating point.
• If you don't already speak Lisp, tinylisp might be hard to understand.

## K

K is a member of APL-family languages, originally created by Arthur Whitney. Arthur's K has many versions; the latest version as of June 2021 is Shakti (also commonly called K9), which is still under development.

While official K versions were made for commercial purposes, multiple open-source implementations are also available. Two actively maintained ones are oK by John Earnest (JohnE), and ngn/k. The oK manual is a particularly good resource to get started in K, and then you can choose to move to ngn/k without too much problem (the two are 99% compatible with each other). You can also ask any questions about programming in K in the k tree, where multiple open-source K implementors (including JohnE and ngn) and other K users are regularly active.

## Why K?

• It is the K language actually used in investment banks and hedge funds.
• It is a great example of iterations of language design, aimed at general purpose programming with a small set of built-in functions and easy-to-parse syntax. I'd especially recommend K to the CGCCers interested in making their own languages.
• The oK manual is an excellent resource for starters.
• Despite being relatively minimalistic in the list of built-ins (and being ASCII-only), K is often pretty competitive in code golf.
• K is also often pretty fast for an interpreted language.

# 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