Спасибо Степану Митькину за идею. Мне эта идея не совсем понятна и постараюсь объяснить почему. 1. Начнём с цели этого преобразования. Как я воспринял на слух, задача этого внедрения - избавиться от скобок и операторов. Для меня это странно, потому что пользователю трудно воспринять программу не из-за скобок и операторов, а потому что это априори программа, и пользователь, возможно, в этой области не полностью разбирается. Сам наступал на эти грабли и мне вовремя сделал замечание, кажется, Геннадий Тышов. Поэтому я придерживаюсь больше концепции ИС ДРАКОН - прятать код во втором текстовом поле. Думаю, вы понимаете, о чём речь. Если у меня икона в коде проекта - объект (выражаясь терминами JavaScript), структура (выражаясь терминами Си), то он имеет ключи: ширина, высота, дизайн, текст1 и текст2. Именно текст1 будет использоваться при отображении иконы в Дракон-схеме (например, "Обнуление счётчика"), а текст2 будет использоваться в интерпретации схемы в текст программы на ЯП Си (например, "int score = 0"). В доработках к своей среде Дракон-Си я такую деталь в плане указал и буду работать над реализацией. 2. Оценили ли вы возможность составления такого набора цветов, чтобы пользователь мог использовать все возможности языка и, условно, не путать нежно-бежевый с нежно-розовым? Мы же идём по дороге лёгкости визуального восприятия. Мне кажется, что для таких цветов потребуется своя справка. Например, писать "Голубым цветом выделяются два числа/две переменные/два выражения, между которыми стоит знак "больше". Могу предположить, что такая справка выйдет большой, а пользователи не любят читать. Тем более громоздкие пояснения не характерны редакторам Степана Митькина, DrakonHub и DrakonTech. 3. Сам процесс использования блоков такой, что можно сломать голову. Я понял, что пользователю надо ПЕРЕВЕРНУТЬ то выражение, которое он хочет записать и составить ПЕРЕВЁРНУТОЕ выражение из блоков. Причём у него могут возникнуть сложности для функций с несколькими аргументами - что над чем писать и каким цветом. А если выражение составлять в естественном порядке в виде блоков, то в них и смысла мало. Выражаясь глубоко-научными терминами - "костыли". 4. Рассмотрим ваш пример в видео - аргументы стрелочных функций. Почему left и right оказались в коде заменены звёздочками? Пользователь же не сможет также. 5. У Вас такие свойства и методы как length, parse, random записаны в один блок вместе с объектом, которому эти методы и свойства принадлежат. Почему бы для полноты картины и эти моменты не выделить в другие блоки? Это касается языка ДРАКОН-JavaScript.
Я, к сожалению, жёстко прошёлся по этой идее, но недостатков уж сильно много. Я бы называл это попыткой "одраконить" программирование тотально. Визуализация циклов, переключателей, условий, меток в программировании помогает пользователю отследить все пути работы программы при разных входных данных. Это полезно хотя бы даже для тестирования программного продукта. Попытка визуализировать функции, операторы для пользователя значительных преимуществ в понимании программы не принесёт. Мне, например, понятнее строка "a == b", чем блок a, блок b и снизу блок equal. Это приобретает привкус ассемблера. Считаю также идею Степана Митькина, как минимум, не универсальной, потому что языки разные бывают. У JavaScript есть методы, стрелочные функции и т.д., у Си такого нет - там предназначение блоков должно быть другое. Пока что не хватает контекстных подсказок как в любой IDE.
Могу попытаться предложить, что-то своё, так как сам однажды продвигал идею делиться успехами и мыслями. Моя задача проще - среда создана исключительно с поддержкой языка ДРАКОН-Си. Ввиду этого я понимаю смысл каждой иконы в контексте программы на Си. Например, икона Адрес - должна содержать одну из меток, на которую надо перейти методом goto. Что я сделаю для пользователя? Я предоставлю ему список меток, которые он уже объявил в иконах "Имя ветки". Пользователь с радостью, отказавшись от ручного ввода такой многословной метки как Initialization_of_matrix_column, найдёт эту метку в списке, кликнет на неё и метка автоматически занесётся в поле со значением ключа текст2 иконы Адрес (о текст1 и текст2 читайте выше, если потеряли нить). Другой пример. Пользователь объявляет формальные параметры. В параметрах содержится список подключаемых библиотек (include), определение констант (define), описание структур (struct [имя]{ ... }), глобальные переменные (int Begin = 0;). Как минимум, я предлагаю пользователю вводить подключаемые библиотеки в другом текстовом поле, чтобы не писать лишнего. В итоге, пользователь может в поле просто написать "stdio stdlib locale wondows" вместо "#include <stdio.h> #include <stdlib.h>..." и т.д.
Чтобы убедиться в полноте и целесообразности моих попыток помочь пользователю в программировании, я проверял информацию у Кернигана и Ритчи.
|