Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: "Gerry Rzeppa" Newsgroups: comp.compilers Subject: Re: Writing A Plain English Compiler Date: Sat, 8 Nov 2014 02:41:24 -0600 Organization: Compilers Central Lines: 178 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-11-015@comp.compilers> References: <14-11-004@comp.compilers> <14-11-005@comp.compilers> <14-11-007@comp.compilers> <14-11-014@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Trace: miucha.iecc.com 1415455610 75972 2001:470:1f07:1126:0:676f:7373:6970 (8 Nov 2014 14:06:50 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Sat, 8 Nov 2014 14:06:50 +0000 (UTC) Keywords: design Posted-Date: 08 Nov 2014 09:06:50 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1423 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.