Здравствуйте! Начну статью с небольшого отступления. Не посетило ли вас разочарование когда вы впервые столкнулись с программированием? Я предполагал что создание программ происходит путём взаимодействия с каким-то сложным, но очень интересным инструментом, в котором я смогу заниматься своим любимым делом (собирать конструкторы) на новом уровне. Однако, вместо этого мне пришлось изучать как писать текстовые файлы состоящие из различных операторов, скобок, строк и прочих текстовых конструкций. Прошли десятилетия, я научился программировать, и уж было позабыл про это разочарование, однако увидев в сети новость про Google Blockly и Scratch я почувствовал ностальгию…
Эти инструменты, даже не претендуя на профессионализм, так интересны! Никаких текстов и компиляций — таскаешь блоки и мгновенно получаешь результат. Можно ли сделать так для профессионалов? Уверен, что можно! И в этой статье я хотел бы выразить своё видение того как.
В чём суть?
Если мы уходим от тестового способа написания программ, нам необходимо разделить структуру кода программы и его вид…
Как это?
Для этого в первую очередь нам потребуется хранить исходные коды в другой форме. Они должны представлять собой описание инструкций и данных программы в одной из существующих форм хранения данных, таких как json, xml или любой другой. Этот файл (рисунок 1, слева) может иметь довольно безобразный вид и не поддаваться хоть сколько-нибудь разумному способу его прямого редактирования, однако в среде программирования он будет превращаться в блочный код (рисунок 1, справа).
Сама же среда программирования имеет дело не с текстовыми кодами, а с «блоками», из которых строится код программы.
Что нам это даст?
1. Во-первых, мы избавимся от несущественных отличий в синтаксисе различных языков. Например, блоки кода в С++ разделяются фигурными скобками, а Ruby обращает внимание на ключевые слова… В редакторе можно настроить и тот и другой вид программы, от этого не поменяется ничего в ней самой. Персональные настройки отображения позволят разработчику смотреть на программу так, как ему нравится. Кроме того, мы сможем использовать любые символы при именовании, включая пробелы.
2. Во-вторых, увеличится скорость написания программы. Сейчас для того, чтобы написать оператор for в С-подобном языке нам нужно написать сам текст for, затем скобки, параметры, точки с запятыми, фигурные скобки, и нажать клавишу ввод. В нашем же варианте среда программирования по нажатию на определенное сочетание клавиш вставит цикл и потребует только ввести его параметры. Например, по нажатию на «f» поставит на место курсора цикл for и предложит ввести количество повторений и название счётчика через табуляцию, нажав клавишу ввод в конце.
3. В-третьих, можно будет обеспечить независимость от языка программиста. Операторы языка могут обозначаться некоторыми символами или же ключевые слова могут отображаться на родном языке программиста. Если он хочет чтобы операторы назывались по-английски, по-русски или на любом другом языке, он выбирает этот язык в настройках редактора и названия операторов меняются «на лету». Насчёт имён объектов и методов посложнее, но в любом случае, если программа разрабатывается русскими разработчиками, то и именовать всё можно по-русски — в случае выбора этого сценария не будет никакого несоответствия между названиями операторов и названиями объектов и методов — всё будет на русском. Это может упростить обучение для школьников и взрослых, незнакомых с английским языком. Да и к тому же в многонациональных командах есть возможность использовать для именования объектов и методов два названия — на английском и на языке разработчика.
4. В-четвертых появится возможность обновления структуры программы. Если в новой версии стандарта появится какая-то новая возможность изменяющая вид блочных конструкций, можно будет выпускать патчи для старых программ, которые автоматически приведут их в новый вид. На рисунке 4 можно увидеть, какие старые конструкции языка могут преобразовываться средой программирования к новому виду.
5. В-пятых представлять структуру программы можно будет любым удобным для того способом. Например, в виде трехмерной комнаты, по которой можно перемещаться наподобие компьютерных игр и редактировать связи трехмерных классов и объектов.
Среда программирования
Такой способ представления программы уже не позволит менять её в простом текстовом редакторе. Для редактирования программы понадобится особая среда программирования. Разработать первую версию этой среды программирования сложнее чем для традиционных языков, но есть способы начать попроще. Например, можно начать с редактора файлов данных, позволяющего редактировать файлы любых форматов (xml, json, yaml и т. д.) одним и тем же способом — с помощью блоков. В этом случае пользователь будет избавлен от необходимости изучать синтаксис этих файлов и сможет редактировать любой из них научившись редактировать файлы данных лишь в этой программе.
Затем встанет задача разработки компилятора, способного «налету» строить программу во время её редактирования. А в будущем обеспечить функциональность автодополнения и добавлять в среду разработки функции, требующие «глубокого» знания кода программы будет легче, так как не придётся разбирать текстовые коды. Кроме того, среда программирования будет «знать» всё, что нужно о программе для лучшей подсветки синтаксиса и рефакторинга, так как все нужные для этого данные можно хранить невидимо для самого программиста в файле данных программы.
Заключение
Я уверен, что описанный способ программирования откроет огромные возможности для программистов и в значительной степени ускорит и упростит разработку приложений. Однако один в поле не воин. Разработка подобного продукта требует могучего подхода и ресурсов. Я одиночка и работаю удалённо — мне этот проект не по зубам… Возможно, если вы заинтересовались им, мы могли бы поработать вместе?
Автор: Сухоруков Иван
