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.
Advantages:
  • 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.

Example

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:
Player:
- 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) {
    this.name = 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.

Comments

Popular posts from this blog

Familiarity and workflow

Blender is a 3D design software with a built-in video editor and a powerful compositor, among other relatively hidden gems. The advantage of these tools in a 3D design app might not be obvious to some but it saves from having to learn workflows of multiple apps. Once a user is comfortable with Blender's basic workflow and key commands, it's much easier to learn other parts of the software. Rather than exporting rendered videos to edit in another software, they can use the workflow they're already familiar with to edit within Blender. To be forthright, Blender has a steep learning curve. It takes time to get acquainted with it. The reward being increased productivity through familiarity with an intuitive and fast workflow. Once that time is taken, the same workflow can be applied to other aspects of design like video editing and compositing. What we want is a workflow that's far easier to learn than Blender's. Notepad for Windows provides our base experience. An

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.

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 inspiration In 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 power If 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 fo