Помимо Справки и FAQ хотелось бы узнать больше о системном представлении программ в HiAsm.
Может, были когда-то дискуссии о концепции, может, какие-то теоретики программирования вдохновили Дилму и его соратников?
Ну, не бывает культурного вакуума, когда нечто рождается из ничего.
Впрочем, Ахматова с этим не согласилась бы:
"Когда б вы знали, из какого сора.
Растут стихи, не ведая стыда...
Как одуванчик у забора,
Как лопухи и лебеда".
Но надежда еще живет - она ведь умирает последней... ;0)
Потому спрошу приверженцев HiAsm: справедливо ли следующие тезисы:
Каждый компонент, включаемый в схему, представляет собой черный ящик (хотя через команду "Исходник компонента" всегда можно посмотреть его код на Паскале, а команду "Конфигурация компонента" - версию, авторов и список настроек). Слева направо через него течет поток событий (сигналов, чисел, символических наборов), которые компонент преобразует согласно своей функции. На верхнюю сторону квадрата через точки поступают внешние параметры функции, а по точкам на нижней стороне параметрические выходы компонента воздействуют на другие компоненты.
Иными словами, по горизонтали связаны событийные входы-выходы, а по вертикали - параметрические. По горизонтали разворачивается основной информационный процесс программы, ведущий от исходных входных данных к результатам. А вертикальный срез состоит в статических установках программы, дополняющих ее структуру, и процессах управления параметрами компонентов.

KomKon, правильно поставленный вопрос содержит 90% ответа В вашем вопросе все 100% (некоторые компоненты сами "запрашивают" данные сверху, и даже формируют событие в верхнем компоненте - исключение, которое лишь подтверждает правило )

все верно. Подробное описание работы схемы приведено в статье Основы


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

KomKon, Вам может быть будет интересно почитать дискуссию, которая прошла на другом форуме, но затрагивала вопросы HiAsm в его теоретическом аспекте.

http://forum.oberoncore.ru/viewtopic.php?f=26&t=1758&start=20

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

Ведущий теоретик там Илья Ермаков. И вот как трансформировалась его оценка 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

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

С чем не получается согласится это с

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

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

Но это уже немного совсем другая история.

Вообще то учителя просто не знают что такое HiAsm, я однажды на информатике спросил об нем учителя, а она меня спросила "а что это такое и как это работает", хотя преподает уже 10 лет

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

Ну, это естественно, всегда есть нормальный и психованный, дурак и умный,