# Esolang

An esoteric programming language is a programming language designed to explore unusual ideas, be difficult to program in, or serve as a joke rather than for practical use.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Why Small Programming Languages Can Encourage Implementations Instead of Use

DevFeed: [Why Small Programming Languages Can Encourage Implementations Instead of Use](<https://devfeed.tech/articles/the-siren-song-of-little-languages-22023.md>)

Original publisher: [Read original article](<http://www.wilfred.me.uk/blog/2019/03/24/the-siren-song-of-little-languages/>)

Author: Wilfred Hughes

Published: 2019-03-24T00:00:00Z

Content type: opinion

Language: en

Sources: [Wilfred Hughes](<https://devfeed.tech/sources/wilfred-hughes.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [Esolang](<https://devfeed.tech/topics/esolang.md>), [Lisp](<https://devfeed.tech/topics/lisp.md>), [Clojure](<https://devfeed.tech/topics/clojure.md>), [Racket](<https://devfeed.tech/topics/racket.md>)

Tags: [clojure](<https://devfeed.tech/tags/clojure.md>), [languages](<https://devfeed.tech/tags/languages.md>), [lisp](<https://devfeed.tech/tags/lisp.md>), [programming](<https://devfeed.tech/tags/programming.md>), [programming-languages](<https://devfeed.tech/tags/programming-languages.md>)

### AI overview

This commentary examines how small, elegant programming-language specifications can encourage developers to build implementations rather than use the language. It discusses BF, Scheme, Shen, Forth, Clojure, and Racket, and argues that language designers should consider the risk while recognizing that multiple implementations can also indicate language health.

### Source excerpt

Some programming languages languish due to obscurity. They lack breathless blog posts exclaiming how much nicer they are to use. Other languages are too ambitious. They aspire to support so many features that the original implementers struggle to get a first version working. For example, the type system in Fortress required constraint solving which took exponential time. Sometimes a usable language struggles simply because it's too much fun to write your own. Developers end up building their own implementation rather than actually using the language. The most obvious implementation-focused language is BF. Despite having many implementations, BF programmers have to encourage the implementers to actually try using the language! Scheme is also susceptible to this. Wikipedia lists 31 different Scheme implementations, not to mention the many toy implementations. Writing a Scheme is a great introduction to interpreters, especially once you get beyond the minimal lisp featureset. I've certainly written more implementation code than Scheme code. The problem seems to be languages with a small, well written specification. Shen is a multiparadigm lisp defined in terms of an elegant base language with only 46 system functions. This has resulted in a remarkable 15 third-party implementations, but only a small number of libraries implemented in the language. This phenomenon is not limited to lisps. Forth is also a language that developers often prefer to implement rather than use. Jones Forth is both a Forth tutorial and a discussion of how to build a Forth compiler. There are even stories of people spending years working on implementations without learning much of the language. Designing a language with a straightforward implementation is not a bad thing. It's just a pitfall that language designers need to be aware of. Some crypto systems have this problem too. It seems that we need languages to be big enough that new users write hello world in the language, not write a tool for