(Open Minded) Linux Programmer Wanted
BACKGROUND
Some years ago my elder son and I developed a Plain English programming language and development system in the interest of answering the following questions: 1. Can low-level programs (like compilers) be conveniently and efficiently written in high level languages (like English)? 2. Can natural languages be parsed in a relatively "sloppy" manner and still provide a stable enough environment for productive programming? 3. Is it easier to program when you don't have to translate your natural-language thoughts into an alternate syntax? We can now answer each of these three questions, from direct experience, with a resounding "Yes". PRINCIPLES OF OPERATION Our parser operates, we think, something like the human brain. Consider. A father says to his baby son: "Want to suck on this bottle, little guy?" And the kid hears, "blah, blah, SUCK, blah, blah, BOTTLE, blah, blah." But he properly responds because he's got a "picture" of a bottle in the right side of his head connected to the word "bottle" on the left side, and a pre-existing "skill" near the back of his neck connected to the term "suck". In other words, the kid matches what he can with the pictures (types) and skills (routines) he's accumulated, and simply disregards the rest. Our compiler does very much the same thing, with new pictures (types) and skills (routines) being defined -- not by us, but -- by the programmer, as he writes new application code. SAMPLE CODE A typical Plain English type definition looks like this: A polygon is a thing with some vertices. Internally, the name "polygon" is now associated with a type of dynamically-allocated structure that contains a doubly-linked list of vertices. "Vertex" is defined elsewhere (before or after this definition) in a similar fashion; the plural is automatically understood. A typical routine looks like this: To append an x coord and a y coord to a polygon: Create a vertex given the x and the y. Append the vertex to the polygon's vertices. Note that formal names (proper nouns) are not required for parameters and variables. This, we believe, is a major insight. My real-world chair and table are never (in normal conversation) called "c" or "myTable" -- I refer to them simply as "the chair" and "the table". Likewise here: "the vertex" and "the polygon" are the natural names for such things. Note also that spaces are allowed in routine and variable "names" (like "x coord"). This is the 21st century, yes? And that "nicknames" are also allowed (such as "x" for "x coord"). And that possessives ("polygon's vertices") are used in a very natural way to reference "fields" within "records". Note, as well, that the word "given" could have been "using" or "with" or any other equivalent since our sloppy parsing focuses on the pictures (types) and skills (routines) needed for understanding, and ignores, as much as possible, the rest. At the lowest level, things look like this: To add a number to another number: Intel $8B85080000008B008B9D0C0000000103. Note that in this case we have both the highest and lowest of languages -- English and machine code (albeit in hexadecimal) -- in a single routine. The insight here is that (like a typical math book) a program should be written primarily in a natural language, with appropriate snippets in more convenient syntaxes as (and only as) required. THE TASK AT HAND I'm looking for an (open minded) Linux programmer to convert this program to run on Linux. The program consists of about 20,000 lines of Plain English source code and includes a unique interface (that will look exactly the same on Linux as it does on Windows), a simplified file system viewer, an elegant text editor, a hexadecimal dumper, a native-code-generating compiler/linker, and the wysiwyg page layout facility that was used to produce the documentation. Most of the code (for example, the wysiwyg page layout facility) will not have to change; the system-specific portions of the program are isolated. You can get the whole shebang, including the source code, here: www.osmosian.com/cal-3040.zip . Start with the PDF in the "documentation" directory and before you go ten pages you'll be recompiling it in itself (in less than 3 seconds on a bottom-of-the-line Windows machine from Walmart). Interested parties please respond directly to gerry.rzeppa@pobox.com Thanks! |
To the OP: are you serious ? Have you ever heard of structural ambiguity in human languages ?
Explain to me the meaning of "metal bird cage" for starters. |
Quote:
Yes, I've heard of structural (and many other kinds of) ambiguity in human languages. The question we wanted to answer is whether such ambiguities pose a practical problem in systems such as ours. The answer -- and I'm speaking from first-hand experience here -- is "Nope". Our compiler was easy to write (except, of course, for all the Windows and Intel crap) and is remarkably reliable. The meaning of "metal bird cage" in our system would depend on how the application programmer defined the type, and the routines that manipulate it. There's a story of how Henry Ford asked one of his engineers to figure out how much gasoline an oddly-shaped fuel tank would hold. While the engineer was struggling with his calculations, Henry filled the tank with water and poured the contents into a graduated cylinder. After reading off the correct answer, he fired the engineer. The moral, which I'm sure you've guessed, is that sometimes complex problems can be turned into trivial ones simply by taking a different approach. |
Quote:
Quote:
And regarding "metal bird cage" - way back in the USSR years, in Lithuania, I once saw in a pedestrian street trees - so far so good. One of the tress was killed by fire - probably vandals, but it's not the point. The authorities decided to keep the tree in place, among still alive ones. But you know, birds sometimes "land" on trees, this is how the things are. But birds prefer alive/livings trees. So the authorities solved that problem too - they installed metal birds on the branches of that dead tree. Quote:
Rather, there is a frontend for your new language, the frontend produces some intermediate representation, and that representation undergoes optimizations and is finally converted into assembly or machine code directly. Or, say, into "C" or C++. In your shoes I would use LLVM infrastructure. |
In my experience it is very important to define which chair is being talked about. There's usually a long description about how the chair is or where it is. I think it would be easier to label the chair.
I notice that on many farms the livestock are not called "cow" but are either numbered or named. I also tend to find that, for example, handling of modular arithmetic is difficult to define in terms that make it easy to convey in English terms. Similar goes for type conversion and signed numbers. |
Quote:
Quote:
It seems that you're greatly misunderstanding both our intent and our prototype. And it doesn't sound like you're contemplating the conversion to LINUX. So I bid you farewell; you may have the last word if you please. |
Quote:
I'd be willing to bet that most of the posts in this thread are not correct English and that all are open to misinterpretation. Which table? How will you ensure that your implementation of set works correctly? |
Quote:
Quote:
Quote:
Put sqrt(a^^2+b^^2) into the length. Again, nice to have a choice. And note that it's much easier to extend a language like ours to include snippets of specialized syntax, than it is to extend specialized languages to include an all-emcompassing natural-language wrapper above them. |
Quote:
Quote:
The question is, Do any of you folks want to take a shot at making the thing run on LINUX? |
There is not choice. When I refer to "The chair with the cat hair on it.. No... The one with the black hair on it..." I'm using a key attribute which is unique to that chair. All databases work like this -- you *can* use something that's not the key attribute to find something but it can, and will, fail spectacularly if you rely upon it.
The same follows for the rest. I think mathematics ought to be written in mathematics. I'm not very good at it but I've never seen it expressed in "natural language" properly. It's not by accident that mathematics uses something other than natural language -- it has been around for a while... |
Quote:
My "metal bird cage" is a grammatically correct English example. Exactly because I know limitations of human languages I would not like to use a compiler that understands English. Regarding your code. If people think cross-platform, they write code in a cross-platform manner from the getgo, using a cross-platform toolkit like Qt or wxWidgets. The mere fact that you have an issue of porting your GUI part to other platforms suggests poor architectural thinking. Quote:
... All in all, what problems are you trying to solve with your language and compiler ? Language design in general is a tough problem, but, luckily, it's a mature area of knowledge. So, is your new language just a kind of syntax sugar, or it also resolves in yet unknown way some language design problems ? Are you aware of, say, https://en.wikipedia.org/wiki/Camlp4 and http://people.csail.mit.edu/mikelin/ocaml+twt/ (no, I don't like Python, but it's a good example of what can be done to an existing language regarding syntax sugar - if one of your goals is syntax sugar). |
Quote:
How about the amusing (to me) "I could care less."? I think I asked about how you set set to set a set to work without problems confusing it with set or set? |
Quote:
|
Quote:
|
Quote:
The fundamental issue is: "testing never shows absence of bugs, it can only show their presence". OTOH, there is a hing called "formal verification", sometimes also called "static verification". So, what verification methodology and tools did you use to prove that your program works ? |
All times are GMT -5. The time now is 05:31 PM. |