Future Programming Languages

Khun Yee Fung, Ph.D.
4 min readAug 18, 2020

--

Part I. Something similar, something new

I studied computer science about 10 years after Knuth’s papers about parsing were published. In other words, the perfect time, if there is such a thing.

Because of his contribution, parsing became something that can be largely automated. And obviously, tons of languages came out right after that. Of course, programming languages were already coming out in large number since mid 1960’s. But after those papers, it was like a torrent.

Over the years, the really interesting programming languages are FORTRAN, COBOL, APL, LISP, ALGOL, SNOBOL, and PROLOG. Any other language we can argue is the descendent of one or more of these languages. Some of these languages are more or less one off. APL, for instance, only had one descendent. SNOBOL has ICON. PROLOG has some variants. COBOL has PL/I sort of as its descendent. But not really. FORTRAN also has simple lineage as well.

ALGOL has tons of descendants. Pascal. C. C++. Java. Etc., etc. Variants, like SIMULA 67, Algol 68. Perl.

Lisp has tons of descendants, both in spirit and also in different variations. Scheme is the major one. But a lot of functional constructs in a language like Java, also come from Lisp. More or less. In spirit, perhaps.

I am well aware of the differences of these languages. But they do seem to belong to families.

All of them, except perhaps PROLOG (without the cut), are sort of procedural to some degree. I define procedural as having explicit or implicit order of execution of statements, functions, or whatever is the unit of instructions in a language.

Other than these languages, however, we also have SQL. It is hard to classify SQL, as it is really not a programming language. But to query a relational database, it is still the best there is. The pure form of PROLOG is close to SQL, but with the cut, it becomes something different.

From the new programming languages designed in recent years, it seems we will continue to change incrementally the procedural idea. I probably am ignorant of many new programming languages, but I don’t seem to have an impression of a new language that is like SQL, non-procedural.

What is special about SQL?

Well, when you have a SQL query, you can’t specify how it should be executed. Instead, you specify what you want to have as the result of the query. And how the query is actually performed is really up to the query engine. I know many database management systems do allow the programmer to provide hints, so as to tell the query engine perhaps the intention of the query. I personally think that is extraneous; making SQL richer is perhaps the better avenue.

To “run” a SQL query, the query engine parses the text, comes up with a execution plan, converts the plan into steps, and executes the steps.

SQL is not procedural in that sense, even though the execution might be, after the execution plan has been mapped out.

So what?

Well, in my opinion, a lot of natural processes are also like that, not procedural. Specifically, I believe the human thinking process to be like that. The thinking process itself is not procedural. We can make it procedural, with paper and pencil, etc., to do things in steps. But we mostly set the result first and then do whatever is necessary to get that result. Order is usually not strictly prescribed.

For instance, eating a hamburger is not a process we do step by step, pre-determined before we start eating. True, we might have some rituals on how we eat a hamburger. Perhaps we always pull out the pickles first, so that they are eaten last. Perhaps we pat down the burger first, and eat it upside down. All true, but the actions in between these rituals are still not pre-determined step by step. And they are usually ordered according what is going on at each exact moment, with us not necessarily even conscious of the actions.

None of the procedural languages can do something as simple as that in that way. We will have to fix the steps. We add in condition checking to make sure we handle all the possible events that can happen during the burger eating exercise. If we miss one, well, that is an exception thrown, IllegalEventException. Core dump.

So, something like SQL will handle that? Well, not exactly. SQL is too declarative. Also, the database is where the variations happen, not the SQL queries.

One of the future programming languages, in my opinion, is like SQL. But the database and the query language is one. Data and queries are one and the same. But isn’t that like the old joke about Lisp being self-modifying. Well, no, not the “program” self-modifying, but rather the “execution plan” changes according to the data.

Instead of querying a database, this programming language, if we can call it that, will allow us to write programs that collectively can do something like eating a hamburger.

Mind you, not being procedural does not mean there can’t be some general order of how things should be done. Just that it does not follow fixed and rigid steps previously determined.

Okay, time to end this part. See you in the next part.

--

--

Khun Yee Fung, Ph.D.

I am a computer programmer. Programming is a hobby and also part of my job as a CTO. I have been doing it for more than 40 years now.