How will the computing landscape evolve as we move towards the next millennium? Clearly the computer architecture will evolve towards a more parallel architecture with multiple CPUs each handling a part of the problem in parallel. However, programming parallel architectures is no simple task and will challenge the greatest minds.
In the future where the problems and the architectures will be extremely complex, the programming language will itself evolve towards simplicity. The programming language will be based on natural language that we use to define problems. Behinds the scenes of the natural language interface will be complex algorithms of Artificial Intelligence which will perform the difficult task of specifying the definition of problem into a high level programming language like C++, Java etc.
The Artificial Intelligence interface will handle the task of creating variables, forming loops and actually defining classes and handling errors. The code generated by the machine will have far less syntactical errors than those created by human beings. However while a large set of problems can be solved by the AI interface there will be a certain class of problems which will still require human intervention and the need to work in the languages of today.
One of the drivers for this natural language of programming of the future, besides the complexity of the computer architecture is the need to bring a larger section of domain experts to solve the problems in their fields without the need to learn all the complex syntax, and semantics of the current programming languages.
This will allow everybody from astrophysicists, geneticists, historians and statisticians to be able to utilize the computer to solve the difficult problems in their domain.
Giga thoughts ... 
Some years ago my elder son and I developed a Plain English programming 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”.
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.
A typical 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.
You can get our development system here: http://www.osmosian.com/cal-3040.zip . It’s a small Windows program, less than a megabyte in size. If you start with the PDF in the “documentation” directory, before you go ten pages you’ll be recompiling the whole shebang in itself (in less than three seconds on a bottom-of-the-line machine from Walmart).
Questions and comments should be addressed to gerry.rzeppa@pobox.com
LikeLike
Hello! Quick question that’s completely off topic. Do you know how to make your site mobile friendly? My weblog looks weird when browsing from my apple iphone. I’m trying to find a
theme or plugin that might be able to fix this problem.
If you have any recommendations, please share. Many thanks!
LikeLike