OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 16:40

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Среда, 26 Август, 2009 22:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Спасибо, очень интересно!

Несколько слов:

1) Термин "Черепашка" Вы увидели на форуме, но он никаким образом к Дракону не относится. Имеется в виду черепашья графика, учебный исполнитель, который поворачивается и ползает, оставляя след. Традиционно применяется в обучении с младших классов (среда Лого и т.п.) Таковой есть для Блэкбокса, и детишки пишут на Компонентном Паскале гоняние Черепашки, осваивая процедуры, циклы и др. базовые кирпичики. http://www.inr.ac.ru/~info21/troitsklic ... ojetap.htm

2) По поводу отличий - тут всё ясно. Сопоставлять HiAsm и сам по себе язык Дракон вообще нельзя. У Вас - инструмент, позволяющий конструировать ПО; Дракон сам по себе - просто язык спецификации одного из аспектов - управляющей логики. И в этом смысле существенно отличие - у Вас обычная структурная управляющая логика (вложенность блоков - "ниточка"), в Драконе - более общая автоматная логика, которая для сложного поведения (не обрабатывающего данные, а интерактивного) более подходит.

К сожалению, нет сейчас времени отвечать подробнее... Подход HiAsm ясен и интересн, но можно заходить и с других сторон по каждому вопросу :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Август, 2009 22:23 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
О, вот, наконец, я понял, что такое HiAsm! :)

(Ностальгически) Очень похоже (деревом) у меня предсталялась матричная формула (с циклами FOR и т.п.) в подсистеме символьного преобразования (лет 20 назад) :)

Скрещивание потоков данных и алгоритмических нитей имеет место у меня сегодня в системе типа Soft Logic, правда, я не додумался до элегантной идеи их разделения по вертикали/горизонтали.

Так что, оказывается, очень близок должен быть мне HiAsm :) А я до сих пор ничего не знал про него, кроме того, что он есть! Лень и недостача академической привычки обзора литературы...

Замечания по опыту проектирования и эксплуатации аналогичных визуальных систем.

1) Крайне большой минус инкапсуляции важных свойств внутри кубиков (необходимо открывать спец.редактором, теряя визуальную связь с рабочей схемой). Как следствие - невозможность адекватной распечатки. Повторяю - крайне большой минус.
Можно ли с ним что-то сделать?
Нет, инкапсуляция в том или ином виде неизбежна в сложных проектах.
Да, можно использовать эргономический компромисс вроде Property Editor в той же Дельфе.
Да, можно менять визуальное изображение в соответствии с текущим выбором слоя (слоёв) метаинформации.
Ну и т.д., целая куча рассуждений на эту тему...

2) Трудно сделать хороший отладчик для такого подхода.
а) тут многие вообще против отладчика в принципе :)
б) возможности отладчика потенциально выше, поскольку текущее состояние в известной мере уже визуализировано.

3) Как это ни странно, в текстовом представлении на единицу площади экрана умещается больше информации (и это привлекательно, но только до тех пор, пока ВЕСЬ текст вписывается в экран).
Возможно, интерактивная система построения текста (которой занимается Сергей К с форума Компьютерры), является интересно перспективной штукой.

4) Да, в графе HiAsm гораздо удобнее (автоматически, по определению) решаются многие вещи, требующие тщательного конструирования в тексте или блок-схеме алгоритма (в т.ч. в драконе).
Нет, некоторые вещи (скажем, последовательность действий) в HiAsm выглядит не всегда достаточно наглядной...

5) если я правильно понимаю, то HiAsm достаточно близок к функциональному программированию... по форме...
К сожалению, я совсем не математик, я могу только предположить, что структуры тех или иных визуальных представлений (текст, блок-схема, HiAsm) обязаны быть гомеоморфными (т.е. легко преобразуемыми друг в друга), коль скоро они описывают одну и ту же сущность - алгоритм.
Однако нет никакой ясности, можно ли получить из этих ортогональных (?) представлений что-то совокупное, или среднее, или переключаемое по желанию для той или иной когнитивной задачи и насколько всё это будет хорошо...

Вот такие сумбурные первые впечатления...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 27 Август, 2009 21:39 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Galkov, - Вы прямо статью написали! Конечно, лучше бы в ваш тект побольше поясняющих скринов с примерами вставить, для лучшего симультивного восприятия :)
Кстати я уже говорил, что думаю на HiASM и это написал до прочтения книги "Как улучшить работу ума". Видимо симультивная часть мозга у меня лучше работает. Сложно описать те чувства которые возникают в процессе создания программы в среде HiASM. Но попробую описать: в голове возникает идея, выставляю нужные мне элементы на рабочее поле, расставляю связи, устанавляваю последовательность действий, жму "Компилировать" и вижу результат своих действий. Все занимает секунды/минуты. Мозг свободен для творческого развития возникшей идеи и не обременен синтаксисом языка программирования, расстановкой запятых, придумыванием названий переменных или названиям для Label, Edit, Button.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 00:29 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Илья Ермаков писал(а):
Scratch-и, "Алисы", Флеши в школах...

Scratch знаю. А что такое "Алиса"? Можно ссылку? А под Флешами понимаются Flash-ролики?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 01:31 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Термин "Черепашка" Вы увидели на форуме, но он никаким образом к Дракону не относится
Не, ну я надеюсь, что употреблял в правильном таки смысле. У нас на форуме в большей степени употребим термин "паровозик"
Например сегодня, на вопрос "чего нельзя сделать в HiAsm", отвечал бы примерно так: "И сложные алгоритмы с сильнодинамическими графовыми структурами фигу Вы нарисуете на HiAsm"
Хотя и закопипастено вовсе не с обсуждения Дракона. Зато сказано хорошо :)
При этом добавил бы, что у нас не сборщик мусора есть проблема, а отсутствие некоторых визуальных механизмов ООП. Со структурированием по Дейкстре - проблем как раз нет.
Проблемы в в когнитовной эффективности таких механизмов, если их начинать придумывать. Серьезного обсуждения требует с коллегами, которые а) в этом разбираются б) понимают их необходимость.
И в исполнительной эффективности в стандартном пакете.
Клинч такой получается: механизмы не делаются из-за отсутствия эффективности. А работа над кодогенерацией без устоявшегося Front-End-а, тоже не самое разумное занятие.
Называется - эффект Шанхая, наверное...

Илья Ермаков писал(а):
Сопоставлять HiAsm и сам по себе язык Дракон вообще нельзя
Не соглашусь с Вами, Илья
Все-таки про ДРАКОН я кое-чего уже знаю...
Во-первых, на ДРАКОНе можно собирать реальный код методом сборки текста. Коллега Рэйлвэй Каген выложил проект для PIC-а. У меня тоже есть проект, сделанный на AB (см скрин), который я хочу потренировать на ДРАКОНе
Во-вторых, проведение кодогенерации вообще, и оптимизационных мероприятий - в частности, можно организовать как плагин (что в HiAsm и сделано). Не думаю, что выставить интерфейс, возвращающий информацию о элементах схемы - есть сложная задача. И что договориться с Геннадием об этом будет невозможно.
В третьих, от HiAsm можно "отрезать" этот плагин кодогенерации, и он тоже станет "метаязыком".

Просто, чтобы сравниванивать, не надо затрагивать качество генерируемых кодов, и рассматривать только Front-End - вот и вся проблема.
Вот я и сравниваю AB, ДРАКОНа, HiAsm...
И возникла, в результате таковых сравнений, у меня гипотеза: чем больше мы пытаемся улучшить работу ума, тем большие требования мы накладываем на кодогенерацию.
Приглядитель к скрину для AB - там два входа в цикл. Портируя это в ДРАКОН, я буду вынужден это убрать и завести некий логический артефакт, снижающий эффективность. Т.е., просто сборка текста - уже минус. Ну ладно, не супер-задача, справимся при наличии менее банальной кодогенерации.
А HiAsm по-мощнее будет. Мне пока так кажется. И там я пока просто не знаю какой компилятор и выбрать - не умеют они делать то, что мне надо. Есть мысли о перспективном пути конечно же, но сложные они какие-то...

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

Илья, интересный Вы человек :D
Когда, при обсуждении необходимости GOTO в ЯВУ, чела фэйсом по тэйблу возили, чтобы он выложил пример более адекватного с помощью GOTO представления алгоритма - Вы ведь не не вспомнили про Автоматы.
А здесь - сразу же. Хотя спасибо, действительно интересно :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 09:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Илья, интересный Вы человек :D
Когда, при обсуждении необходимости GOTO в ЯВУ, чела фэйсом по тэйблу возили, чтобы он выложил пример более адекватного с помощью GOTO представления алгоритма - Вы ведь не не вспомнили про Автоматы.
А здесь - сразу же. Хотя спасибо, действительно интересно :)


Ну, дело в том, что автомат и GOTO - разные вещи. Разного уровня. Отстаивание GOTO/BREAK чаще всего связано просто с неумением строить нормальные циклы (viewtopic.php?f=35&t=1483), и только в редких случаях с тем, что человеку нужна автоматная логика (которая обеспечивается и без GOTO). Поэтому в первую очередь и спрашивется "а зачем.."

Тут ещё полезно прочитать книгу Хоара "Взаимодействующие последовательные процессы".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 09:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
TAU писал(а):
Илья Ермаков писал(а):
Scratch-и, "Алисы", Флеши в школах...

Scratch знаю. А что такое "Алиса"? Можно ссылку? А под Флешами понимаются Flash-ролики?

Еле нашёл... Она, оказывается, через C пишется :)
http://www.alice.org/

А под Флешами - да. Столь любимые многими учителями флешки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 10:24 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
и только в редких случаях с тем, что человеку нужна автоматная логика
Но эти случаи - ЕСТЬ.
И Вы совершенно справедливо мне о них напомнили.
Ну а агитировать-то "за Советскую Власть" меня не надо :D
Ибо у нас все начинает произрастать не из GOTO, а из структурирования по Дейкстра. Потому-то как раз и не оказалось визуальной конструкции, аналогичной силуэту.
А вот специально отметить, я хотел бы следующее: тут логичней был бы не холивар, а конструктивный подход.
Вы мне показали, я с Вами согласен, и готов вводить новую "визуальную синтаксическую конструкцию"
Аналогичный подход возможен, между прочим - и в ЯВУ. Заведите себе синтаксическую конструкцию, заменяющую комбинацию WHILE-CASE. Придумайте другое название для GOTO, который меняет состояние... Ну не знаю, CHANGE_STATE может быть...
Может быть и инкапсуляция состояний получится, и НКА... Думать надо.
Поговорите Виртом, наконец ((шутка юмору конечно же... Если не забывать, что в каждой шутке есть доля... шутки))
Основания:
  • Это будет более "читамо" в когнитивном аспекте.
  • Есть у меня серьезные сомнения, что компилятор распознает комбинацию WHILE-CASE, и хитромудрые выходы из него, с изменением вектора состояния - соптимизирует в простой GOTO.
  • Во многих случаях, именно попытки оптимизации кодов являются побудительным мотивом для использования GOTO программистами. А оставление GOTO в языке, является росписью авторов языка в неумении самостоятельно проводить адекватную оптимизацию.
  • Генерация кодов (таблиц) для автоматов - это отдельная, почти наука. Вспомните, чем занимаются всякие там Flex/Bison-ы, и прочая нечисть. Тут вам и компрессия таблиц, и преобразование НКА в ДКА, ....


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 13:45 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Alexey_Donskoy писал(а):
Лень и недостача академической привычки обзора литературы
Та же самая фигня.
Больше узнаешь от коллег (типа: посмотри там-то), чем самостоятельным целенаправленным поиском.

Alexey_Donskoy писал(а):
Крайне большой минус инкапсуляции важных свойств внутри кубиков (необходимо открывать спец.редактором, теряя визуальную связь с рабочей схемой)
Скажу больше - это похоже на "пятую" сторону на кубике. У нас нормально сделана инкапсуляция с четырьмя сторонам. С "пятой" - сложнее. Начинаешь вникать - понимаешь, что это просто сокрытие неких действий при конструировании объекта. И если на анатомию создания этого кубика смотреть изнутри - это немного сложней, чем снаружи.
Но если я выйду с предложением ликвидировать сию сущность - мне устроят линчевание. Даже пробовать не буду, знаю заранее :lol:
Потому-что с ней УДОБНЕЕ. Экспериментальный факт, черт бы его побрал

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 писал(а):
обязаны быть гомеоморфными (т.е. легко преобразуемыми друг в друга), коль скоро они описывают одну и ту же сущность - алгоритм
Алексей, ну я бы так не горячился :D
Однажды, чисто для прикола, попросил знатока C++ изобразить на нем, простой как топор, Дельфячий тип данных procedure of object
((btw: вот я говорил, что у нас не GOTO, а CALL... А ведь точнее будет - вызов метода объекта, который лежит себе спокойненько в одном из полей класса))
Сколько я наслушался... И про технологию шаблонов, и про QT-шные слоты/сигналы, и про каких-то "делегатов"
А Вы про взаимопреобразование :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 16:09 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Galkov писал(а):
Однажды, чисто для прикола, попросил знатока C++ изобразить на нем, простой как топор, Дельфячий тип данных procedure of object
((btw: вот я говорил, что у нас не GOTO, а CALL... А ведь точнее будет - вызов метода объекта, который лежит себе спокойненько в одном из полей класса))
Сколько я наслушался... И про технологию шаблонов, и про QT-шные слоты/сигналы, и про каких-то "делегатов"
А Вы про взаимопреобразование :)


Просто, видимо, человек хорошо понимает как это работает "изнутри". Причем в общем случае (closure), а не какой-то частный случай типа банального вызова метода объекта.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 28 Август, 2009 18:56 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Galkov писал(а):
Alexey_Donskoy писал(а):
обязаны быть гомеоморфными (т.е. легко преобразуемыми друг в друга), коль скоро они описывают одну и ту же сущность - алгоритм
Алексей, ну я бы так не горячился

Отнюдь. Я просто выделил поразившую меня мысль.
Ведь, действительно, если взять древовидное представление алгоритма HiAsm и, скажем, Дракон, то преобразование их друг в друга обязано быть возможным, какими бы разными ни казались эти формы представления.

Другой вопрос в том, что при этом в обоих случаях придётся вводить артефакты преобразования, которые не имеют отношения к информационной модели (алгоритму).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Август, 2009 00:41 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Илья Ермаков писал(а):
Огромный класс задач требует описания поведения, как алгоритма, автомата, процесса, протекающего во времени. И рисованием зависимости по данным тут не обойдёшься

Точно - зато можно нарисовать временные соотношения между процессами (циклограмму).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Август, 2009 00:44 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Илья Ермаков писал(а):
TAU писал(а):
Scratch знаю. А что такое "Алиса"? Можно ссылку?

Еле нашёл... Она, оказывается, через C пишется :)
http://www.alice.org/

Спасибо! Интересная штучка. С моей точки зрения, больше всего действительно похожа на Squeak и Scratch.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Август, 2009 01:05 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Уважаемый Galkov! Видимо, Вы являетесь автором проекта HiAsm. Хочу выразить Вам свое восхищение - когда я на него натолкнулся в рамках НИР по графическим языкам программирования, он произвел на меня весьма положительное сильное впечатление, и родил чувство гордости за то, что такая система была создана нашим (русскоязычным) автором.

Galkov писал(а):
у проекта есть некая история


На сайте Hiasm.com есть перечисление некоторых "аналогов" - видимо, сред визуального программирования. Если Вам интересно, могу дать информацию о некоторых других - ту, которую собрал в 2008 в рамках вышеупомнятой НИР.


Последний раз редактировалось TAU Воскресенье, 30 Август, 2009 00:36, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Август, 2009 08:27 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
TAU писал(а):
Уважаемый Galkov! Видимо, Вы являетесь автором проекта HiAsm. Хочу сразу выразить Вам свое восхищение - когда я на него натолкнулся в рамках НИР по графическим языкам программирования, он произвел на меня весьма положительное и сильнео впечатление, и родил чувство гордости за то, что такая система была создана нашим (русскоязычным) автором.
У Вас на сайте есть перечисление некоторых "аналогов" - видимо, сред визуального программирования. Если Вам интересно, могу дать информацию о некоторых других - ту, которую собрал в 2008 в рамках вышеупомнятой НИР.

Обязательно давайте!!!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 29 Август, 2009 20:47 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
TAU писал(а):
Уважаемый Galkov! Видимо, Вы являетесь автором проекта HiAsm.

Galkov - не автор HiASM, он пользователь, но.. очень старый пользователь HiASM. Я например - молодой пользователь (около 5 месяцев пользуюсь HiASM).
Автор проекта HiASM - Dilma.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Август, 2009 00:22 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Alexey_Donskoy писал(а):
5) если я правильно понимаю, то HiAsm достаточно близок к функциональному программированию

HiAsm - комплексная система, воплощающая "в одном" сразу несколько подходов к визуальному программированию. В том числе - описание потоков данных. Естественно, графический язык, в котором упор сделан на описание потоков данных (как правило, представляемых стрелками) между обработчиками (функциями), близок к функциональному программированию.

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

Дело в том, что "одна и та же сущность" - это классический алгоритм (по Маркову, Тьюрингу или Чёрчу), или, говоря другими словами, вычислительный. А еще могут быть управляющие алгоритмы (например, не подразумевающие вообще останова, т.е. фиксации некоторых "выходных данных"). И даже - еще более отличающиеся - управляющие алгоритмы реального времени.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Август, 2009 00:23 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Pirr писал(а):
TAU писал(а):
Уважаемый Galkov! Видимо, Вы являетесь автором проекта HiAsm.

Galkov - не автор HiASM, он пользователь, но.. очень старый пользователь HiASM. Я например - молодой пользователь (около 5 месяцев пользуюсь HiASM).
Автор проекта HiASM - Dilma.

Я подумал, это одно и то же лицо :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Август, 2009 00:34 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 372
Валерий Лаптев писал(а):
TAU писал(а):
могу дать информацию о некоторых других - ту, которую собрал в 2008 в рамках вышеупомнятой НИР

Обязательно давайте!!!

Хммм... Ну, можно вырезать из оглавления:

Цитата:
4. Системы визуального построения пользовательского интерфейса 24
4.1. Системы визуального конструирования интерфейса на основе компонент 24
4.2. VUFC 26

5. Учебные языки 30
5.1. Scratch 30
5.2. Интерпретатор блок-схем 32
5.3. Sivil 35
5.4. VIPR 36

6. Языки, ориентированные на состояния 38
6.1. Язык SDL 38
6.2. Диаграммы состояний в UML 43
6.3. Языки Grafcet и SFC (МЭК61131-1) 44
6.4. Язык Argos 48

7. Языки описания потока управления (control flow) 50
7.1. Графические схемы (блок-схемы) алгоритмов и программ 50
7.2. Технология графосимволического программирования ГРАФ 52
7.3. Диаграммы деятельности и активностей в UML 55
7.4. Язык потоковых диаграмм FC (Flow Chart) системы IsaGraf 59
7.5. Язык ДРАКОН и технология ГРАФИТ-ФЛОКС 60
7.6. Язык Р-схем 62
7.7. Algorithm Builder для микроконтроллера Atmel 63

8. Языки графического описания структур данных 65
8.1. Язык ER-диаграмм и стандарт IDEF1X 65
8.2. Диаграммы классов UML 67

9. Языки описания потоков данных (dataflow) 69
9.1. LD (Ladder Logic, МЭК61131-3) 70
9.2. FBD (МЭК61131-3) 71
9.3. DFD (Data Flow Diagram) 73
9.4. LabVIEW 75
9.5. Simulink 77

9.6. Prograph 79
9.7. Ptolemy 82
9.7.1. Discrete-Events – DE 86
9.7.2. Giotto 86
9.7.3. Timed Multitasking – TM 87

10. Событийный подход 88
10.1. Графическое программирование в IBM Visual Age 88
10.2. Передача методов, данных и событий в системе HiAsm 92


Ну и еще можно упомянуть кое-что из не вошедшего в отчет по НИР - A-Flow, пи-схемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 30 Август, 2009 08:52 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
TAU писал(а):
Я подумал, это одно и то же лицо
Вот сколько не пытаюсь быть "аккуратным" в этом аспекте - ничего не получается :D
На нашем форуме даже в подпись себе забил "В авторском коллективе не состоял, а такой же User, как и мы все :) "
Здесь же, даже явно указывал
Galkov писал(а):
Но смутно припоминаю, что 5 лет назад мне тоже было очень не просто. Модель "привязанной черепашки" мне никто не излагал. Разбирался методом "допроса Автора с пристрастием"
А познания мои являются лишь следствием привычки во всем разбираться до конца. Не более! НО, и не менее.
Нас этому учили. По прошествии десятков лет, понимаю, что учили-то - прежде всего этому. Школа у нас такая...
И даже возьму на себя смелость утверждать, что умею это делать. Мне это необходимо профессионально, хотя я и не являюсь профессиональным программистом.
А являюсь Инженером, которому HiAsm предоставил возможность "программировать без программистов". Практическую возможность, а не высокую идею о светлом будущем :)


TAU писал(а):
HiAsm - комплексная система, воплощающая "в одном" сразу несколько подходов к визуальному программированию. В том числе - описание потоков данных
Угу.
Если добавлю еще одну конструкцию "визуальнго синтаксиса", то это - еще один подход. Перекрывающий, до какой-то степени, Visual State Studio от IAR System (они говорят, что это представление State Flow Automat с помощью UML-диаграмм).


TAU писал(а):
Хммм... Ну, можно вырезать из оглавления:
Ну как раз и стало интересней посмотреть Весь анализ :)
Ибо: Лень и недостача академической привычки обзора литературы... - а тут, сделанный коллегой труд. По любому, превосходящий результаты нашей "лени"


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB