Re: A Plain English Compiler

Martin Ward says, Gerry claims that all these questions can be answered in
the affermative: I would disagree.


Gerry replies, You are, of course, free to disagree. But keep in mind that
our understanding of the matter is first-hand, taken from actual experience.
Yours is merely theoretical -- and, based on your remarks below, appears to
be founded on a number of serious misunderstandings of both our prototype
and our project goals. For now, let me just say that (1) we know that it is
easier to program when we don't have to translate our natural-language
thoughts into an alternate syntax because we've actually done it both ways,
and find ourselves greatly preferring the natural language environment. (2)
We know that natural languages can be parsed in a relatively sloppy manner
and still provide a stable enough environment for productive programming
because, again, we've done it. And (3) we know that low-level programs (like
compilers) can be conveniently and efficiently written in high level
languages (like English) because, yet again, we've done it.


Martin Ward says, But if some of the above *can* be done, the effort is much
greater than with a traditional "Algol-like" programming language with a
limited set of keywords and unambiguous, precisely defined syntax and
semantics.


Gerry replies, That first clause should read, "has been done." And we know
it's easier to do it the Plain English way because we've actually done it
both ways. You're arguing with actual experience when you talk to us,
Martin, and actual experience is very hard to refute.


Martin Ward says, Let's take one of the most basic concepts in imperative
programming: the assignment... MOVE bar TO foo


Gerry replies, I think a little more self-examination is required here.
"MOVE bar TO foo" may be "natural" to you, but that's only because you've
studied programming languages extensively; it's not a natural way of
speaking English. Do you really say things like "Please pass salt" and "Put
car in garage" when you're talking to other humans?


Martin Ward says,


copy bar to foo
set foo to be equal to bar
make foo equal bar
assign bar to foo
assign foo from bar
get bar and put it into foo
put foo into bar (although this suggest that bar is a set)


As far as I can tell from the manual, none of these will work.


Gerry replies, This is one of the places where you seriously misunderstand
our compiler. Plain English is user-extensible; the programmer can easily
teach the compiler to understand his particular dialect of English and his
preferred modes of expression (within limits, of course -- it's only a
prototype) simply by defining new routines.


Martin Ward says, The little words "the", "a", "an" which can often be
omitted in natural English appear to be absolutely required in this
language: "the" indicates a global variable, while "a" or "an" indicates a
local variable.


Gerry replies, Our studies have led us to believe that "the little words"
are what people actually and intuitively focus on when parsing language in
their heads; so yes, articles, prepositions, and conjunctions play a
prominent role in our compiler. Try removing all the articles, prepositions,
and conjunctions from this post and see if it appears English-like to you.
See if, in that form, it is more or less natural, more or less intelligible.


Martin Ward says, This reminds me of the old fashioned text-based adventure
games where you knew what you wanted to do: but getting the parser to accept
your command turned into a game of "guess the verb":


Gerry replies, As above, your ignorance of our prototype and project is
showing. Almost all verbs in Plain English are defined by the programmer,
not our system; it's the articles, prepositions, and conjunctions that we
focus on. And every English-speaker knows what those "little words" are and
where those "little words" go in a sentence.


Martin Ward says, Another example: you can "divide the foo by the bar" but
cannot "divide the bar into the foo".


Gerry replies, Plain English supports both ways of expressing that thought.
And many others.


Martin Ward says, So: you *do* need to translate your natual language
thoughts into an alternative syntax: the minimalist subset of English
accepted by the parser.


Gerry replies, Again, no. The "subset of English accepted by the parser" is
user-defined.


Martin Ward says, Of course, since you have the source code, you can extend
the parser by adding different ways of saying the same thing.


Martin Ward says, No, the programmer extends the language by creating new
routines in his own source code, not by changing the compiler.


Martin Ward says, Which leads us to the next problem: ...if you are working
on a team and have to read other people's code then you will need to be able
to recognise *all* the different ways of writing a standard statement or
call: in this case, adding more variations just adds to the amount of
"legalese" you have to remember.


Gerry replies, Case in point: (1) You're wrong again, Martin. (2) Once
again, you're wrong. (3) Wrong, Martin, once again. Did you have to "learn"
anything to understand those three sentences? No! Team members understand
each other's code because the thoughts are expressed in the most natural and
common ways. You don't have to understand Plain English to understand a
routine written in Plain English -- you only have to understand English.


Martin Ward says, The semantics may be subtly different from the semantics
of natural language. For example, in English: "A plus B times C" means, as
any schoolchild will tell you, multiply B and C together and add the result
to A.


Gerry replies, Again, your education and your culture have biased you. Here
in America -- among average English speakers on the street, young and old,
"A plus B times C" means "start with A, add B, then multiply by C". Try it:
ask average people on the street what "five plus five times three" is;
they'll say "Thirty" more often than not. It is only those trained in
mathematics that see it otherwise. And here again your ignorance of our
prototype and our goals is hampering your evaluation. We fully intend to
include standard mathematical notation in the language; the purpose of the
prototype was to see how far we could get without it. For such future plans,
see:


https://www.indiegogo.com/projects/the-hybrid-programming-language/x/8950932


Martin Ward says, The problem is that English is ambiguous and the ambiguity
in the "Plain English" source code is not resolved by the ambiguous English
sentences in the manual!


Gerry replies, This is a very common misconception. English itself is not
ambiguous; it is a very powerful tool that can be used both unambiguously
and ambiguously; it is the user of English, not the language itself, that is
either ambiguous or not.


Martin Ward says, The whole "Plain English" language is actually quite
limited...


Gerry replies, Yes and no. It's a proof-of-concept. It's a prototype. It's a
work in progress. So yes. But it is also user-extensible, so no.


Martin Ward says, ...with "Plain English" we also have to memorise all the
different ways to write the same statement, and all the subtle semantic
differences between it and English.


Gerry replies, I really don't see how you could miss the mark by a wider
margin. The whole point of Plain English is to make memorization
unnecessary! You simply code what you're thinking and it works. And if it
doesn't, you write the routines necessary to make it understand, so the next
time it will understand more. Like all natural languages, Plain English is a
living, growing thing; and, like all natural languages, it develops into
different dialects in the context of different users and user communities --
dialects that are, nevertheless, understandable by all who speak (or write
or code in) the mother tongue.


Martin Ward says, A real test of the utility of "Plain English" would be to
compare...


Gerry replies, The "real test of the utility of Plain English" has been
completed. Two programmers, experienced in a wide variety of languages,
wrote a complete development system -- including interface, file manager,
text editor, hex dumper, native-code-generating compiler/linker, and
page-layout facility for documentation -- conveniently and efficiently, in
Plain English. In just six months. And they found it more natural, more
effective, and simply more fun to do it in Plain English than in any other
way.


Gerry adds, It surprises me, Martin, that a fan of Chesterton wouldn't be
attracted to a project such as ours. Chesterton was the quintessential
iconoclast, and he delighted in helping people realize how blinded they
could become by accepting the status quo without question. So he would "turn
things on their head" and "look at things backwards" to make his point.
Which is exactly what we've done: we've developed a system that challenges
pretty much every preconception about programming a modern practitioner
might have: Are installation programs necessary? Can a high-level language
like English be used to conveniently write low-level programs like
compilers? Can a workable interface be designed without icons, scroll bars,
radio buttons, and a wide variety of other widgets? Can complex programs be
clearly and concisely written without nested ifs and loops? Can a
polymorphic drawing program be effectively programmed without objects?
Should menus be organized like a table of contents, or like an index? Should
documentation be dry and serious, or challenging and fun? Can only
scientists and mathematicians write efficient compilers, or can poets and
comedians do the same?
[The small size of the user base worries me. Over and over, stuff
that seems obvious and natural to a small group of developers turns out
to be strange and baffling to other people. -John]

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