This work is licensed under a
Creative Commons License.
I received the following message a few days ago...
Dear Travis,
Was that you who recently wrote the following about our site?If so, and if you're interested, I'd like to try to clear up some of your misunderstandings about our work. Write me.
Sincerely,
Gerry Rzeppa
Grand Negus, The Osmosian Order of Plain English Programmers
Curiosity and unwillingness to let such an opportunity slip by, I offered for him to fire away, as long as everything said was fair game for publishing. To be fair, I did give him a heads-up that he was facing an uphill climb. I dutifully reminded him "that you engaged me in this conversation, so it's on you to convince me that your philosophy isn't naïve and the resulting programming language/environment isn't useless for practical purposes; this is my current opinion."
Round 1
Our work is important for two reasons.
(1) It presents a credible challenge to a number of preconceived and virtually unassailable notions that, we believe, need questioning. The program works - conveniently and efficiently - without icons, radio buttons, scroll bars, dialog boxes, tear-off palettes, objects, nested ifs, nested loops, artificial syntax, and a variety of other commonplace gadgets and constructs. At worst, that should rank it in the "surprising" category. At best, "an example to emulate." We, in our typically modest way, usually say something like, "thought provoking" or "worthy of study."
(2) It parses language as, we believe, humans do. Chomsky spent years investigating rigid syntax definitions for natural languages and, in the end, gave up. The reason for his failure, we believe, is that natural languages have no rigid syntax, nor do they need one -- if the approach one takes to "understanding" a sentence is not based primarily on the meaning of the words in that sentence, but on whether or not a "precompiled routine" for handling that kind of sentence exists or can be quickly assembled in the listener's mind.
Consider. A six month old knows what a bottle is, and knows how to suck on one; in other words, he has a noun in his head by his left ear (attached to an appropriate but sketchy picture on the other side of his brain), and a compiled routine near the back of his neck labeled "suck bottle." Now when daddy says, "Hey, Chuckles, want to suck on your bottle a bit?" the child hears only "blah, blah, blah, blah, suck, blah, blah, bottle, blah, blah" but responds, properly, by executing the only routine in his head that comes close to "matching" that sentence. Had daddy said, "Bottle suck" the same result would follow, since word order isn't important to a six-month-old, and even "Bottle" or "Suck" all by themselves would probably work -- because there's only one routine with either of those words available. But as he is taught new sentences -- note that I say taught, not "as he learns" -- his discrimination increases; not because anything structural has changed, but because he simply has more nouns and more routines to choose from. It's slightly more complicated than this, of course, but I think it illustrates the major differences in our approach: (a) we consider a sentence "understood" when it is matched to an appropriate, pre-compiled routine, and (b) we'll settle for a "sloppy" match when a better one can't be found.
Our compiler implements this algorithm - with extensions, type reductions, and a handful of keyword markers (articles, prepositions, conjunctions) to allow for recursive, phrase-by-phrase substitutions - to match sentences with the intended routines. It has proven itself in practice to be a simple, efficient, and remarkably (some would say, suprisingly) reliable approach.
Now I know we're not talking "genius" like Einstein here; but I do think we are talking genius in the style of Henry Ford -- genius that, instead of attempting to calculate how many gallons an oddly-shaped fuel tank might hold, simply fills it with water and then empties the water into gallon jugs while counting (with small integers). It's not magic, but it is a different, simpler, and -- from what we've seen and done -- very effective way of thinking.
And so, as you examine our work, please keep three things in mind:
(1) The product is NOT intended for isolated self-study. Both the program and the documentation are designed to provoke questions and discussion. So when anything strikes you as unusual, strange, or just plain stupid, ask: help@osmosian.com. We have at least three good reasons for everything that we put in there, and we're more than happy to tell you what they are.
(2) The product is intentionally different -- iconoclastic is the term we use. It is designed to make the programmer question almost every preconceived notion 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? And so forth.
(3) The product is serious stuff, in spite of our tongue-in-cheek presentation. We really believe in our unique and deceptively simple approach to natural language parsing. And we really do think this approach will provide a firm foundation for computers like the HAL 9000 sometime in the not-too-distant future. Our next step is to install the compiler on a dedicated machine where all previously compiled code will be resident at all times. We will then extend that machine's compiler to accept and rank additional and even alternative defintions and routines submitted by a group of dedicated Plain English programmers who will continue to "teach" it new things over a period of years. Our hope is to recruit 100 such teachers who will each explain 10 things to the machine every day, so that at the end of just three years, our "apparently intelligent"(tm) machine will understand and properly respond to more than a million natural language sentences. There's more to it, of course, but that's the gist. And yes, it's a bit of a "brute force" approach. But very much like the one we all use with our human children!
You can get the most recent Plain English compiler here: www.osmosian.com. Less than a megabyte. Note that. Just download and unzip it. This is the complete product. No further installation is required. Note that too. Start with the PDF in the "documentation" directory and before you go ten pages you'll be reading the instructions using the built-in page editor and recompiling the thing in itself. In less than three seconds. Note that as well.
If you're serious, it really helps if you take the time to print off the first 54 pages of the manual, and actually type in the sample program. I know this sounds tedious and even childish, but it is the best way to get a feel for Plain English programming and our spartanly simple development environment.
The Meek and Patient Negus of the Osmosian Order of Plain English Programmers
And I countered.
1) There are a great many things about contemporary interface design that need work. What you're trying to do was described fairly well by Donald Norman in his book "The Psychology of Everyday Things" where he described the difference between "knowledge in the head" and "knowledge in the world". A problem faced by any sufficiently complex system is how to make the available complexity accessible. Immediate options are:
A) Invent metaphors and teach others how to use them (knowledge in the head). This is the approach taken by most enterprise software which typically is sold with instructional documentation and on-site training bundled in with the product. It is also the easiest cop-out for the developer.
B) Utilize as many assumed-existing metaphors as you can (knowledge in the world). If you create something that utilizes the same metaphors people use in day-to-day life, they should be able to recognize them, and begin using the system intuitively. This is more difficult, but is generally regarded as the ideal.
C) Reduce complexity. No need to make the complexity easy to use if the system isn't sufficiently complex.Your approach appears to primarily use option C with acknowledgment of awareness of option B. The usability still needs a great deal of work (due mostly to interface bugs) but essentially relies on the lack of any advanced features in order to make the system approachable. Keep in mind that there's nothing wrong with that--there are a great many software titles that flourish under the "do one thing and do it well" mantra--just as long as there aren't claims that the product is trying to be something it isn't. Unfortunately, you refer (in your manifesto) to your compiler as an integrated development environment--which it is not. It provides significantly less functionality than, say, TextPad, which makes no claim to be an IDE, and would face a serious uphill battle to try to argue otherwise. If the lack of functionality is due to it being a work in progress, then (in addition to the question of charging $100 for an incomplete product) you are sure to find the the trade-off between complexity and usability to become more and more strained.
After listing various interface widgets you also tack on several language constructs and structures that your product finds no use for. Among these are objects, nested ifs and nested loops. I refer you to the myriad of procedural languages that live without objects (I assume you're well aware that COBOL tried the "close to natural language" bit in the 60s) and functional languages that eschew straight iteration in favor of recursion.
So, my summarized response to item 1 below is that while your ideas are "worthy of study," they are neither "surprising" nor "worthy of emulation" due to your being about about fifty years late to the party.
With respect to your comment on parsing: natural language processing is one of the most difficult problems facing computer science. Your approach is neither novel nor appropriate for this problem area. One of the inescapable first things one must learn prior to really understanding any science is the idea of ambiguity. Until artificial intelligence surpasses our own intelligence (at which time there will be no need for us to write software anyway), ambiguity will not be correctly tolerated by machines. The fact that your philosophy tries to "brute force" a faked tolerance of ambiguity by pre-programming a preferred interpretation of it is self-defeating in that respect. Natural languages do not need a rigid syntax because people tolerate this ambiguity (with often costly results when the ambiguity is incorrectly resolved) in favor of expressiveness. This feature forms the basis of jokes: amusing variations in parsing the ambiguity of language. What forms jokes in natural language is what forms incorrectness in software. Any effort to overcome this without first disproving Turing's groundwork is naively wasted effort. The goal of more recent prgramming languages is to increase expressiveness while maintaining precise expression; Python and Ruby are making feeble inroads to this end, but almost everyone has their own subjective opinion on which language is most "expressive."
All in all, your language is a trivially amusing esoteric implementation, but it is betrayed by your delusions of grandeur. My unsolicited advice to you is to stop taking yourself so seriously, and you might be taken more seriously. (LOLCODE enjoys a fairly decent mind share in this way.)
In closing, you've demonstrated enough that I am forced to assume you're at least mildly aware of the work that has come before you, but either your literature review was drastically incomplete, or you are willfully ignorant of it. I look forward to your reply to find which of those two fit. -trav
Unfortunately, the Grand Negus turned out to be more meek than patient.
Round 2
Travis,
I'm thinking the gulf between us is too wide to bridge. It is apparent that our journalistic standards, our programming principles, our short- and long-term goals, our way of doing business, and even our sense of humor are all quite foreign to you. It's also quite clear that you're not at all impressed with our "proof of concept" product. So I strongly suspect that pursuing the matter further, especially in this polemic style, will not be fruitful.Thank you for your time and effort.
The Old and Weary Negus of the Osmosian Order of Plain English Programmers
Pity. I would have expected him to have more spirit than that, considering he's had some experience trying to defend his ideas to a tough crowd.
[ home - archives - quoteboard - blogger decoder - wishlist ]
This work is licensed under a
Creative Commons License.