Семантический редактор

Почему мы в 21-м веке программируем как в эпоху перфокарт?

Следующий сценарий знаком наверное большинству программистов: после внесения незначительных правок кода в вашем текстовом редакторе или любимом фреймворке компилятор внезапно выдаёт десятки или даже сотни непонятных ошибок компиляции. Даже если вы привыкли к подобным вещам, в этом есть что-то слегка деморализующее. Мне очень не нравится искать в таких случаях главную причину — компилятор совершенно не даёт мне подсказок по поводу причины этой кучи вроде бы несвязанных ошибок. Компиляторы вообще довольно плохо описывают основную причину фактических ошибок.

Этот базовый, фундаментальный рабочий процесс (вносить изменения в код, передавать его компилятору и интерпретировать любые ошибки, которые возникают) остаётся по сути неизменным со времен перфокарт. Вот еще одно доказательство этого: мы начинаем работу с совершенно неограниченного ввода в файл исходного текста. Затем мы отправляем этот необработанный текст компилятору, который «анализирует» его, а затем выполняет тайпчекинг. Конечно, большинство сырых строк такого первичного кода обычно не получаются сразу корректными — они даже не анализируются, не говоря уже о проверке типов! Таким образом, на протяжении десятков лет компиляторы и редакторы становятся всё более изощренными для, по сути, представления пользователю формальной «отчетности» о том, где и как пользователь сделал что-то не так в этом сыром тексте, ничем не ограниченном. Современные IDE ужесточили этот цикл, но базовая модель осталась такой же!

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

Например, я хочу вызвать функцию foo(), которая принимает на вход целое число, и когда я ввожу её аргумент, семантический редактор каким-то образом мешает мне ввести строку «привет!». Такое ограничение предъявляет к пользовательскому интерфейсу ряд дополнительных требований:

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

— если пользователь вводит что-то лишнее/недопустимое (например, строку «привет!» в foo), редактор должен сформировать некоторую обратную связь. Например, в поле автозаполнения покажется тип аргумента Number, а строка «привет!» подсветится серым «невыбираемым» цветом с указанием типа String;
— если пользователь не может произвольно поставить курсор в любую точку кода и начать вводить текст, как тогда правильно перемещаться по программе и выполнять хорошо форматированные и хорошо типизированные изменения?
— стандартное редактирование текстового кода даёт нам ощущение контроля. Однако при этом можно легко временно «сломать» структуру кода, а исправить его позже. В семантическом редакторе мы не хотим, чтобы пользователь попадал в такое «заторможенное» состояние, из которого никуда нельзя двигаться — поэтому наш UI должен быть сильно ограничен.

вторая часть

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *