Programming language of the future

New features that will facilitate development for the Web, mobile devices or robotics.

In recent years, there has been a popularization of some features in programming tools, including competition and asynchronous mode. Features that accompany the transition from a local application to a universal, network, or local application.

But this is far from enough to ensure the final achievement in the development of programming. We need new characteristics for languages, but which ones?

Tolerance in code

None of the current languages are suitable for robotics due to their formal nature. The slightest comma is missing and the program is not working. Perhaps this is suitable for current applications, although you can guess when you know that the Ariane rocket exploded in flight as a result of a simple division by zero, but this is completely unacceptable for robotics.

On the contrary, the HTML language is tolerable: the open tag and the rendering engine reach the missing part. If he doesn't recognize the tag, he just ignores it. This greatly facilitated the task of web developers and made it possible to popularize HTML. Languages ​ ​ and compilers of the future must be tolerant, and this is even necessary for robotics to enable certain training. The interpreter must be able to draw conclusions and provide the code necessary to complete the task.

Service as module

In a new environment where it is impossible to determine what is local and what is remote, since local applications use remote services, and online applications can work locally, you should revise the design of modules and libraries and give them the form of a service.

The service is less strict in the interface with the application than the bookstore. It can be used directly with applications written in different languages. The principle of tolerance extends to services. The service responds to what it understands and ignores what it does not understand, or tries to replace it depending on what is at its disposal.

Language for tools

Dart language, an ultra-classical language designed to allow veterans to program web applications without having to change the habits acquired on the desktop in previous decades, to the pretense of coming up with tools that facilitate programming. The language itself facilitates the creation of these development tools.
Classic languages ​ ​ can already create a debug version that contains meta information that allows you to track the progress of the program and find errors. This should go further.
You need to make not only tools for languages, but also languages ​ ​ for tools.
In fact, the most useful is synchronization between the type of the current program and the type of source code. This is not only about putting stop points and looking at the contents of the variables during each stop, but also about allowing the program to run in slow motion, being able to see the corresponding source code in a different window.
This assumes that the translator will show each source instruction before executing it, and also that he can interact with it, "add" the part of the program that you want to go through, or "expand" the part that you want to see. The interpreter reacts to events from the interface and is able to adapt its behavior, this ability will develop with code suggestions, which suggests that the interpreter can determine the goals of each part of the program. It should also offer alternatives to the code. The development tool must be interactive and smart, and this assumes that the language includes concepts about its goals.

View running code

Even if some languages ​ ​ are trying to make the code more compact for writing and thus allow typing on the keyboard a little less, the proportion of writing a program is negligible compared to the design time and especially with debugging time.

Debugging is a programming weakness: how do you find an instruction that creates a defect that we see in several thousand lines of code? Things would become much easier if you could see code that runs at the same time as the execution result.

No tool can add this feature, stopping point placement is an alternative, but this feature must be built on the language and its compiler.
When generating object code, the compiler must add calls to a function that contains a representation of the source code that can be displayed at run time.
Better yet, we should be able to change the source code and resume execution...

Auto-correction

The program's ability to correct its mistakes is nothing new in itself. This was incorporated into the Apollo 11 program, which first allowed humans to walk on the moon in 1969, and it was a wise caution, as during the mission the program slept and became erratic, but due to its ability to correct, the mission was able to continue normally.

Self-correction should add additional procedures at the present time, so programs almost never have this opportunity. An error in the code caused the Ariane 5 rocket to explode in 1996 (cost: $500 million!).
The language must have self-regulating constraint-based objects to avoid harmful behavior due to errors in the code.

Author: Denis Suro, creator of the Script language.
March 30, 2013. Updated February 12, 2017.

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