Re: Writing A Plain English Compiler

I'm replying to several posts together because the answers are closely
related. I'll answer specific questions and comments in a moment; but first,
allow me a couple of introductory remarks and an example that will help
throughout.


One of the main purposes of our research is to determine how "ordinary"
people -- ie, people untrained in formal methods of problem solving and
artificial modes of expression -- (a) naturally think about, and (b)
naturally describe, procedures for solving problems. Since the making of
popcorn was brought up earlier, I'll use that as an example. Here's how my
wife described the process -- with just a little prompting for clarification
of certain points -- when I asked her:


To make some popcorn in a microwave oven:
Put the popcorn in the microwave.
Turn on the microwave.
Wait until the popcorn is done popping.
Turn off the microwave.
Take the popcorn out of the microwave.


Note that my nine-year-old son independently gave a virtually identical
description. Further note the following:


1. The process, in their minds, is naturally sequential and procedural.


2. They don't give formal names to any of the objects in the situation, but
use generic nouns (popcorn, oven) preceded by articles (some, a, the) with
an optional adjective sometimes appearing inbetween (microwave). They use
indefinite articles (some, a) when referring to entities in general, as in
their opening statements, but switch to the definite article to refer to
those same entities thereafter. And they often use the adjective preceding a
noun by itself (as if it were a noun) for convenience -- just "microwave"
instead of "microwave oven".


3. Admitting that there may be more concise (or even precise) ways of
expressing these thoughts, and allowing for minor variations in expression,
I think it's fair to say that this way of describing the process is probably
the clearest and most natural for the kind of people described above -- any
English-speaking person can understand it, without training of any sort. And
it works for the computer, too, since it is also Plain English source code
that will compile directly to machine instructions.


And now to your specific remarks.


John says,
I think you're missing the point he was making about "once ...".
Event driven languages have a different model, you tell it what
the triggers are, it figures how how and when to call them,
typically from an implicit event loop. But you don't have
to write the loop.


Gerry replies:
Yes, I can see how you might think that. The bottom line is that I don't see
any significant difference between a system with a compiler-generated loop
that dispatches events, and a system with a similar loop hand coded: in both
cases the programmer has to tell the thing where to go and when to go there.


Bartc says,


For a start, anyone considering using such a language probably wouldn't be
concerned with type definitions. If it is meant to make programming simple
and accessible, then dynamic typing is expected (or more likely, someone
won't even think about that aspect; it should just work).


Gerry replies:
I strongly disagree. Ordinary people are extremely "type oriented" -- they
refer to almost everything in their lives (other than humans and pets) by
type names. Like "popcorn" and "microwave oven" above. "Put the book on the
table by the chair" is a natural mode of expression, and it is thoroughly
based on types (books and tables and chairs). Further, such people expect
books to be books and chairs to be chairs, and they expect them to stay that
way; "dynamic typing" is a very foreign concept in real world.


Bartc says,
But then, even with a more informal language, there's only so much that can
be done, because to create sizeable programs that work reliably, I think you
need to use a more stylised and disciplined way of writing instructions. Any
free-format English would get in the way of that.


Gerry replies:
We offer our prototype system as proof that is not so. It is a sizeable,
reliable program that includes a unique interface, a simplified file
manager, an elegant text editor, a hexadecimal dumper, a
native-code-generating compiler/linker, and a wysiwyg page layout facility
for documentation; and it was coded entirely in Plain English --
conveniently and efficiently so.


Bartc says,
(I assume this syntax would just be a front-end to a conventional language
and conventional compiler, as your list suggests, and is not some
super-advanced AI project that can understand anything.)


Gerry replies:
On the contrary, we compile Plain English source directly to machine code.


Bartc says,
Using syntax that looks like written English sounds attractive, and might be
suitable for some kinds of command-line interaction ('kill dwarf with axe'),
but I'm not sure it would be taken seriously for real programming.


Gerry replies:
Our prototype IS a real and non-trivial program, and it was coded entirely
in Plain English. It is capable of reproducing itself, and has been used to
create many new and better versions of itself. It has also been used to
create other programs that have been used productively by a variety of users
in a variety of ways. It is also excellent for education because it is not
only suitable for beginners, but can be used to teach advanced subjects
(such as data structures, compiler design and implementation, etc) as well.


Bartc says,
Maybe, a tool can be used to translate conventional syntax into the English
style you propose, which would be fun, but I don't know if it warrants
creating a whole new language. Not if it doesn't otherwise do anything new.


Gerry replies:
The language has already been created. But we're not striving for something
new; rather, we're striving for something old, as I described at the top of
this post: a programming environment that will allow ordinary people to
explain things to a computer in their ordinary way.


John says:
Back in the 1970s there was a vogue for extensible languages, in
which you could add new syntax on the fly, by adding new BNF to the
underlying grammar. They all disappeared, because what happened was
that no two programs were written in the same langauge and nobody
could read them.


Gerry replies:
An obviously bad idea. And not at all what we've done and are proposing for
the future. We're aiming at a compiler that will properly translate natural,
popular, and well-understood modes of expression into something computer can
run.


John says:
Now we have OOP, where the syntax doesn't change,
but you can add lots of new types and semantics to go with them.


Gerry replies:
OOP is fundamentally flawed. See
http://harmful.cat-v.org/software/OO_programming/why_oo_sucks . And Plain
English is user-extensible in those ways without the syntax problem (since
any extensions to the syntax are also English, which is already understood
by every English-speaking person).


Bartc says,
Actually, some of us are fussy about syntax, but while we might prefer
something less terse than C++, it's not necessary to go as far as something
that can be mistaken for English.


Gerry replies:
It IS necessary if we want to program like we naturally think and speak to
others; if we want our programs to be self-documenting; if we want to be
able to teach both beginners and experts using the same language and the
same paradigm; etc.


Bartc says,
About a year ago, I had an experimental project where I could write code in
my own preferred syntax, and it would translate it to one of a number of
well-known languages. It worked up to a point
(I wrote some small benchmarks that were translated
to C, Python, Lua, Lisp and one or two others. In some simple cases, exactly
the same code would work unchanged on a number of different targets). But
you still had to be aware of the different capabilities of each target. In
the end, I preferred to create a proper language of my own (two in fact).


Gerry replies:
We've written lots of different languages of our own, too. The problem with
all such things is they are essentially arbitrary -- and there is no end to
them. We were working on one when we switched to natural language
programming, in fact. Why? Because we wanted to write the "last" programming
language, not just "another". And because we saw that natural languages
allow ordinary people, and very young students, and even experts to think
and write in ways that are natural to them and their peers. We saw that such
programs are self-documenting, as well. And long-lasting -- think about it:
grab a routine written in any popular programming language and ask yourself
how intelligible it will be to people who live 100 years from now; then ask
yourself the same thing regarding the Plain English routine at the top of
this post.

Return to the comp.compilers page.
Search the comp.compilers archives again.