The "reasonable licensing terms" are for the protection of those who want to create non-English language versions of the product (Plain Spanish, Plain French, etc) for sale to those language communities. The English version is now free.
I know this remark was directed to Mark, but what do you mean by "the only compiler which compiles the language it's compiled in"?
I don't understand that either. Seems the same to me.
Right. Many years ago we wrote a compiler for a Pascal-like language called AIQ in an early version of Delphi. Then we used AIQ to write a bare-bones version of Plain English (with just enough editor and compiler so we could stop working in AIQ and work exclusively in Plain English). Every version since then has been developed using only the previous version of Plain English.
But we think this is an important point. When someone says to me, "Language X is the best language ever -- but I wrote the compiler in Y", it makes me think that he really prefers language Y when he wants to get some work done. Which is why we thought it important to write Plain English in Plain English. And why we think a future HAL 9000, that communicates in English, should also be written in English -- the HAL shouldn't have to learn C++ to make little baby HALs; he should be able to do it in his native tongue.
Free as in freeware, not Free as in speech, you mean. If the product were Free as in speech, although people could sell the product, it wouldn't be "protected" - other people could compile the software themselves too and distribute it freely and Freely.
Take GCC - please! (It's Free.) GCC can compile itself. But GCC can also be compiled by the Intel C++ compiler, the Microsoft C++ compiler, and others. There is no other compiler which compiles your compiler - and evidently no Free one at all - because your compiler is written in the language it compiles, and only your compiler compiles that language.
If I'm not mistaken, you're harking back to my challenge to come up with more than ten (reasonable) ways to say "I'm going to the store". And it appears your argument here is that there are an infinite number of ways to say such a thing, once you're allowed to tack a conditional onto the statement. And that our compiler would thus need an infinite number of routines to be able to handle all those sentences.
Or why it just might! Either way, they'll definitely see how our approach works well enough for the coding of a complete and functional development system including a unique desktop, a simplified file manager, an elegant text editor, a handy hexadecimal dumper, a native-code-generating compiler, and a wysiwyg page layout facility, that fits in less than a megabyte and can recompile itself in less than 3 seconds on a puny machine. One wouldn't think all that possible if the theory was that far into crazy land.
It seems you guys have lost sight of what we were, and are, trying to accomplish with our system. The original goals are at the top of the thread; specifically, we wanted to know:
Actually, the idea is to teach the computer enough about what people typically say so that it will appear to understand them when they express themselves as they naturally do. That's why we use the terms apparent intelligence and natural language: it's a convincing simulation of intelligence that, under the covers, is nothing of the sort -- but that, on the surface, responds as might be expected to millions of very natural language requests that actual people might actually put to it. (Apple's SIRI is a similar project, with the disadvantage of not being English through and through!)
So when I say to my apparently intelligent PAL, "Hey Pal, open the garage door and turn on the light in the back yard," and it does, what is that? Or when I say, "Hey Pal, remind me next Tuesday at breakfast that I have a dentist appointment at two," and he does, what is that? I say that's the same kind of thing I'd say to my wife or my kid, and in the very same words I'd use with them. With the same effective results. Apparent intelligence.
Okay, free as in freeware.
Got it. Thanks. I think there's a difference here, however. Artificial programming languages begin with a precise definition of the language's syntax and semantics, and compilers are written to conform to that definition. Our compiler compiles a (useful) subset of a language that defies precise definition, in both syntax and semantics. Ask Noam Chomsky. And if someone else were to develop a similar compiler using different techniques, I suspect that it would succeed in understanding a somewhat different subset of the language. So I'm not sure there will ever be the analogous case with "natural language compilers" as there is with, say, "C" compilers.
I think it's more precise to say that a person can speak (or write) English ambiguously, or he can speak (or write) English precisely. It is the speaker (or writer) who is ambigous; the language itself, at most, allows ambiguity; it is not, in itself, ambiguous. The 25,000 lines of Plain English code in our development system are obviously not ambiguous (or are at least un-ambiguous enough) since the thing actually works.
Yes, because it seems you need to be reminded about the claims we are actually making.
But we're "real" programmers. Both my son and I have made our livings, for years, in the computer industry. And we want to (and do) use Plain English to write programs. Lots of 'em. When, for example, I needed to generate a list of all the syllables actually used in the English language for our "teach your kid to read in 20 minutes a day" course (www.rhymingreader.com), I used Plain English to do it. In fact, the entire course was written (and drawn!) using our wysiwyg page layout facility. And the published PDFs were generated by the same. The various statistics comparing our course with competing approaches (who covers which words, etc) were also tabulated using Plain English programs. If that's not a real-world application of the thing, I don't know what is.
But that's pretty far, don't you think? We don't have the resources of NASA, you know; we're more like the Wright Brothers.
I figure it's timing. Really. I wrote a relational database design course back in the 1980's (www.era-sql.com) and made millions licensing it to Oracle, Microsoft, etc -- a very popular product. I have since written several demonstrably better courses and haven't been able to sell more than a handful. What the difference? Timing. You can only sell mousetraps to people who are having mouse problems -- or who think they are!
No, because I know from direct experience that isn't so. When, for example, I wanted to write a program to teach my youngest to type, I immediately chose Plain English as the language to write it in; it was (by far) the fastest, simplest, easiest way to get exactly what I wanted on the screen. I suspect if you had a similar need -- and were as experienced in Plain English programming as I am -- you just might make the same choice. See? Timing. You can't see the benefits from where you're standing because you don't have the experience I've had with the the thing, and you don't have an immediate need for it.
But you don't, because you don't think a project like that would be worth the effort. We thought Plain English was -- and still do. I use it every time I write a new program.
What we've discovered -- and demonstrated with a working prototype -- is that it is easier (at least for us) to program in Englsih-language sentences, and that a relatively "sloppy" parsing algorithm can yield predictable and reliable results, and that a non-trivial integrated development system can indeed be conveniently and efficiently written in such a high level language. I call those three things "breakthroughs" only in the sense of "breaking through" people's preconceived notions that those statements are categorically false.
On the contrary. Here's a thought: "I want to add a big number to a smaller number." Here are some ways you could say that in Plain English:
We never claimed to have "fundamentally changed the way we instruct the computer to do things." We just made it possible to command the computer in sentences that are written and punctuated and read like other English-language sentences.
To me that's a bad example, where the "big" number and "small" number is much less clear than x and y. What if you don't know which number is embiggened ahead of time? What if they are roughly the same size?
If you teach someone to write code that depends on a number being "bigger" or "smaller" than another number, I suspect we can come up with cases where later uses of the numbers or addition result produces later results other than what's intended. I'm too lazy to prove that
Fair enough. Try this. I want to find the width of a box on the screen:
English is not the most effective way of expressing complex mathematical formulas; that's why mathematical notation was invented in the first place. But conversely, there are a lot of things that are not as conveniently or as clearly expressed in mathematical notation: "Clear the screen," for example, is hard to improve upon. And there's a lot of this latter kind of stuff in a typical program. In our development system, for instance, less than 15% of the 25,000 lines are mathematical in nature; the rest do things like "move this over there" or "sort that" or "send a page to the printer".
I don't think I said that. English itself is a symbolic language ("cat" in no way resembles either the thought or the reality). I'm saying that English is one of the bridges of which you speak, and one which in many cases can be mechanically reduced to the more formal, saving us the trouble.
People use natural language to decompose complex problems all the time, in all of the fields you mention, and then some. Every time a programmer, for example, uses pseudo-code to outline the solution to a problem. Or as Einstein did when he was developing his theory of relativity, talking about it with himself and others -- the precise formulas came much later in the process. Here, for example, is the first page of his description of the problem and solution in his own hand -- with nary a formula in sight:
You've used this example multiple times. Yet, I've never done it myself, nor have I ever seen any other programmers' pseudocode look like anything but an abstract symbolic programming language, including balding bearded folk, that have been doing it longer than I've been here. Maybe you do, but it's far, far, from, "every time a programmer uses pseudo-code to outline the solution to a problem."
Wikipedia's article on the subject defines pseudocode as "an informal high-level description of the operating principle of a computer program or other algorithm," which sounds reasonable to me (and, I imagine, to you as well). But then they almost immediately give examples of pseudocode under the headings "Fortran Style Pseudocode" and "Pascal Style Pseudocode" and "C Style Pseudocode" which are probably closer to what the term brings to your mind. What I think of when I hear the term appears under a related Wikipedia article entitled "Structured English". Here's the example given in that article:
IF customer has a Bank Account THEN
IF Customer has no dues from previous account THEN
Allow loan facility
ELSE
IF Management Approval is obtained THEN
Allow loan facility
ELSE
Reject
ENDIF
ENDIF
ELSE
Reject
ENDIFIf the customer doesn't have a bank account, reject the loan; exit.
If the customer has dues from a previous account, reject the loan; exit.
If management approval is not obtained, reject the loan; exit.
Allow the loan.Yes.
Ideally, the programming language and the database language should be one and the same. The best implementation I've ever seen of such a thing is a language called Starset developed by Mikhail M. Gilula; his book on the subject is here (but hard to find, since it's currently out of print):
Most people, at first blush, seem to think that's the case; we wanted to know if that was really true; that's why we decided to test our theory by writing a complete development system, including a compiler and a wysiwyg page editor, rather than something small and easy. It turns out that the "most basic of the logic" and the "real nitty gritty" can both be expressed, conveniently and efficiently, in Plain English.
Formulas when being explained to someone ofc are translated to normal language in order to explain relations between parameters used, what they mean and so on. But when you use the formula in equation you no longer use natural language but rather symbolic/numeric format.
Facebook
Twitter