Skip to main content

Code in English

Code from programming languages ultimately gets compiled or translated down to some sort of digital code that a human would have difficulty reading.
The languages exist so humans aren’t required to read or write at the machine level. <- Lisp facilitates reasoning rather than attempting to be readable.
If the goal of programming languages is readability, why not have a single, human readable language? And why not just make it an actual language? Early languages like BASIC and COBOL were mostly based on English. We now have means to significantly advance that idea.
Let’s program using plain English.
  • Most of the world knows English so most of the world would know how to program (no need to learn a language).
  • If code is universally in English, it’s re-usable across all platforms.
  • Addresses concerns and frustrations with code comments. Comments aren’t much needed when code is in plain English.

Markdown as a starting point

Markdown, at least for now, provides an excellent starting point. It’s a plain text language that uses symbols people often use naturally for representing things like lists and emphases.
For example, consider this:
- buy some glue
- stop by Mark's
- post old books on ebay
That’s a list in Markdown. And it’s exactly how most people would type a list in a computer naturally. Markdown reads the way people would generally type if they don’t have special formating options like in Microsoft Word. We can still provide the same types of tools they use in Word, but the underlying language representing it all would be human readable. Thus it provides a great starting point for coding using English language, it’s just as readable.


Let’s say we want a small program to tell us how many photos are in a particular folder:
- get the list of all files in pictures folder
- print the list's length
That could be simplified to something like, “Tell me how many photos are in the pictures folder.” But the above list shows how the computer could be programmed to deal with requests like that. It’s all in English, and very easy to grasp.

Simple JavaScript example

Say we want a program to create a class called Player. We could use the following Markdown:
- has a name, height and date of birth.
- can move left or right.
If we transpile the above to JavaScript, we could end up with this:
class Player (name, height, birth) {

  constructor(name, height, birth) { = name;
    this.height = height;
    this.birth = birth;
  move_left() {
    this.x -= 1;
  move_right() {
    this.x += 1;
Clearly, using Markdown to code something like that is vastly easier and far more legible. It really doesn’t require much programming knowledge. And it could be compiled down to byte code or machine code. For now, it seems reasonable to transpile to other languages like JavaScript or C++. As the idea gains traction, an interpreter (and VM) and/or compiler would be made. The goal would ultimately be that the operating system would accept English language as input for everything. So we could do whatever we needed in the computer using plain English.


Popular posts from this blog

OpenGL Everything

Recent terminals like Alacritty and Kitty have proved OpenGL is the fastest way to handle text rendering. Xray, the potential next generation of Atom text editor rightly seems to follow suit. Meanwhile, Linux distros like Ubuntu have long been using OpenGL for general rendering to great success as seen with compositors like Compiz.It seems OpenGL might be the best technology for any and all rendering needs. If an OS is built on and uses OpenGL for everything, the consistency could yield great results. Text editing, image manipulation and even office apps would be as fast as possible.

Everything Text

Pixel and vectors, video and text. What if we built one editor that could handle all these cases and more? One editor using one human-readable text format for files. If we use Markdown, we can use code blocks to represent binary data, if needed. Besides being able to store binary data, we could create human-readable data sections using formats like Eno. We could even include executable code.  With the flexibility of Markdown and its respective code blocks, we could store any type of data in a manageable way. So the file format for our all-purpose editor is plain text, Markdown.

We'll build our editor for text processing. But from the start, we must account for all editing needs. We're building a text editor that can do what Photoshop does, and what Premiere does. So first and foremost, everything those editors can do, our editor must be able to do using plain text. From there, we can create intuitive graphic interfaces to facilitate different workflows. Those UIs will basicall…

The Text Editor

Text editing comprises the core of an operating system. Every OS ever provides some way to edit text. Even the terminal or commandline is a text editing experience. We should build the best possible text editing experience into the OS.Temple OS as inspirationIn Temple OS, the text editor is everything. The commandline is actually a programming experience since commands are compiled as they’re entered. Meanwhile, a special document format (DolDoc) lets users structure text for easy navigation similar to HTML but better because of the way it links to other documents. That’s all part of the same core text editing experience. And that experience distinguishes Temple OS. The text editing experience is all its focus.Markdown for powerIf we use Markdown for structured documents similar to Temple OS’s DolDoc format, we can advance it steps further by allowing code execution via code blocks. Code blocks are executed when documents are opened for viewing. We can use that same concept for any an…