The programming language of the future

New features which will facilitate development for the Web, mobiles or robotics.

In recent years we have seen popularized certain features in programming tools, including concurrency and asynchronous mode. Functions that accompany the transition from local application to the universal application, online or locally.

But it is far from sufficient for the final achievement in the evolution of programming. We need new features in languages, but which ones?

Tolerance in the code

No current language is really suited to robotics because of their formal nature. Any missing comma and the program fails. This may be appropriate for current applications, although it may be in doubt when you know that Ariane rocket exploded in flight due to a simple division by zero, but this is totally unacceptable for robotics.

On the contrary HTML is tolerant: a tag which is not closed and the rendering engine infers the missing part. If a tag is not recognized, it is simply ignored. This greatly facilitates the task of Web developers and this helped to popularize HTML.
Languages ​​and compilers of the future should be tolerant, and it is indispensable for robotics to allow some learning. The interpreter must be able to make inferences and provide himself the code needed to complete a task.

The service as a module

In a new environment where you can not define what is local and what is remote, because local applications using remote services and online applications can run locally, we should redesign modules and libraries and give them the form of a service.

A service is less strict in communicating with an application than a library. It can be used directly with applications written in different languages. The principle of tolerance also extends to services. The service responds to what is included and ignores what it does not understand or try to supplement it according to what he has.

Language for tools

Language Dart, a ultra-classic language designed to enable veterans to program web applications without having to change their habits acquired in the office during the previous decades pretend to come up with tools to facilitate programming. The language itself facilitates the creation of these development tools.
Classical languages ​​can already produce a debug version that contains meta-information to monitor the progress of a program and locate errors. We must go further.
We must not only make tools for languages ​​but also languages ​​for tools.
The most useful is in fact synchronization between on the one hand the view of the program in progress and on the other hand the view of the source code. It is not just putting breakpoints and watch the contents of variables at each stop, but instead let the program executed in slow motion while you can view the source code in another window.
This assumes that the interpreter displays each source instruction before executing but also that we can interact with it, "fold" part of the program that we want to ignore or "extend" part that we want to see. The interpreter responds to events from an interface and adapts its behavior, this ability will grow with suggestions on the code, which means that the interpreter can infer the objectives of each part of the program. It should also propose alternatives to the code. The development tool should be interactive and intelligent and this implies that the language incorporates notions of its objectives.

Code visualization while running

While some languages ​​try to produce the most compact code to write and so allow a little less typing on the keyboard, writing the code is a tiny part compared to the design time and especially the debugging time.

Debugging is the weak point of programming: how to find the statement that produced the fault that we see among a few thousand lines of code? Everything would be so much simpler if we could see the code that runs in the same time as the result of executing.

No tool can add this functionality, to set breakpoints is an poor alternative, actually this function should be built into the language itself and its compiler.
When the compiler produces the object code, it should add calls to a function that contains a representation of the source code, which could then appear during execution.
Better yet, we could be abble to modify the source code and resume the execution ...

Auto correction

The ability of a program to correct its own errors is not something new. This had been included in the Apollo 11 program, which for the first time allowed men to walk on the moon in 1969, and it was a wise precaution because the program became frightened and became erratic during the mission. But thanks to its ability to correct itself, the mission was able to continue normally.

Self-correction must be added by additional routines for now, which is why programs almost never have this possibility. A program error caused the explosion of an Ariane 5 rocket in 1996 (cost: $ 500 million).
The language should have self-correcting objects based on constraints to avoid bad behavior due to bugs in the code.

Author: Denis Sureau, creator of the Scriptol language.
March 30, 2013. Last updated February 12, 2017.

Note: I'm talking about interpreters and no compilers, but with JIT and AOT as Asm.js, the difference tends to disappear.