Язык программирования будущего

Новые функции, которые облегчат разработку для Сети, мобильных устройств или робототехники.

В последние годы наблюдается популяризация некоторых особенностей в инструментах программирования, в том числе конкуренции и асинхронного режима. Функции, которые сопровождают переход от локального приложения к универсальному, сетевому или локальному.

Но этого далеко не достаточно, чтобы обеспечить окончательное достижение в развитии программирования. Нужны новые характеристики для языков, но какие?

Допуск в коде

Ни один из нынешних языков не подходит для робототехники из-за их формального характера. Отсутствует малейшая запятая, и программа не работает. Возможно, это подходит для нынешних приложений, хотя можно и догадаться, когда ты знаешь, что ракета Ariane взорвалась в полете в результате простого деления на ноль, но это совершенно неприемлемо для робототехники.

Наоборот, язык HTML терпим: незакрытый тег и движок рендеринга доходит до недостающей части. Если он не узнает тег, он просто игнорирует его. Это значительно облегчило задачу веб-разработчиков и позволило популяризировать HTML. Языки и составители будущего должны быть толерантными, и это даже необходимо для робототехники, чтобы дать возможность определённого обучения. Интерпретатор должен уметь делать выводы и сам предоставлять код, необходимый для выполнения задачи .

Служба как модуль

В новой среде, где невозможно определить, что является локальным, а что удаленным, поскольку локальные приложения используют удаленные службы, а онлайн-приложения могут работать локально, следует пересмотреть дизайн модулей и библиотек и придать им форму службы.

Сервис менее строгий в интерфейсе с приложением, чем книжный магазин. Его можно использовать непосредственно с приложениями, написанными на разных языках. Принцип терпимости распространяется и на услуги. Служба отвечает на то, что понимает, и игнорирует то, что не понимает, или пытается заменить его в зависимости от того, что есть в ее распоряжении.

Язык для инструментов

Язык Dart, ультра-классический язык, созданный для того, чтобы ветераны могли программировать веб-приложения без необходимости менять привычки, приобретенные на рабочем столе в предыдущие десятилетия, к притворству придумывать инструменты, облегчающие программирование. Сам язык облегчает создание этих инструментов разработки.
Классические языки уже могут создавать версию отладки, которая содержит мета-информацию, позволяющую отслеживать ход программы и находить ошибки. Это должно идти дальше.
Нужно делать не только инструменты для языков, но и языки для инструментов.
На самом деле наиболее полезной является синхронизация между видом текущей программы и видом исходного кода. Речь идет не только о том, чтобы ставить точки остановки и смотреть на содержимое переменных во время каждой остановки, но и о том, чтобы позволить программе работать в замедленном режиме, имея возможность увидеть соответствующий исходный код в другом окне.
Это предполагает, что переводчик будет показывать каждую инструкцию источника перед его выполнением, а также что он может взаимодействовать с ним, «складывать» часть программы, которую вы хотите пройти, или «расширять» часть, которую вы хотите видеть. Интерпретатор реагирует на события из интерфейса и умеет адаптировать свое поведение, эта способность будет развиваться с предложениями по коду, что предполагает, что интерпретатор может определить цели каждой части программы. Ему также следует предложить альтернативы кодексу. Инструмент развития должен быть интерактивным и умным, и это предполагает, что язык включает понятия о его целях.

Просмотр запущенного кода

Даже если некоторые языки пытаются сделать код более компактным для написания и, таким образом, позволить печатать на клавиатуре чуть меньше, доля написания программы ничтожна по сравнению со временем проектирования и особенно со временем отладки.

Отладка - слабое место программирования: как найти инструкцию, создающую дефект, который мы видим в нескольких тысячах строк кода? Все стало бы намного проще, если бы можно было увидеть код, который выполняется одновременно с результатом выполнения.

Ни один инструмент не может добавить эту функцию, размещение точек остановки является альтернативой, но эта функция должна быть построена на языке и его компиляторе.
Компилятор при создании кода объекта должен добавлять вызовы к функции, содержащей представление исходного кода, которое может отображаться во время выполнения.
Что еще лучше, мы должны иметь возможность изменить исходный код и возобновить выполнение...

Авто-исправление

Способность программы исправлять свои ошибки сама по себе не является чем-то новым. Это было включено в программу «Аполлон-11», которая впервые позволила людям ходить по Луне в 1969 году, и это было мудрой осторожностью, так как во время миссии программа спала и стала беспорядочной, но благодаря своей способности исправляться миссия смогла нормально продолжаться.

Самокоррекцию должны добавить дополнительные процедуры в настоящее время, поэтому у программ такой возможности почти никогда не бывает. Ошибка в коде стала причиной взрыва ракеты Ariane 5 в 1996 году (стоимость: $500 млн!).
Язык должен иметь саморегулирующиеся объекты, основанные на ограничениях, чтобы избежать вредного поведения из-за ошибок в коде.

Автор: Денис Суро, создатель языка Script .
30 марта 2013 года. Обновлено 12 февраля 2017 года.

Примечание: Я говорю о интерпретаторах и не о компиляторах, но с JIT и AOT, такими как Asm.js, разница, как правило, исчезает .