Проект: Среда программирования без исходного кода

Автор этого ТЗ и эскиза: Сергей Прохоренко   Об авторе

English translation of this website

Статья "Почему мы пишем и храним код в текстовых файлах?"

Частичное воплощение в "Семантическом редакторе" Лаптева и Грачева

Валерий Лаптев

Semantic IDE

Видео (старое) прототипа "семантического редактора"

Свежий скриншот "семантического редактора"

Статья "Разработка учебного языка программирования и интерпретатора" (стр. 92)

Статья "Требования к современной обучающей среде по программированию" (стр. 104)

Концепция

Цели PureBuilder

Цели PureBuilder:

1. Использование PureBuilder должно начинаться еще на стадиях, предшествующих написанию программы, - для разработки архитектуры программы.

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

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

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

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

Это всё должно значительно увеличить производительность труда при разработке и сопровождении программ и сократить количество ошибок в программах.

Замысел

Среда визуальной разработки PureBuilder [пю'оби'лдэ] (чистый построитель программы - англ.) - должна полностью избавить от исходного кода в текстовом виде и перейти к визуальному программированию на основе универсального языка программирования. PureBuilder относится к классу программных продуктов, который известен как "семантический редактор" или "структурный редактор".

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

Разработчик программы изначально мыслит схемами (зрительными образами) и затем обычно переводит свои мысли в форму исходного кода, понятного компьютеру. При переводе разработчик программы делает ошибки. Задача состоит в том, чтобы заставить компьютер понимать схемы, избавившись от посредника в форме исходного кода. Современный графический интерфейс и тачскрин позволяют разработчику программы создавать схему на экране компьютера наиболее естественным для человека образом.

Но исходный код не должен быть заменен на блок-схемы алгоритмов и графические (визуальные) языки программирования, в том числе UML и ДРАКОН, так как их возможности ограниченны, использование трудоемко, а расположение на экране проблематично. Напротив, целесообразно использование автоматически генерируемых структурных схем свободной компоновки. Однако, такие схемы могут быть только вспомогательным средством, так как недостаточно подробны и выразительны для описания деталей алгоритма.

Заменой исходного кода должна быть, во-первых, структура из вложенных блоков для описания алгоритма (как дальнейшее развитие идеи структурного программирования), а во-вторых, таблицы для объявления переменных и констант. Они должны непосредственно определять содержимое, соответственно:

• • абстрактного синтаксического дерева, компилируемого в исполнимый код для целевой платформы, в байт-код или в формат WebAssembly

  • таблицы символов, в которой компилятор хранит информацию об объектах программы

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

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

Идентификатор должен объявляться, специфицироваться и при необходимости инициализироваться значением в соответствующей таблице "элементы документа". Причем это должен быть гибрид таблицы и дерева, так как идентификаторы относятся к объектам различных типов - с различными наборами параметров. Если идентификатор сложный, то для его построения может использоваться построитель идентификаторов. Хранится идентификатор должен в таблице имен.

Архитектура PureBuilder

Лучшим кандидатом на роль встроенной СУБД является PostgreSQL, причем для хранения кода во внутреннем представлении должно использоваться поле типа JSONB.

ПОПРАВКА: внутренним представлением программного кода удобнее сделать текст на пока не разработанном языке текстовой разметки программного кода.

Карточный интерфейс !!!

Первоначально предполагалось использовать В PureBuilder существенно модифицированный Многодокументный интерфейс со вкладками (tabbed document interface (TDI)), в котором устранены его главные недостатки. Но теперь автор (Прохоренко С.А.) кардинально изменил замысел интерфейса. Это должен быть карточный интерфейс с карточками одинаковой ширины и адаптивным дизайном.

Переход фокуса с одной карточки на другую с отображением на экране осуществляется в основном не с помощью прокрутки и поиска карточки глазами, а:

• путем щелчка в другой карточке по значку объекта, отображаемого затем карточкой,

• или путем щелчка по одному из элементов интерфейса deletable chip, расположенных на отдельной панели.

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

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

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

Карточки некоторых типов могут иметь вкладки на всю область карточки (например, текст программы или таблица переменных/объектов программы), полосы прокрутки и раскрываться в отдельном окне или вкладке.

Вот краткий самоучитель по программированию карточек: Implementing the “Card” UI Pattern in PhoneGap/HTML5 Applications. См. также CardStack . Следует по возможности воспользоваться шаблонами карточек в фреймворке Material Design Lite

Эскиз устаревшего дизайна

Вкладки открытых документов (проектов, модулей, процедур и т.д.) можно перетаскивать на панель задач MS Windows в качестве открытых окон. Поэтому на разных мониторах или друг под другом могут одновременно отображаться разные вкладки.

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

В качестве более предпочтительного варианта рассматривается расположение вкладок документов не по горизонтали, а по вертикали:

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

Требования к шрифту: моноширинный, без засечек, с большим количеством символов Unicode, с кириллицей, с приятным начертанием, не позволяющий спутать буквы со схожим начертанием (и ноль), не растровый.

Этим требованиям удовлетворяет шрифт Liberation Mono. От него меньше устают глаза, чем от Courier или  Consolas. В нем есть необходимые для составления выражений символы "больше или равно", "меньше или равно" и "не равно". Символы, отсутствующие в этом шрифте, должны заимствоваться из других шрифтов.

Отображение грамматики языка программирования на интерфейс PureBuilder

Функциональные возможности PureBuilder, в основном, должны соответствовать возможностям языков Go (преимущественно), Python, Rust (в части управления памятью) и языков семейства Oberon (включая Zonnon). Кроме того, должна быть реализована функциональная парадигма программирования.

Грамматика языка, в основном, включает в себя:

1. Импорт

2. Объявления

3. Последовательность инструкций

4. Выражения

5. Идентификаторы

Эти разделы должны реализовываться совершенно различными графическими средствами PureBuilder:

• • импорт - древовидными схемами (наподобие зависимостей в Microsoft Access) (раздел "Зависимости" панели задач);

  • объявления - таблицами (панель элементов структуры);

  • последовательность инструкций - блочным гипертекстом (панель структуры) и коллекциями шаблонов элементов (панель коллекций элементов);

  • выражения - построителем выражений (примерно как в Microsoft Access) (во вкладке "Выражение"). Построитель выражений должен полностью избавить от необходимости пользоваться клавиатурой, например, пробелы в выражениях не допускаются, а вместо них автоматически вставляются увеличенные интервалы между буквами;

  • идентификаторы - построителем идентификаторов (наподобие довольно распространенных средств для выбора имен веб-сайтов, дополненных тематическими каталогами, словарями и средствами поддержки стиля) (во вкладке "Идентификатор", не показанной на эскизе). Стиль написания идентификаторов должен обеспечиваться автоматически: использование заглавных и строчных букв в начале и в середине идентификаторов, использование наклона букв и т.п.

Вставка элементов из коллекции в панель структуры

Вставка шаблона элемента из панели коллекций элементов в панель структуры

Традиционные технологии drag-and-drop и щелчки по значкам «копировать» и «вставить» должны быть дополнены более быстрыми технологиями работы с мышью:

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

  • при щелчке левой клавишей мыши по объекту (блоку, оператору или идентификатору в области алгоритма или элементу палитры блоков и операторов) тот копируется в буфер обмена и одновременно вставляется в место нахождения мигающего курсора в области алгоритма и выделяется

  • при щелчке левой клавишей мыши по значку «вставить» выделенный объект из соответствующей панели копируется в место нахождения мигающего курсора в области алгоритма 

  • при щелчке левой клавишей мыши в области алгоритма туда вставляется содержимое буфера обмена или поля редактирования соответствующей панели (например, выражение из панели выражения) или выделенный объект (элемент палитры блоков и операторов), причем вид курсора указывает на источник вставляемого содержимого (буфер обмена или объект из панели)

  •  

Упорядочение шаблонов элементов на панели коллекций

Шаблоны элементов на панели коллекций должны быть упорядочены. Для этого панель коллекций может быть разбита по вертикали на несколько разделов. Разделы с заголовком - свертываемые. Они могут состоять из разделов без заголовка - несвертываемых.

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

Заглушки в элементах на панели структуры

Элемент, вставленный из панели коллекций элементов в панель структуры, автоматически содержит заглушки вида «выражение», «число», «дата», «угол», «массив», «строка», «формат», «тело цикла» и т.п. аналогично тому, что происходит в построителе выражений MS Access. Текст заглушки подсказывает, что необходимо вставить вместо заглушки. Заглушки автоматически выделяются цветом. Они не считаются ошибкой, пока не производится попытка трансляции кода в форму, предназначенную для исполнения.

Примеры заглушек в построителе выражений MS Access и в строке формул MS Excel:

Пиктограммы типов контейнеров

Нумерация массивов должна начинаться не с 0, а с 1, что должно найти свое отражение и в пиктограммах.

В PureBuilder должен быть также тип "унифицированный контейнер". Контейнер – это набор однотипных элементов. К контейнерам относятся массивы, списки и типизированные файлы. См. статью В. В. Лаптев, А. Тырнава, В. В. Толасова "Об унификации агрегатных типов данных при обучении программированию"

Локальное меню элемента в панели структуры

Локальное меню элемента в панели структуры должно появляться при наведении курсора на элемент, без необходимости щелчка правой клавишей мыши.

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

• • Отменить

  • Повторить

  • Вырезать

  • Копировать

  • Вставить

  • Удалить

  • Дублировать

  • Очистить (превратить элемент в его пустой шаблон, но без изменения заголовка)

  • Тип (можно изменить тип элемента на другой, выбранный из панели элементов)

  • Найти (в пределах элемента)

  • Заменить (в пределах элемента)

  • Свернуть/развернуть (фолдинг)

  • Показать все уровни (фолдинг)

  • Активировать/дезактивировать (т.е., закомментировать для транслятора)

  • Переместить (буксировка)

  • Примечание (комментарий, который может содержать гиперссылки, в том числе, на закладки и на объекты, доступные через браузер проекта)

  • Запуск (исполнение кода)

  • По шагам (исполнение кода)

  • Закладка

Структура программного кода

Скобка операторного блока

Скобка операторного блока используется в PureBuilder вместо операторных скобок. Она автоматически охватывает слева весь операторный блок в коде, включая заголовок. Она имеет закругленные углы.

При коротком щелчке левой кнопкой мыши по скобке она действует как кнопка «свернуть/развернуть», осуществляя фолдинг кода. Сворачивание происходит до строки заголовка. Разворачивание не охватывает вложенные блоки, если те были свернуты. Операторный блок не выделяется. Локальное меню не появляется. Двойной щелчок по скобке воспринимается как два коротких.

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

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

При щелчке правой кнопкой мыши по скобке весь операторный блок выделяется, и над ним появляется локальное меню. При любом способе выделения операторный блок выделяется только целиком, включая вложенные блоки, но вложенный блок может быть выделен отдельно.

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

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

Многоветочные конструкции и особенности циклов

PureBuilder должен поддерживать многоветочные конструкции:

Верхний левый угол - обычная длинная форма условного оператора

Нижний левый угол - переключатель (case, switch)

Верхний правый угол - цикл Дейкстры (ветка else исполняется однократно, если изначально ни одно из условий не соблюдено)

Нижний правый угол - модификация цикла Дейкстры, предназначенная для автоматного программирования в форме SWITCH-технологии

Значения, с которыми сравниваются выражения-селекторы, также являются вычислимыми выражениями.

Разумеется, лишние ветви в каждом конкретном случае удаляются. Для добавления или удаления пустых (!) ветвей используются всплывающие при наведении курсора графические элементы с символами "+" и "×".

После выполнения ветви по какому-либо условию не производится проверка следующего условия (как в switch без break в языках С/С++), а управление сразу передается ветви anyway.

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

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

Циклы с постусловиями не применяются в PureBuilder.

Для линейного поиска используется функция select или построитель запросов. Кроме того, для схем "полный проход" и "линейный поиск" используются специализированные конструкции со словом until. Вот эти схемы:

Полный проход

1. Задать переменным первоначальные значения (ввод и/или присвоение)

2. Перейти к первому элементу

3. Задать условие продолжения перебора элементов в цикле (while)

4. В теле цикла выполнить полезные действия

5. В теле цикла перейти к следующему элементу

Линейный поиск

1. Задать переменным первоначальные значения (ввод и/или присвоение)

2. Перейти к первому элементу

3. Задать условие продолжения перебора элементов в цикле (while) и условие ненахождения искомого элемента (and)

4. В теле цикла выполнить полезные действия (это редко требуется)

5. В теле цикла присвоить переменным номер и значение элемента

6. В теле цикла перейти к следующему элементу

7. После цикла использовать переменные с номером и значением элемента

8. После цикла, если искомый элемент не был найден, то выполнить полезные действия

Конструкция поэтапного выполнения

Эта конструкция предназначена для упрощения программ, в которых используется большое количество последовательных проверок. Она основана на реальной потребности программистов.

Модуль не содержит непосредственно операторных последовательностей, но может содержать указания на (не обязательно содержащуюся в нем) процедуру или функцию, выполняемую при загрузке модуля, и/или на (не обязательно содержащуюся в нем) процедуру или функцию, выполняемую при выгрузке модуля из памяти.

Для модулей не существует понятий "раньше-позже", "вышестоящий-нижестоящий" и "вложенный-объемлющий". Эти понятия остаются на более низком уровне: в процедурах и функциях. Модули служат лишь для удобной группировки функций и процедур, а также для их одновременной загрузки/выгрузки из памяти во время исполнения программы. Зависимость между модулями - это использование переменных, функций и других объектов одного модуля другим.

Высокоуровневые представления (проект, подсистема, модуль) должны отображаться двумерными графами на панели структуры, а кроме того, таблицами содержимого. Графы не должны отображать очередность (следование, ветвление, циклы), а только лишь состав элементов и зависимости между ними. Щелкнув по значку элемента или зависимости, можно "провалиться" на уровень ниже (процедура, функция), где увидеть очередность выполнения инструкций алгоритма.

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

Модуль является полноценным электронным документом - зашифрованным криптостойким шифрованием и подписанным электронной подписью и timestamp по UTC. Все модули одинакового ранга и формата, кроме модулей, описывающих модульную архитектуру программы.

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

Функции и процедуры

В PureBuilder функции и процедуры не могут быть вложенными в другие функции и процедуры.

В PureBuilder функции не только имеют единственное возвращаемое значение, ассоциированное с именем функции, но и, в отличие от процедур, для функций не допускается никаких побочных эффектов. Для процедур побочные эффекты допускаются только путем изменения значений переменных через параметры (при передаче параметра по ссылке) и только если эти процедуры объявлены как имеющие побочные эффекты. Переменные, объявленные снаружи функций и процедур, доступны внутри этих функций и процедур только в режиме "для чтения".

Все переменные в PureBuilder строго локальные, то есть объявляются не непосредственно в модуле, а в процедурах и функциях - в табличном виде в панели элементов структуры. Непосредственно в теле процедуры или функции (на панели структуры) содержатся только последовательности операторов.

Принцип "сначала объяви, потом используй" в PureBuilder неприменим. В процедуре/функции объявления делаются в одном месте - в таблице на панели элементов структуры, а алгоритм записывается совершенно в другом месте - на панели структуры. Естественно, что к моменту компиляции должно быть готово и то, и другое, но что из них по времени раньше - безразлично. Наполнение их содержанием происходит параллельно. А чисто пространственно объявления располагаются даже ниже алгоритма.

Логические функции могут задаваться в табличной форме, аналогичной построителю запросов в MS Access, или в форме таблиц истинности. Такие функции очень удобны для применения в качестве условий в условных операторах и операторах циклов.

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

При завершении функции/процедуры (независимо от того, возник ли сигнал отказа) должны быть автоматически освобождены все ресурсы, занятые этой функцией/процедурой. Например, должны быть закрыты открытые в ней файлы. Ответственность за это возлагается на компилятор, действие которого аналогично действию конструкции using в C#.

Стандартный ввод и вывод данных 

В PureBuilder стандартный ввод и вывод данных осуществляется в следующих формах:

• • В/из неформатированного текстового файла

  • В/из гипертекстового документа

  • В окно терминала

  • В текстовый лог-файл

  • В/из таблицы базы данных, совместимой с Microsoft Excel

  • Именованный ввод и вывод в/из таблицы, совместимой с Microsoft Excel

  • В/из полей форм и виджетов рабочего стола

PureBuilder имеет текстовый и табличный редактор для ввода, просмотра, редактирования данных, а также конверторования данных в/из различных форматов.

Генерация и обработка сигналов отказа

Сигналы отказа в PureBuilder являются переменными логического типа и заменяют собой исключения и функции Assert и Exit в языках программирования, а также создаваемые программистом коды ошибок.

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

• • имя_вызываемой_процедуры.имя_сигнала_отказа,

  • имя_вызываемой_процедуры.имя_прерывания_операционной_системы,

  • имя_вызываемой_процедуры.failure (для любого сигнала отказа или реально возможного прерывания операционной системы).

Необходимо автоматически информировать программиста, какие из сигналов отказа, могущих возникнуть в вызываемой процедуре/функции, учтены в вызывающей процедуре/функции. Для этого около идентификатора процедуры/функции должна появляться всплывающая табличка со всеми возможными сигналами отказа (включая реально возможные прерывания операционной системы) и обозначениями действий ("не учтено", "учтено", "игнорировать") напротив них. Идентификаторы процедур/функций, имеющих хотя бы один неучтенный сигнал отказа, должны автоматически помечаться.

В вызываемой процедуре/функции сигналы отказа используются один раз – только в качестве параметра в операторе escape(имя_сигнала_отказа) – и без указания имени вызываемой процедуры. Они не могут каким-либо ещё образом использоваться в вызываемой процедуре.

Как и оператор Exit в языках программирования, оператор escape(имя_сигнала_отказа):

• • чаще всего используется в условном операторе;

  • прерывает исполнение процедуры/функции, в которой он встречается.

Но, в отличие от оператора Exit (отсутствующего в PureBuilder), оператор escape(имя_сигнала_отказа):

• • объявляет сигнал отказа – переменную логического типа – и присваивает ей значение «истина»,

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

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

• • Разбить каждый крупный объект на меньшие, передаваемые по значению.

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

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

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

• • для облегчения обработки прерываний операционной системы с помощью перехвата сигналов отказа,

  • для сохранения возможности воспользоваться выходными параметрами или возвращаемым значением в случае отказа опасной части программы.

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

В деструкторе объекта сигнал отказа объекта (в отличие от сигнала отказа самого деструктора) генерируется при выполнении оператора destroy(имя_сигнала_отказа). При этом происходит бесследное уничтожение всего объекта.

Сигналы отказа записываются в специальный стандартный журнал (аналог "черного ящика" самолета). Не всегда последствия ошибок времени исполнения можно предотвратить, но можно будет хотя бы сделать какие-то выводы.

Легковесные процессы и обмен сообщениями между ними

В PureBuilder функции, процедуры и объекты (в парадигме ООП) являются легковесными процессами, имеют отдельные "кучи" в памяти с отдельной "сборкой мусора" и могут исполняться параллельно на разных ядрах процессора или разных компьютерах, объединенных в сеть. Реализован обмен сообщениями между легковесными процессами на основе модели акторов, аналогично языку Erlang.

PureBuilder имеет собственную виртуальную машину, подобно BEAM в языке Erlang.

Управление памятью

В PureBuilder используются автоматическая память и сборка мусора (точная, не "консервативная"). Программисту также предоставляются возможности использовать динамические многомерные массивы, предотвратить сборку мусора в неподходящий момент, а также форсировать освобождение памяти указанными программистом объектами не дожидаясь сборки мусора, если эта память одновременно не используется другими объектами. Для ускорения работы программы программист может использовать передачу значения переменной в виде константного параметра в функцию или процедуру по ссылке (т.е., без копирования) вместо передачи по значению (с копированием).

Предотвращение типичных ошибок в программах

В PureBuilder используются следующие средства предупреждения типичных ошибок в программах:

• Сборка мусора и Умный указатель

• Многомерные динамические массивы и Цикл foreach

• Целые числа произвольной длины и вещественные числа с плавающей точкой произвольной точности (в ячейке хранится число стандартной длины/точности или ссылка на число большей длины/точности)

• Строки произвольной длины

• Компилятор должен выявлять использование переменных, которые "выше по тексту" не получают значение. Это не абсолютная гарантия от ошибки, так как, например, переменная может якобы "получать" значение в неиспользуемой ветви условного оператора

• Запрещено сравнение вещественных чисел на равенство

• Не применяются литералы, за исключением инициализации переменных (благодаря этому предотвращается появление так называемых "магических чисел")

Парадигмы программирования

Мультипарадигменность

PureBuilder должен, оставаясь по-возможности лаконичным, наглядными средствами поддерживать разнообразные (но не любые существующие) парадигмы программирования:

• • Автоматное программирование в форме SWITCH-технологии

  • Функциональное программирование

  • Логическое программирование (кстати, знаменитый "Буран" летал под управлением программы, написанной на диалекте Prolog'а)

  • Процедурное программирование

  • Структурное программирование

  • Объектно-ориентированное программирование

  • Обобщенное программирование

  • Компонентно-ориентированное программирование

  • Параллельное и распределенное программирование

Средства PureBuilder, относящиеся к какой-либо парадигме программирования, должны отображаться на отдельной вкладке или в виде скобки операторного блока соответствующего цвета.

ООП

Полиморфизм

В PureBuilder полиморфизм обеспечивается следующим образом. Для каждого метода в таблице методов класса программист указывает псевдоним, по которому вызывается этот метод. Разные методы разных классов, обладающие похожим действием, могут иметь общий (одинаковый) псевдоним. Метод не может быть вызван непосредственно по своему имени, а только по псевдониму. Всякий раз при использовании псевдонима будет вызываться тот из методов с общим псевдонимом, который содержится в классе объекта, к полям которого применяется псевдоним. По умолчанию псевдоним создается автоматически на основе имени метода и может быть отредактирован программистом разом во всей программе (рефакторинг).

Классы

Классы (типы объектов) в PureBuilder принадлежат тому или иному модулю. Класс изображается в виде таблицы полей, таблицы методов и таблицы родительских интерфейсов. Программист добавляет в таблицы класса поля, методы и родительские интерфейсы, принадлежащие данному модулю или другим модулям и специфицированные именем модуля. Поля и методы объявляются в модуле независимо от классов, которые могут их содержать.

Непосредственное добавление полей и псевдонимов методов

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

Копирование полей и псевдонимов методов из родительских классов

Программист может добавить в соответствующие таблицы класса все поля и псевдонимы методов одного или нескольких других классов, указав имена этих классов. Эти поля и методы автоматически помечаются в таблицах именем родительского класса, от которого они непосредственно получены. Имя родительского класса в таблице не может быть изменено программистом.

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

Никакие изменения (добавление, удаление, отключение, включение) в родительских классах (в отличие от связанных интерфейсов) не наследуются автоматически в классах-потомках.

Тем не менее, программист может явным образом передать изменения, уже произошедшие в родительских (в том числе, библиотечных) классах, в классы-потомки. Если поле или псевдоним метода в родительском классе были удалены, отключены или включены (а в дочернем классе они находятся в противоположном состоянии), то такие поля и псевдонимы методов выделяются соответствующим образом в дочернем классе без автоматического удаления, отключения или включения. Если поле или псевдоним метода были добавлены в родительский класс, то они автоматически добавляются в дочерний класс в отключенном состоянии и выделяются как добавленные, и программист может их включить. Для доступа с целью внесения изменений ко всем классам-потомкам данного класса (во всех поколениях) используется дерево зависимостей объектов программы. Классы-потомки, в которых программист может принять или отклонить унаследованные изменения, автоматически выделяются. Таким образом, хотя наследование и не применяется в явном виде, но программисту предоставляются удобства, свойственные наследованию.

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

Постоянное связывание с родительскими интерфейсами (композиция или агрегирование)

Если программист добавил один или несколько классов (например, библиотечных) в таблицу родительских интерфейсов, то впоследствии программист не сможет удалять, отключать или включать унаследованные от этого интерфейса поля и псевдонимы методов. Но эти поля и псевдонимы методов могут быть удалены, отключены или включены в тех классах, куда они будут скопированы.

Для решения проблемы «хрупкости базового класса» классы, от которых образуются объекты, не могут быть добавлены в таблицу родительских интерфейсов, а от классов, добавленных в таблицу родительских интерфейсов, нельзя непосредственно создавать объекты (экземпляры классов, переменные). Исключение составляют библиотечные классы, на которые оба этих ограничения не распространяются. Интерфейсы и библиотечные классы соответствующим образом выделяются по отношению к другим классам.

Устранение дублирования полей и псевдонимов методов

Если имеются дублирующие одинаковые поля и псевдонимы методов, полученные от разных родительских классов, содержащиеся в связанных родительских интерфейсах или добавленные непосредственно (без копирования полей и псевдонимов методов какого-то класса), то они автоматически выделяются как ошибочные. Программист должен отключить или удалить дублирующие поля и псевдонимы методов.

Сравнение классов

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

Проверки целостности классов

PureBuilder осуществляет проверки во время конструирования программы или компиляции: (1) объявлены ли в новом классе все необходимые поля, обрабатываемые при вызове всех его псевдонимов методов (выдача ошибки "нет поля или лишний псевдоним метода"); (2) есть ли в новом классе поля, не обрабатываемые ни одним из его псевдонимов методов, кроме конструктора (выдача ошибки "нет псевдонима метода или лишнее поле")?

Создание объектов (экземпляров классов)

Объекты (экземпляры классов) в куче (динамической памяти) создаются с помощью оператора new, а объекты в стеке (статической памяти) создаются путем объявления в соответствующей таблице – как и переменные базовых типов.

Программирование по контракту

В PureBuilder поддерживается программирование по контракту.

В таблице формальных параметров и возвращаемого значения функции/процедуры имеются столбцы Предусловие и Постусловие. Если параметр является исключительно входным (передача по значению), то постусловие автоматически помечается как недоступное. Если параметр является исключительно выходным, то предусловие автоматически помечается как недоступное. Для возвращаемого значения функции предусловие автоматически помечается как недоступное.

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

В таблице импорта переменных имеется столбец Предусловие, проверка условия которого происходит при импорте соответствующей переменной.

Работа в среде

Сохранение кода на жесткий диск

Сохранение кода на жесткий диск осуществляется путем записи во встроенную базу данных, в которой формат хранения данных почти совпадает с внутренним представлением PureBuilder (абстрактное синтаксическое дерево в табличной форме и таблица символов). Преимущества:

• Мгновенное переформатирование старого кода к новым версиям PureBuilder

• Мгновенная загрузка больших проектов

• Не нужно делать парсер

• Базу данных можно встраивать в разрабатываемые на PureBuilder проекты (побочное применение)

• Вопросы контроля целостности кода, отслеживания изменений, отката к предыдущим состояниям, совместной удаленной работы и т.п. решаются легко, так как это прямые функции базы данных

Поддержка последовательных версий программных проектов

Исходный программный код каждого программного проекта должен сохраняться в отдельный файл, содержащий базу данных. В качестве СУБД рекомендуется PostgreSQL. В базе данных программного проекта должна храниться не только текущая версия проекта, но и полная история его изменений. Это позволит производить сравнение версий и откат изменений на любую глубину как в Википедии.

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

Удаленные, модифицированные и новые элементы должны автоматически выделяться соответствующими цветами. Щелкнув по модифицированному элементу, можно посмотреть, что же изменилось в его структуре.

Сравнение версий и откат изменений должны быть возможны как в целом по проекту, так и по отдельному модулю, функции и т.п.

Если в ранней версии содержатся части программного кода, которые должны быть возвращены в текущую версию, то это может осуществляться копированием в буфер обмена (где программист может подвергнуть программный код рефакторингу) и вставкой в текущую версию проекта. С той же целью может быть использован и механизм, аналогичный средству экспорта и импорта таблиц, запросов и других объектов в Microsoft Access. В случае совпадения идентификаторов копируемых модулей, функций и т.п. с идентификаторами в текущей версии проекта конфликт должен разрешаться по выбору программиста: перезаписать, записать с новым именем или отменить изменения.

Если в проекте участвуют несколько программистов, то изменения помечаются их именем как в Википедии.

Изменения каждого модуля, функции и т.п. сопровождаются нередактируемым автоматическим комментарием в таблице, отображающей изменения, например, «Произведен откат к версии от 14.09.2012 13:57». Может быть также добавлен комментарий программиста, а в необходимых случаях PureBuilder может требовать от программиста ввода комментария.

Любую версию можно сохранить в отдельный проект с новым именем (форк, то есть, параллельный вариант).

Разработка программы методом "сверху вниз" и поддержка стадий готовности

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

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

Поддержка списка ToDo

Список ToDo должен храниться в базе данных проекта – как текущая версия списка ToDo, так и полная история его изменений, в том числе изменений стадии готовности пунктов списка ToDo. Список ToDo может просматриваться как в целом по программному проекту (в порядке очередности исполнения), так и в разрезе модулей, функций и т.п., к которым относятся соответствующие пункты списка ToDo (т.е., иерархически).

Поддержка форков (веток, параллельных вариантов) программных проектов

PureBuilder должен обеспечить сравнение двух проектов, имеющих общего предка, а также копирование (по выбору программиста) несовпадающих частей программного кода из одного проекта в другой – аналогично принятию исправлений в сравниваемых документах Microsoft Word.

Однако при этом PureBuilder может ошибочно находить мнимые отличия из-за измененных идентификаторов или общей структуры сравниваемых проектов. Для исправления таких ошибок программист может в ходе сравнения проектов производить рефакторинг или изменение общей структуры любого из двух проектов.

При копировании модуля, функции и т.п. из одного проекта в другой история изменений этого модуля, функции и т.п. тоже копируется.

Поддержка комментариев к программному коду

Комментарии к программному коду хранятся в базе данных проекта в привязке к модулям, функциям, параметрам и т.п. Комментарий может относиться к строке алгоритма, к строке объявления или к строке свойства объявленной переменной или иного объявленного объекта программы. Для комментариев поддерживается стандартная структура, например: необходимость элемента, способ реализации элемента и обоснование выбора, достоинства и недостатки, область применения, условия применения и т.п. Стандартная структура комментария зависит от типа элемента (модуль, функция, цикл и т.п.). Комментарии могут содержать гиперссылки и внедренные в текст маленькие пиктограммы.

Поддержка тестирования и отладки 

Тестирующие модули, тестовые данные и результаты тестирования с комментариями хранятся в базе данных проекта в привязке к соответствующей версии проекта, а также к тестируемому модулю, функции и т.п.

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

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

Экспертная система

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

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

Вкладки в главном окне

Закладка должна указывать на определенное место в программном проекте, и это место в программном проекте должно отображаться в специализированной вкладке.

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

Открытые ранее вкладки элементов должны укладываться в штабеля (папки, стопки, группы - устоявшегося русского перевода нет) вкладок (модули отдельно, функции отдельно и т.д.), соответствующие типу элементов и имеющие соответствующий значок. Похожий механизм под названием tab stacking реализован в браузере Opera 11. Но в PureBuilder штабель вкладок должен раскрываться в виде выпадающего списка при нажатии находящегося на нем значка

. При нажатии на сам штабель должна открываться последняя вкладка, с которой осуществлялась работа. При нажатии на пустой штабель должна открываться новая вкладка.

Ссылки

• Программирование без текстовых файлов

• Статья Structure editor в английской Википедии

• Дискуссия на OberonCore

• Блог Кирилла Осенкова

• Цитата Страуструпа на блоге Евгения Зуева

• Построитель выражений в Microsoft Access

  • Scratch - среда программирования для детей

  • Alice - похожая на Scratch среда программирования для старшеклассников и студентов ВУЗов

  • Squeak - похожая на Scratch среда программирования для детей и профессионального использования

  • 12Blocks - похожая на Scratch среда программирования микроконтроллеров

  • StarLogo TNG - похожая на Scratch среда программирования для детей

  • Elements - похожая на Scratch среда программирования для Smalltalk

  • Modkit - похожая на Scratch среда программирования встроенных систем

  • App Inventor for Android - похожая на Scratch среда разработки от Google

• Microsoft Kodu - среда программирования для детей

• StencylWorks - похожая на Scratch среда для разработки компьютерных игр

• Google Blockly - похожая на Scratch среда программирования

• Build Your Own Blocks (раньше назывался SNAP!) - похожая на Scratch среда программирования

• JetBrains MPS - блочный редактор DSL, Java и еще нескольких языков

• iiiiioiooooo - структурный редактор Clojure