A brief introduction to esoteric programming languages
hillelwayne.com
hillelwayne.com
My favorite thing about esolangs is using them as a chance to try out a design choice that's interesting but not necessarily good. Like what does making gotos an expression do to a simple lisp-y language? Designing and implementing languages is what I was most interested in in programming for a while and esolangs are a nice low-stakes way to practice that for me.
[1] https://esolangs.org/wiki/You_are_Reading_the_Name_of_this_E...
https://esolangs.org/wiki/BytePusher
To this day I wonder why this isn't a standard feature of every programming language virtual machine out there.
I'm fairly certain that INTERCAL introduced 'COME FROM'.
They later made a concurrency scheme based on multiple COME FROMs addressing the same label.
Yep. In fact, INTERCAL uses labelled COMEFROM, e.g. `COMEFROM foo`, in analogy to labelled GOTO like `GOTO foo`.
If you think that's silly, there are languages which have an unlabelled COMEFROM, which doesn't even specify where it's going to take over control from! This symbol is usually written `catch` or `except`.
SNOBOL, an early string-based pattern-matching language
K, a database query/programming language
PROSE, a dynamic systems modeling language from the 1970s that introduced automatic differentiation
Among languages most people would have heard of, though, my vote for the most esoteric goes to Prolog.
[0] https://matt.might.net/articles/c++-template-meta-programmin...
It's actually a metaprogrammable functional programming language. It's possible to do a ridiculous amount of stuff in it. For example, I managed to write a pure GNU Make implementation of the find command. I tried to implement a small version autoconf as well but stopped because I could no longer understand what was going on.
sendmail.cf configuration file.
text munging languages from the Unix environment, like ed and sed.
text munging languages from elsewhere like Teco.
nroff/troff.
Interactive Vi/Vim commands look like an esolang when you record them into a register and confront what that looks like.
It's almost unfair to put it on this list, because it's a genuinely cool and fun way to create music, especially if you're inclined to programming. This video [1] shows off the basic idea very nicely, and you can find lots more examples of it on YouTube. I highly recommend playing around with it if this is the kind of thing you find cool.
[1] https://rbjl.janlelis.com/34-do-you-know-the-official-ruby-i...
I found it last year and planned to contribute to the interpreter.
My favourite language is SK (combinatory logic), which is both tiny (two symbols + parentheses; one rewrite rule each) and reasonably sane (unlike, say, Iota). It's also useful, since it's basically just function definition and application, which is applicable to pretty much every "proper" programming language. Hence the 'puzzle solving' we do in SK can give real insights into day-to-day understanding of programming. For example, to make an if/then/else branch in SK we end up using Church encoding, which was quite enlightening to me.
In particular, I always thought of booleans as bits: a fundamental component of our computers; and of languages "sitting above" those bits, controlling them (and, in turn, being controlled by them; since programs are stored as bits, and we can write self-modifying code). From that perspective, the idea of representing booleans as functions seems backwards.
However, I found it intriguing to go down this "backwards" rabbit-hole: if Church-booleans are functions/programs that make a choice, then a bit is also a program that makes a choice. Passing around bits, in a language like C, is just like passing around higher-order functions in a language like SK (or lambda calculus, or whatever). The main difference is that booleans/bits aren't "native": we can't call them directly. They must be interpreted, and the interpreter is called 'if/then/else'.
On the topic of Church-booleans, it can be similarly enlightening to see how Smalltalk implements branching using polymorphism, with a 'True' class and a 'False' class which override the 'ifTrue:ifFalse:' method of the 'Boolean' class in different ways. After a little pondering, we realise that those method definitions are the Church-booleans; and hence polymorphism/dynamic-dispatch is a higher-order function call. Then we find that objects are a poor man's closures, and that closures are a poor man's object. The deeper we go, the more blurred our once-crisp distinctions become, the more of our unconscious assumptions fall away, until everything can be twisted into anything else, and it all becomes a matter of perspective.
None of these perspectives are "more correct" than any other, although some are certainly more consistent and practical than others. Hence playing with esoteric/minimalist languages can force us to learn unfamiliar mechanisms, and learn new uses for familiar mechanisms. This can give us more flexibility and insight when approaching real-world challenges, where a shift in perspective might turn an unsolvable/incompatible mess into a straightforward solution.
Also, it's the first of a twin prime. 8675311 is also prime.