Re: Writing A Plain English Compiler

Joshua_Cranmer:
You want to design a language model that allows people to express
their thoughts in the most natural way possible.


Gerry:
Yes. And it seems to us that the method of expression that is both most
frequently used and that has survived the test of time is that which is
pictured and described in our Hybrid Programming project:


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


A natural language framework, with other modes of expression (formulas,
graphics, etc) inserted where appropriate. You can see examples of it in
human-to-human communication everywhere: web pages, encyclopedias, white
papers, and this very forum. It's the natural way humans communicate ideas.
All we want to do is extend that paradigm to include human-to-computer
communications.


Joshua_Cranmer:
Yet at the same time,
you limit the expressibility of the programming model because, well,
you personally don't think naturally in alternative models and thus
you don't see why other people might.


Gerry:
It's true, I prefer a procedural approach for solution descriptions; and I
think most of the
people on the planet, by far, do as well. But that doesn't mean that I would
be against someone inserting a snippet of event-driven code, or an object or
two, or whatever, in the middle of a Hybrid program.




Joshua_Cranmer:
When I tried to point out examples of alternative paradigms, your
reply was fixated on trying to prove that you could express them in
your procedural paradigm. That's not the point. The point was that
having to do these paradigm translations is as much a programmer
burden as, say, having to translate from "I need to solve this
equation" to writing the code to solve that equation.


Gerry:
Yes, but I believe that most systems are procedural at bottom; and that most
people naturally think procedurally. (Think of the billions of instruction
manuals, repair manuals, how-to books and even recipe cards that have been
written on any and every imaginable topic.) I further believe that most
problems, when fully understood, can be most easily described and understood
and solved procedurally. But Hybrid programming allows for the specialists
among us, as above; and rightly so.


Joshua_Cranmer:
But those two statements are not semantically equivalent. The example
you give requires the program to continually check in a busy-wait
loop; the example I gave does not.


Gerry:
And in a Hybrid program you would be able to specify either solution.


Joshua_Cranmer:
After reading the thread you posted, it became clear to me that you
are (were?) under the impression that having a self-hosting compiler
was rare for a new proposed language. On the contrary, it is (to my
knowledge) standard rigor to present a new language by having its
self-hosted compiler be the largest application written in said
language. I've even heard it opined that this tends to cause people to
optimize their language design for writing compilers to the detriment
of other kinds of applications.


Gerry:
I don't think it's at all rare for a new language to be "written in itself".
(Though many of today's most popular languages are not: Javascript, for
example.) It is somewhat more rare to have a complete development
environment
written in the new language; and quite rare for a compiler-writer to "prove"
his language by writing a wysiwyg page-layout facility in his new language
and then use that facility to produce the documentation for the language.
And extremely rare for the whole thing to be written in English-language
sentences. Point me to some English-sentence compilers (or even
interpreters) written in English: SIRI? No. Alpha? No. Inform? No.


Joshua_Cranmer:
Your comments about "subset of English" are misleading, when taken in
context of your stated goal of making a "natural language" compiler.
That term, in the eyes of most, would imply that you could, say, build
a compiler that inputs the ISO C++11 specification and outputs a
working C++11 compiler.


Gerry:
A program that could "input the ISO C++ specification and output a
working C++ compiler" would not be a compiler, to my way of thinking, but
a (non-human) analyst and programmer; a thing capable of analyzing a
specification, devising an appropriate design, and then implementing that
design. A compiler is much more like a translator in my mind. Now if the
"specification" in question was a step-by-step procedural description of
exactly how to convert C++ code into machine language, then I would call a
program that actually accomplished the feat a compiler.


Joshua_Cranmer:
Programming came so naturally to me that I disclaim any ability to
properly evaluate programming 101. But the responses you have given,
both in this newsgroup and the AnandTech forum thread, suggest to me
that you are aware of the issues in writing large, complex software:
you appear to value minimalism in a language (rather than in client
code) very highly, and you appear to be very dismissive of "new"
paradigms.


Gerry:
Yes, I value minimalism in everything very highly, and I am dismissive of
"new" paradigms that have obvious flaws or limitations that are not
recognized by their proponents.


Joshua_Cranmer:
A mild example of that tendency is present in the statement I quoted:
you list compilers as the "more complex" endpoint, yet compilers are
relatively simple affairs--which is why compiler courses tend to
assign "build a compiler" as an ongoing project in the course.


Gerry:
I see compilers as unique. A program that cannot be used to produce better
versions of itself is derivative at best, sterile at worst. I also believe
that there is no such thing as easy or hard problems: that any
well-understood solution to anything, taken one proper step at a time, can
be understood by nearly anyone. Some such problems are certainly larger than
others, and some more tedious; but that doesn't make them hard; just big or
boring.


Joshua_Cranmer:
The sorts of projects I associate with production languages tend to start
considering themselves large only when they get a few million lines of
code.


Gerry:
Yeah, I don't think any problem deserves a million lines of code. Compare,
say, Windows (50 million lines) to Oberon (25,000); somebody needs to start
deleting. But let's say Plain English or the Hybrid Programming Language
that we're proposing never got past 25,000-line systems; surely they would still
be a useful things.

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