In the Conceptual Languages piece last year, we looked at esolangs that produce no programs at all, or the same program repeatedly, regardless of source code. These languages focus on the compiler as a place of validation, a tool that filters code that belongs to the language or doesn’t. They have a minimal syntax or none at all, because the language never takes that next step text, to produce programs according to that code. 

Compute (created by an esolanger known as Orange) is similar, in that every program it produces apparently does the same thing – only here the aim is a bit different. As Orange describes it:

Compute has no required syntax and has the power to solve any and all problems. It is smart enough to interpret any human language (English, Spanish, Latin, etc), any programming language (C++, Java, brainfuck, etc), or any kind of data you can think of. The only downfall is that there is absolutely no I/O.

Without I/O, Compute does not have a way to communicate back to the user: telling it to print “Hello, World!” will not actually produce the those words to the screen (that, after all, requires output. So how do you know that it succeeded? Compute tells you.

print 'hello, world'

Produces “Done.” You’ll just have to trust that, somewhere, Compute has printed those words.

Trying this command:

become self aware

 

(as suggested on esolangs.org), it also immediately replies “Done.” And it accomplishes this as quickly as it accomplishes printing “Hello, World!”. Compute apparently runs very, very fast. It’s no secret that Compute is a joke language, its promise an empty one. Like the classic net art piece Zombo.com, it promises the world and never delivers.

 

Beyond the immediate joke of Compute, it’s interesting in how it reflects a programming language as place of translation between human thought and computer logic. The name reflects the classic line of robots from movies from the 50s to the 80s that try to understand human expression and exasperated, declare “DOES NOT COMPUTE.” In Compute, the onus of understanding is moved entirely to the machine. There are no compromises to the machine in the way we express what we want (in a sense, this is the opposite of low-level languages like brainfuck, that expose the strangeness of assembly-level logic). We express what we want using our own language – the same way we would speak to other people, with none of the precision and clarity asked for when writing actual code.

This fits a certain ideal of programming languages – let the computer understand exactly what we want, in a way that is most natural to how we communicate. The problem is that we don’t generally communicate in a precise way, and that precision is key to computing. One approach to this idea hit its peak with the “naturally-voiced” high-level languages such as Visual Basic (as it is was originally conceived in the early 90s – what we have today in VB.NET is quite a bit different). These languages promised an intuitive approach to programming designed for non-programmers: the idea that anyone could learn to code if the language was made simple enough. The result was a wordy and less intimidating language, and one that hid complexity (memory management, thread safety, etc) from the ordinary user. However, that complexity still lurks in the background, and its wordy style encouraged users to write long, unstructured scripts that quickly became sloppy, unreadable code. 

There is always a trade-off between protecting programmers from common mistakes, giving a high level of control, and making the resulting code easy to understand (as described very well in this piece).  Compute gives us what we want – a machine which can not only understand exactly what we want with great precision (even if our code is lacking that very same precision), but can actually deliver it to us.