Alexey_Donskoy писал(а):
Лень и недостача академической привычки обзора литературы
Та же самая фигня.
Больше узнаешь от коллег (типа: посмотри там-то), чем самостоятельным целенаправленным поиском.
Alexey_Donskoy писал(а):
Крайне большой минус инкапсуляции важных свойств внутри кубиков (необходимо открывать спец.редактором, теряя визуальную связь с рабочей схемой)
Скажу больше - это похоже на "пятую" сторону на кубике. У нас нормально сделана инкапсуляция с четырьмя сторонам. С "пятой" - сложнее. Начинаешь вникать - понимаешь, что это просто сокрытие неких действий при конструировании объекта. И если на анатомию создания этого кубика смотреть изнутри - это немного сложней, чем снаружи.
Но если я выйду с предложением ликвидировать сию сущность - мне устроят линчевание. Даже пробовать не буду, знаю заранее
Потому-что с ней УДОБНЕЕ. Экспериментальный факт, черт бы его побрал
Alexey_Donskoy писал(а):
Как следствие - невозможность адекватной распечатки. Повторяю - крайне большой минус.
Можно ли с ним что-то сделать?
Честно скажу - ни разу ничего не распечатывал. И как-то необходимости в этом не испытывал. Так получилось, я не виноват
Минус вижу: для "обмена знаниями" в виде схем нужна Среда - очень много заточено под интеррактивность. Этой проблемы нет у нас на форуме - она у всех есть. А здесь... Не настолько она еще вылизана, чтобы я направо и налево раздавал рекомендации ее поставить (был и отрицательный опыт). Хотя это был бы выход....
Что сделать - не знаю пока. Если у Вас будут предложения, давайте подумаем...
Сразу скажу: переход на черно-белое изображение, и выплескивание всей информации (которую мы незаметно получаем в режиме интерактивности) на лист - резко сужает поле восприятия, помещающееся на монитор.
Инструменты для дополнительного рисования, или фиксации хинтов - есть, конечно же. Если что-то еще из этой серии - ну конечно надо добавлять, наверное. Хотя это и не самое принципиальное для будущего среды, как мне кажется....
Alexey_Donskoy писал(а):
Да, можно менять визуальное изображение в соответствии с текущим выбором слоя (слоёв) метаинформации.
Ну и т.д., целая куча рассуждений на эту тему...
У меня такие же мысли про слои возникали. Если мы говорим про слои в CAD-овском смысле.
Визуализация - это гениально. Почему - Владимир Даниелович нам открыл глаза. Но мы дошли уже до той стадии, когда ее может оказаться избыточно... И сейчас мы не все показывам - обработчики виндячей очереди сообщений, соотношение parent-child между контролами, их Z-координаты...
А если программист уже достаточно умен, чтобы вмешаться в это безобразие?
Есть еще и вариантность программы, которую гипотетически можно было бы достигнуть меняя комбинацию активных слоев.
Например, редактор формы можно было бы выполнять как компиляцию "на лету" определенного "варианта" программы.
Или отладочные варианты.
Про кучу рассуждений.
Ну давайте по-одной. Спокойно, не торопясь - всю кучу и поднимем
Alexey_Donskoy писал(а):
Трудно сделать хороший отладчик для такого подхода
Но можно.
То, чего сегодня сделано - мне уж очень хорошим не кажется.
И даже - НУЖНО. Он мог бы выполнять познавательно-обучающую функцию.
Про черепашку (паровозик) надо не рассказывать, а показывать ее. Вместе с "веревочкой" - или, может быть, что-то более удачное в восприятии.
Alexey_Donskoy писал(а):
Как это ни странно, в текстовом представлении на единицу площади экрана умещается больше информации (и это привлекательно, но только до тех пор, пока ВЕСЬ текст вписывается в экран).
Не скажу, что я каждый день занимаюсь портированием из текста в схему и обратно... Но кое-что портировать и сравнивать - приходилось.
Получается соотношение строк кода к количеству элементов - 1:1. С точностью "до порядка", как говорится. Но уж точно не в большие разы.
У вас 100-200 строк кода в тестовом редакторе умещаются на один экран ???
У меня - нет. А схема, с таким же количеством элементов - легко.
Да, у нас значительно (в сравнении с ДРАКОНом) все поджато. Когда-то давно (я не помню - "старики" рассказывали) у нас между точками элемента было 10pt, и иконка элемента - 32x32. А сегодня - 7pt, и иконка - 24x24.
Это похоже на физический предел минимизации, и ставка делается на интерактивность.
Хорошо это или плохо... Не знаю, но перед таковым заключением, как минимум - следует "пощупать". Мне кажется
Alexey_Donskoy писал(а):
Нет, некоторые вещи (скажем, последовательность действий) в HiAsm выглядит не всегда достаточно наглядной...
Адаптироваться под новичка мне уже очень трудно. Но смутно припоминаю, что 5 лет назад мне тоже было очень не просто. Модель "привязанной черепашки" мне никто не излагал. Разбирался методом "допроса Автора с пристрастием".
Законченного (достойного помещения на скижаль) описания у нас еще нет. Ловлю себя на том, что я это делаю не первый раз, и каждый раз придумываю все заново.
Однако опыт показывает, что это проходит довольно быстро. Pirr - не единственный, кто может сказать "
мы на нем думаем" - поверьте.
Можно ли лучше, как лучше - достойно обсуждения.
Alexey_Donskoy писал(а):
обязаны быть гомеоморфными (т.е. легко преобразуемыми друг в друга), коль скоро они описывают одну и ту же сущность - алгоритм
Алексей, ну я бы так не горячился
Однажды, чисто для прикола, попросил знатока C++ изобразить на нем,
простой как топор, Дельфячий тип данных
procedure of object ((btw: вот я говорил, что у нас не GOTO, а CALL... А ведь точнее будет - вызов метода объекта, который лежит себе спокойненько в одном из полей класса))
Сколько я наслушался... И про технологию шаблонов, и про QT-шные слоты/сигналы, и про каких-то "делегатов"
А Вы про взаимопреобразование