Блочное программирование

Здравствуйте! Начну статью с небольшого отступления. Не посетило ли вас разочарование когда вы впервые столкнулись с программированием? Я предполагал что создание программ происходит путём взаимодействия с каким-то сложным, но очень интересным инструментом, в котором я смогу заниматься своим любимым делом (собирать конструкторы) на новом уровне. Однако, вместо этого мне пришлось изучать как писать текстовые файлы состоящие из различных операторов, скобок, строк и прочих текстовых конструкций. Прошли десятилетия, я научился программировать, и уж было позабыл про это разочарование, однако увидев в сети новость про Google Blockly и Scratch я почувствовал ностальгию…

Эти инструменты даже не претендуя на профессионализм так интересны! Никаких текстов и компиляций — таскаешь блоки и мгновенно получаешь результат. Можно ли сделать так для профессионалов? Уверен, что можно! И в этой статье я хотел бы выразить своё видение того как.

Если мы уходим от тестового способа написания программ, нам необходимо разделить структуру кода программы и его вид…

Для этого в первую очередь нам потребуется хранить исходные коды в другой форме. Они должны представлять собой описание инструкций и данных программы в одной из существующих форм хранения данных, таких как json, xml или любой другой. Этот файл (рисунок 1, сверху) может иметь довольно безобразный вид и не поддаваться хоть сколько-нибудь разумному способу его прямого редактирования, однако в среде программирования он будет превращаться в блочный код (рисунок 1, снизу).

Рисунок 1. Содержимое файла исходных кодов (сверху) и отображение этого кода в среде программирования (снизу)

Сама же среда программирования имеет дело не с текстовыми кодами, а с «блоками», из которых строится код программы.

1. Во-первых мы избавимся от несущественных отличий в синтаксисе различных языков. Например, блоки кода в С++ разделяются фигурными скобками, а Ruby обращает внимание на ключевые слова… В редакторе можно настроить и тот и другой вид программы, от этого не поменяется ничего в ней самой. Персональные настройки отображения позволят разработчику смотреть на программу так, как ему нравится. Кроме того, мы сможем использовать любые символы при именовании, включая пробелы.

Рисунок 2. Один и тот же отрывок кода с разным форматированием.

2. Во-вторых увеличится скорость написания программы. Сейчас для того, чтобы написать оператор for в С-подобном языке нам нужно написать сам текст for, затем скобки, параметры, точки с запятыми, фигурные скобки, и нажать клавишу ввод. В нашем же варианте среда программирования по нажатию на определенное сочетание клавиш вставит цикл и потребует только ввести его параметры. Например, по нажатию на «f» поставит на место курсора цикл for и предложит ввести количество повторений и название счётчика через табуляцию, нажав клавишу ввод в конце.

3. В-третьих можно будет обеспечить независимость от языка программиста. Операторы языка могут обозначаться некоторыми символами или же ключевые слова могут отображаться на родном языке программиста. Если он хочет чтобы операторы назывались по-английски, по-русски или на любом другом языке, он выбирает этот язык в настройках редактора и названия операторов меняются «на лету». Насчёт имён объектов и методов посложнее, но в любом случае, если программа разрабатывается русскими разработчиками, то и именовать всё можно по-русски — в случае выбора этого сценария не будет никакого несоответствия между названиями операторов и названиями объектов и методов — всё будет на русском. Это может упростить обучение для школьников и взрослых, незнакомых с английским языком. Да и к тому же в многонациональных командах есть возможность использовать для именования объектов и методов два названия — на английском и на языке разработчика.

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

Рисунок 4. Автоматическое преобразование старой конструкций языка в лямбда-функцию.

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

Такой способ представления программы уже не позволит менять её в простом текстовом редакторе. Для редактирования программы понадобится особая среда программирования. Разработать первую версию этой среды программирования сложнее чем для традиционных языков, но есть способы начать попроще. Например, можно начать с редактора файлов данных, позволяющего редактировать файлы любых форматов (xml, json, yaml и т. д.) одним и тем же способом — с помощью блоков. В этом случае пользователь будет избавлен от необходимости изучать синтаксис этих файлов и сможет редактировать любой из них научившись редактировать файлы данных лишь в этой программе.

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

Я уверен, что описанный способ программирования откроет огромные возможности для программистов и в значительной степени ускорит и упростит разработку приложений. Однако один в поле не воин. Разработка подобного продукта требует могучего подхода и ресурсов. Я одиночка и работаю удалённо — мне этот проект не по зубам… Возможно, если вы заинтересовались им, мы могли бы поработать вместе?