Plain English Programming

[mikegonta]

Imagine a programming language that:

• Has keywords like A, AN and THE
  Lets you code what you're thinking
  Can recompile itself in 3 seconds

It's Plain English.
Our Sample Application
Imagine a program that can paint:

• Any person, place, or thing you name
  In the style of Claude Monet
  In 300 lines of Plain English code

The Complete Package

• Full-Screen Desktop Interface
  Super-Smooth Text Editor
  Elegant Page Layout Program
  Plain English Compiler and Linker
  General Purpose Subroutine Library
  Over 100 Pages of Documentation
  Source Code for All of the Above

Frequently Asked Questions
What language is it written in? - Plain English.
Does it produce native code? - Nothing but.
Does it need a runtime library? - Absolutely not.
What do I need to run it? - Windows XP, Vista or 7. Yuk.
How big is the download? - About 1 megabyte.
What format is the documentation? - PDF with Plain English source.

[thepowersgang]

Interesting concept, but just as en experiment.

Programming needs to be too precise to be properly controlled using a "natural" language, especially English.

I foresee a large-ish project in this language being as incomprehensible as legalese, except filled with clumsy terms in stead of precise terms.

[Brendan]

Hi,

Interesting concept, but just as en experiment.

Programming needs to be too precise to be properly controlled using a "natural" language, especially English.

I think (after looking at the source code for their demo) that it's a strict/formal grammar that can't handle arbitrary English in any way whatsoever. For example, I seriously doubt that "The text has a box and a string." could be written as "There's text and a string, both owned by the box." (or any of the many other ways you could rephrase it).


Cheers,

Brendan

[embryo]

...

Really nice artistic work! I had some fun and excitement while reading this. Imagination makes plain world to shine with a lot of colors

Also I see here an example of an almost ideal self-documenting code. Really useful feature.

But there is a problem - how a code can be efficiently managed when one chunk of it takes 481 kb (as is the case for "the noodle")? And even 33 kb of the "the editor" is a lot of brain-f**k, just because we need to realize in mind a call tree of a size of "too many lines" as is the case, for example, here:

to add to some blocks:
create a block.
to create a block:
allocate memory for the block.
to allocate memory:
...

And we need to do such trick for every line of the code. But may be there are some helpful rules, that had assisted you during the obviously long development process? What was a criteria for placing a code in the library (the noodle) and another in the actual program (like "the editor")? How long it took to remember all library procedure names (and there are at least 2000 names in "the noodle")? Or there is some additional documentation like API reference or something alike?

[KemyLand]

Interesting concept, but just as en experiment.

Programming needs to be too precise to be properly controlled using a "natural" language, especially English.

I foresee a large-ish project in this language being as incomprehensible as legalese, except filled with clumsy terms in stead of precise terms.

Somewhat true. It get's even worse when working with more complex (and stupid) languages, such as Spanish. The "code":

Code: Select all

to add to some blocks:
  create a block.
to create a block:
  allocate memory for the block.
to allocate memory:

Becomes:

Code: Select all

para agregar algunos bloques:
  crear un bloque.
para crear un bloque:
  asignar memoría para el bloque.
para asignar memoría:
  ...

This a grade of magnitude harder to parse than its English equivalent. Let's not even add Asian/Native American/Proto-indo-european languages into the mix. Maybe you could invent something like "English++" or "CodEnglish" or something similar, but forgive about parsing natural languages. Several disturbances in history have made them irregular and extremely informal. I don't know why people call "formal grammar" that thing natural languages are said to have. In them, there's always an exception to the rule, and usually it's not only one, and all of the "exceptions" to the rule that's not a rule are completely unrelated. Let's take an example: try to even parse (and translate) this same paragraph into another natural language, Simplified Chinese for example. Not even Google's Translator, one of the largest web corporations in the entire world can do it!

[Kevin]

Also I see here an example of an almost ideal self-documenting code. Really useful feature.

Only if you think that this is ideal documentation:

Code: Select all

xyz++; /* Increase the value of xyz by one */

Usually the job of documentation is to explain higher level concepts, not to describe the code line by line and expression by expression.

[embryo]

This a grade of magnitude harder to parse than its English equivalent.

I see you spanish sample as absolutely acceptable way of translation the idea to another language.
After you read the rules the simplicity of parsing will be obvious.

Code: Select all

Alrighty then. Here's how I manage to do so much with so little.

(1) I really only understand five kinds of sentences:
(a) type definitions, which always start with A, AN, or SOME;
(b) global variable definitions, which always start with THE;
(c) routine headers, which always start with TO;
(d) conditional statements, which always start with IF; and
(e) imperative statements, which start with anything else.

(2) I treat as a name anything after A, AN, ANOTHER, SOME, or THE, up to:
(a) any simple verb, like IS, ARE, CAN, or DO, or
(b) any conjunction, like AND or OR, or
(c) any preposition, like OVER, UNDER, AROUND, or THRU, or
(d) any literal, like 123 or "Hello, World!", or
(e) any punctuation mark.

(3) I consider almost all other words to be just words, except for:
(a) infix operators: PLUS, MINUS, TIMES, DIVIDED BY and THEN;
(b) special definition words: CALLED and EQUAL; and
(c) reserved imperatives: LOOP, BREAK, EXIT, REPEAT, and SAY.

Also I see here an example of an almost ideal self-documenting code. Really useful feature.

Only if you think that this is ideal documentation:

Code: Select all

xyz++; /* Increase the value of xyz by one */

Usually the job of documentation is to explain higher level concepts, not to describe the code line by line and expression by expression.

The lack of high level structuring power was mentioned in my previous post. But the lack of low level understanding among non programmers seems wasn't noticed by many programmers. So there are a lot of losses in translation.

[Combuster]

By the looks of it they essentially "invented" another incompatible flavour of BASIC

[Schol-R-LEA]

Sorry for coming late to the game, but I wanted to point out that there already exists a programming language called English (which, like this one, is essentially a BASIC offshoot), and that one is trademarked. It is (or was, I think it has been off of the market for some time) the default scripting language for the Pick operating system, which dates back to the mid-1980s.

EDIT: It seems Pick OS is still around, but due to legal wrangling, they renamed 'English' as 'ACCESS'. I'm surprised that they never sued Microsoft over that, or vice versa. Also, it seems I was mistaken about English being a BASIC derivative; it was a SQL derivative, instead.