The era of interchangeable parts

The two big challenges for the next gen computer language are reducing complexity and creating a system where interchangeable parts are usable.  There are many wonderful new languages like Elixir, Julia, Parasail, Go, Rust, Dart, Swift, etc., but... none of those languages actually tackle the 2 big issues of complexity and interchangeable parts. In fact, none of these languages even really tries. They are instead adding features on top of their foundation language, and merely improving a few areas. For example, Parasail does a phenomenal job of making it much easier to utilize parallel processing. But the rest of the language is fairly conventional. None of these languages will likely displace the current leading languages (JavaScript, Python, etc.) because the improvement is insufficient. If something is only 10% better than the existing technology, the pressure to change is very slight.  The mass of developers inevitably coalesce upon a standard that the group as a whole picks. History shows that the programming community as a whole selects the language that generates the most billable hours.  We have seen this before with COBOL, and Java. JavaScript is now #1 in terms of code being written, and as you can see from the diagram from the previous blog post, it requires a bewildering array of tools to make it even tolerable. It is time for JavaScript to die, and so the burning question arises: which of the new languages has the potential to displace JavaScript (and most of the other top 10 languages).

The current candidate languages/systems are:

1) Red,  2) Eve, 3) Elm, 4) GunDB, 5) Beads, 6) a few other languages which are in stealth and haven't shown their hands. Let's look at the first three candidates:

Red ( is an improved version of Rebol. Rebol is a LISP family language that has a much cleaner syntax. In some ways it is reminiscent of Objective-C. The beauty of Red is that you only need a small set of tools, and because each module is its own domain specific language, you can hook up lots of components together. However, the Red language doesn't have a database inside the language, and that means you are inevitably going to have a serious mismatch between the very flexible language and an inflexible database. If you dramatically increase the power of a car's engine, and don't beef up the transmission, the car will burn out the transmission. The database is like the transmission, it has to absorb all the power the engine creates. And this is a central flaw in the in the thinking of Red. If they don't include a database, it can't go much further ahead of the current languages. 

Eve ( is a new database system and language. It has inspiration MySQL, and goes way beyond it with an interesting free-form database based on entity/attribute. It adds a feature which allows code to depend on values in records, and to automatically redraw affected DIV blocks. The developers didn't like the problems variables and loops, so they banished them from the language. But banishing one of the fundamental operations of the underlying CPU never works in the long run. If you don't have variables, then people will put their variables into your database and ruin the purity of your system. The other great limitation in Eve is that they are still presenting to the programmer the HTML drawing model, which is terrible. Since most graphical interactive programs comprise 85% of drawing code (my own experience), if you don't fix the lousy graphical model of HTML you can't really fix programming. Eve is still in constant flux, and i expect they will backpedal and fix these problems due to user demand.

Elm ( is a very interesting language. It was inspired by Haskell, but is a much more pragmatic approach. Elm has a very simplified graphical model, and of these entries has the most evolved toolchain. It does however present some difficult abstractions to the beginning, and is not that easy to read for a beginning, as you must have a tremendous memory to remember how many arguments each function needs. By eliminating the parentheses that LISP used, you then rely on the programmer's memory. Evan the author has a prodigious memory, and i suspect that people will find it a little difficult to learn. It doesn't really have a database system.

Gun DB ( was designed as a graph database, but is evolving a general purpose language. Out of the box it offers an offline-first database that can sync with other peers. This feature alone makes what is a very tricky thing program pretty easy. Graph databases are the ultimate in flexibility. Currently the best graph database implementation is Neo4J, however, Neo4J has gotten sidetracked into connecting their system to older databases, and is burning up their development staff on a hopeless quest for compatibility which can never be achieved with the big database vendors. The Neo4J Cypher language is very weak, and you can't build programs in it. GunDB has not implemented the relationships part of Neo4J (its most interesting aspect), but it is a lot of fun, and the pragmatism of the author would indicate it will evolve into a useful thing.

We will talk about Beads in another post. It combines a graph database, with a simplified drawing model, all based on a declarative + deductive language that has a robust mathematical foundation.

One of the things that is built into Excel that is not present in any other language than Beads is the property of mathematical closure in the underlying arithmetic. If you divide by zero, what happens? If you multiply by an undefined variable what happens? If you take the square root of a negative number, and then multiply that by 2 what do you get? many of these languages don't have a precise definition of what happens, and this leads to program errors. The protected arithmetic of Excel is one of the main reasons the amateur programmers of the world, which number in the hundreds of millions, don't venture into conventional languages, which don't protect the user.