А оторванного ли?.. В проекте определения, данном Лаптевым, язык ВЛ-редактора - фактически КП с элементами О-07, как можно понять...
Относительно границы между будущими ролями в триаде - программист отличается только тем, что кодирует для искусственного исполнителя часть решения задачи, предложенной (предметником и аналитиком) для реализации на этом исполнителе. И определяет для пользователя порядок работы с исполнителем этого кода. Отсюда потребность в специнтелресурсах по этому исполнителю, по реализации для него систем алгоритмов и структур данных.
В главном же интеллектуальные ресурсы по ролям должны совпадать - это "программирование, очищенное от мешающих случайностей". Но обеспечивающее "расширенный код" представления знаний.
Притом ориентированное на две категории исполнителей - искусственного (устройство программируемое - в пределе полноценную "языковую машину" и непрограммируемое - мехаанизм для "препоручения вычислений физической среде", типа командоаппарата или шарнирных рычагов) и естественного (обладающего сознанием и, как следствие - способностью действовать на основании только целей). Тут уже Е.Э. говорил на примере всё того же образного представления:
viewtopic.php?p=14059#p14059 и
viewtopic.php?p=13999#p13999.
И тут как раз с учётом представления системной инженерии Левенчуком возникают вопросы к "аттической" концепции. Один уже Илья озвучил - не увлекаться упрощённой и оторванной от возможностей реальных, "промышленных" искусственных исполнителей информатизацией.
Но есть ещё вопрос о том самом минимальном "расширенном коде". И если посмотреть на состав сущностей прогязыка, которые предлагают оставить Аттики (и не только они) для начала - возникает потребность в корректировке.
Потому что интуитивно вроде бы оправданно предельное упрощение конструкций нелинейного управления. Но контринтуитивно - нужно, чтобы как раз "умещалась в голове" реальная деятельность - в частности, уже осуществляемая детьми в играх.
Считаю, для этого с самого начала в языке должны присутствовать
конструкции Дейкстры. Конечно, не в такой абстрактной записи
- надо давать по такому принципу, как
здесь - т.е. заготовки, единицы прибавления/вычитания и "что будет, если мы вот сюда поставим этот кубик".
В чём смысл? Эти конструкции отражают множественный выбор системно, как "шапочный разбор". Что даёт возможность впоследствии объяснять это "для программистов" как IF{(IF)}*, IF{-ELSIF}+, CASE[-ELSE], SWITCH - что в каком ТЯП реализовано. И реально в любой сколь-нибудь сложной игре дети ведь встают перед множественным выбором - как по константе, так и по условию "охраны" ветви выбора...
Кроме того, есть аспект, специфичный для циклов. А именно - то, что сказано в
п.1 этого поста. Конкретно - что в жизни (и в игре) параметризация цикла числом итераций возможна, во-первых, как частный случай и во-вторых - как итог анализа задачи и предметки в соответствии с целью решения.
И когда мы начинаем с "цикла ДЛЯ" - тем самым воспитываем "начётника" из учня ("повторил N раз и пошёл отдыхать, а почему и дало ли это что-то в реальной ситуации исполнения - меня не интересует")...
А когда начинаем с цикла "гибридного", где надо реально задать условие окончания - то побуждаем "вытаскивать" в охранный логвыр элементы реального состояния предметки. И ведь знания об этом дети реально имеют. Вспомним, что в играх с предметами - своих для мальчиков (конструкторы, машинки) и для девочек (куклы, домашняя утварь) - дети ведь обычно придумывают свои конфигурации и "варианты использования" даже при наличии инструкции к игрушкам.
А цикл Дейкстры также задаёт паттерн "универсальной программы". Как построитель вариантов использования из ветвей-"кубиков" (абстрактно - из символов "алфавита процессов", определённого сочинителем).
Понятно, что минимальная конструкция Дейкстры должна иметь две развилки (и соответственно три ветви). Ну и удобно показать, что отбрасывая одну из них - получаем обычную развилку или цикл - как частный случай. Названия конструкций для детей, ессно, надо подбирать не "мудрёные" - лучше всего образные. Вроде "выбор/цикл с вариантами".
Ну и, разумеется, процедура как минимальный механизм расширения языка вопросов не вызывает.
С этим связывается и введение базовых типов данных - числового, литерного, логического. Тут можно вводить видовое подразделение на регулярные (для определённых свойств предметки) и произвольные (для вероятностных или определяемых "на деле"). Это касается и предопределённых типов, и сочиняемых.
Примерно так.