Спасибо. Я даже сделал там поиск - и обнаружились еще несколько дискуссий с весьма примечательной динамикой позиций.

Ведущий теоретик там Илья Ермаков. И вот как трансформировалась его оценка HiAsm:

1. ...обычная программёрская поделка, "давайте на досуге поковыряем левой пяткой в правой ноздре" По поводу собственно подобных систем - героически решают проблемы, часть которых решена в нормальном инструментарии; другая часть - над чем люди в Comp. Sc. много лет уж работают с переменным успехом; третья часть - которые вообще надуманы (С++-сы всякие нормальному прикладнику нафиг не сдались, не до них; отсюда делается ложный вывод, что нужно вообще освобождать их от программирования; только в любом инструменте программирование попрёт из всех дыр рано или поздно). Аффтарам подобного сначала учить теорию и историю отрасли.
http://forum.oberoncore.ru/viewtopic.php?f=7&t=1392&hilit=hiasm&start=80

2. БлэкБокс сам по себе опирается на механизмы, подобные описанным RAD, только они очень удачно отделены от логики программы. "Суп" из кода на простом для освоения и эффективном языке - отдельно, "мухи" из составных документов и графических компонент - отдельно. Связку между ними обеспечивает среда. ...просто дело в том, что идея "визуального программирования" как построение алгоритмов графическими схемами слабо согласуется с идеологией виртовских языков. Точнее говоря, никак не согласуется... Если у кого-то появится желание "клонировать смесь коровы с помидором" - пожалуйста, никаких препятствий к сему нет...
Лично я ничего по этому поводу сказать не могу...
По мере роста сложности задачи графическое представление теряет свою наглядность и становится все более громоздким...
Работать с сотнями объектов, имеющими многомерные связи, в двумерной плоскости - это превращается в дурдом...
Попытайтесь описать n-мерный гиперкуб плоским рисунком, вместо символьного уравнения. Или спроектировать современный процессор графически, вместо использования символьного VHDL.
http://forum.oberoncore.ru/viewtopic.php?f=26&t=266&hilit=hiasm

3. Сама по себе разработка (давно наслышан) - как just for fun разработчиков - любопытная. Вполне может быть, что в каком-то звене сборочной разработки или конфигурирования готовых приложений она могла бы найти своё место.
Как инструментарий программиста её позиционировать нельзя. Она вводит жёсткий барьер между работой в ней и непосредственно уровнем программирования ниже. На определённом этапе сложности задач не будет возможности мягко и постепенно (в нужных местах) уходить на слой абстракций ниже. Т.е. с точки зрения любых долгосрочных целей - просто тупик (ровно по той же причине, по какой тупик - Scratch-и, "Алисы", Флеши в школах... Кстати, эту проблему при обсуждении на недавней конференции в Новосибе многие педагоги поняли и согласились).
Не лишне повторить и повторять дальше - нет реальных альтернатив Оберону, как общеобразовательному базису для всех, кому надо программировать без погружения в ИТ - т.е. делать исполняемые реализации своих идей. Аккумулированный в этом языке аппарат - как дифференциальное исчисление в математике.
Но высокоуровневые средства проектирования над языком - это тоже хорошо. Но, увы, HiAsm взял не такое направление.
http://forum.oberoncore.ru/viewtopic.php?f=26&t=1758&sid=a9a939fa6f4e8c5f47c7fc36238c2030

4. Я не считаю HiAsm - как проект, как исследование, как работу... - тупиком. САПР над языками программирования - это, по моему мнению, хороший путь, хотя конкретно абстракции HiAsm несколько однобоки (а они одинаковы, кстати, в таких САПР - и в Lab View, и в Microsoft Robotics Studio, и в российском имитационном пакете AnyLogic - потоки данных. Dataflow - это очень хорошо. Как один из срезов описания системы. Но - только один. К тому же эти инструменты чрезмерно поощряют - психологически поощряют "кобминаторику", сборку методом тыка и экспериментов, лично я бы хотел видеть САПР, которая буквально вынуждает к постепенному систематическому проектированию, пошаговой детализацией с уточнением).
Возвращаясь к тупику: надо понимать моё выссказывание так. Выбор инструмента класса HiAsm (а это целый класс достаточно по идеологии похожих) для школьного образования - тупиковый. В условиях ограниченности ресурсов - времени, сил педагогов и т.п. - основной инструмент должен быть "на вырост" на много лет вперёд, вплоть до середины ВУЗа. Он должен быть один, универсальный, расширяемый, сквозной. Остальное может довешиваться сбоку, если условия конкретного уч. заведения позволяют. А так: ХайАсм - хороший проект. Можно пожелать авторам успеха. Лучше даже в переплавке и развитии вынесенного опыта, чем в непосредственно разработке системы. Нельзя прикипать душой к первым прототипам, их надо уметь выкидывать.
http://forum.oberoncore.ru/viewtopic.php?f=26&t=1758&sid=a9a939fa6f4e8c5f47c7fc36238c2030

5. Кстати, независимо от интереса к Блэкбоксу в целом, настоятельно советую познакомиться с его способом организации форм и элементов управления. Скачайте http://store.oberoncore.ru/BlackBox/15/blackbox15re.7z, нажмите F1 и в открывшейся карте документации (на русском) найдите раздел "4. Формы".
Никакого ООП. Школьники могут разрабатывать уже со 2-3 занятия в ББ, полностью понимая принцип, а не следуя дебильным учебникам "Щёлкните 2 раза и впишите текст в обработчик".
(замечу, что формы-контролы - только узкий частный случай ББ-шной графики, поэтому их "ограниченность" не является проблемой, если нужно - выходим на уровень ООП-библиотеки составных документов и работаем с ней).
Вычисления и управление - это две стороны в программировании. Какие-то задачи тяготеют больше к преобразованиям данных, какие-то - к описанию поведения. Избавить разработчика от описания последовательности действий в одном случае может осчастливить, в другом - сделать адекватное программирование вообще невозможным. Огромный класс задач требует описания поведения, как алгоритма, автомата, процесса, протекающего во времени. И рисованием зависимости по данным тут не обойдёшься. (Даже чистые задачи на обработку данных превращаются в сильно завязанные на поведение, как только они масштабируются до уровня серверной обработки, онлайн-сервисов и т.п. Там на стыке - взаимодействия, взаимодействия, протоколы, протоколы, протоколы... А любое сложное взаимодействие - это алгоритм, а не просто поток данных.)
http://forum.oberoncore.ru/viewtopic.php?f=26&t=1758&start=20

6. Сопоставлять HiAsm и сам по себе язык Дракон вообще нельзя. У Вас - инструмент, позволяющий конструировать ПО; Дракон сам по себе - просто язык спецификации одного из аспектов - управляющей логики. И в этом смысле существенно отличие - у Вас обычная структурная управляющая логика (вложенность блоков - "ниточка"), в Драконе - более общая автоматная логика, которая для сложного поведения (не обрабатывающего данные, а интерактивного) более подходит... Подход HiAsm ясен и интересен, но можно заходить и с других сторон по каждому вопросу.
http://forum.oberoncore.ru/viewtopic.php?f=26&t=1758&start=40

Такая динамика происходила в ходе полемики со многими сторонниками HiAsm, особенно аргументированно дискутировал Галков.
А наиболее ярко высказался Starant:
Чувак, я тоже подсел на HiAsm. Вещь просто суперская. Видно сразу, что делал человек у которого руки растут из правильного места и голова работает в нужном направлении. За этой идеей большое будущее, будущее в котором не будет места программистам работающими секретаршами-машинистками. Современные программисты мыслят также как и программисты 50-х годов: для них набор программного кода в текстовом редакторе это - фетиш, ритуал, идолопоклонство.
Просто ВВ еще не пришло время уходить из "программерского дома", слишком твердо он стоит на своих ногах. Лично у меня на машине стоят ВВ, HiAsm и SharpDevelop.
HiAsm forever! and BB maybe too. http://forum.oberoncore.ru/viewtopic.php?f=26&t=266&hilit=hiasm
И rus.24bb.ru добавил:
Мне приятно что и в России кто то может мыслить не шаблонно и не писать в 1000 раз аналог MS Notepad, или компилятор Паскаля. Может и наша земля своих Стивов Джобсов рождать
http://forum.oberoncore.ru/viewtopic.php?f=7&t=1392&hilit=hiasm&start=80