OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 21 Август, 2019 16:48

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




Начать новую тему Ответить на тему  [ Сообщений: 67 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Среда, 12 Август, 2009 01:53 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Иван Кузьмицкий писал(а):
Как вот, например, популярные шаблоны проектирования будут выглядеть в среде hiasm?

Хм... Ну если нам по башке за offtop не надают :)
Постейший способ объяснения у нас называется "моделью паравозиков"....
Ну вон рисунок от Pirr
Где-то чего-то когда-начинается, естественно
Ну вот, от кнопки прилетело событие в к левой точке элемента Math. Все, далее начинает функционировать именно Math (иконка на картинке - "+")
И пока он функционирует - линия, вызвавшая это функционирование считается занятой.
А в процессе функционирования, элемент может активизировать свои верхние/правые точки
Если конкретно здесь - первым делом верхняя левая, читает значение с элемента Edit.
Таже самая история - про занятость этой линии, пока функционирует Edit. Который в данной ситуации прост как сибирский валенок - внешней активности не проявляет, а просто возвращает строку, и всего делов. Элемент Edit освобождается, и, соответственно становится свободной и линия, которая активизировала элемент.

Далее, конкретно здесь - повторяется вышеописанная история со вторым Edit. Дословно, естественно.
Последним актом активности элемента Math - вызов события onResult, правая точка.
Кончилась активность Math - освободилась линия, которая его активизировала.

Ну в этой-то схеме на этом все и кончается, но теоретически - активность линии есть следствие внешнего проявления активности некого другого элемента. Ну а у всякого элемента есть свое "расписание" для активизации верхних/правых точек в ответ активирование какой-то из левых нижних. Всегда работает только одно событие - никаких чудес.

Кто такой HUB - да то же последовательное исполнение шампуров в Драконе. Только у нас это выполнено горизонтально почему-то... Что важно: если бы в схеме между кнопкой и Math стоял HUB, Math был подключен к верхней правой, ТОГДА активность второй точки HUB-а наступила бы только после окончания всего выше описанного безобразия
"Расписание" такое у HUB-а - сначала верхняя, потом ниже, потом еще ниже, и т.д.. "Потом" - означает после окончания активности предыдущей.

Вот собственно и вся наука, если по-большому счету-то.

Что такое If_Else: активизируются верхние точки (сначала левая, потом правая, манера у нас такая - у всех элементов слева направо или сверху вниз, если в персональной справке на элемент не указано иного), и одна из правых по результатам сравнения. Естественно - после.

Что такое For: активизируются верхние точки (сначала левая, потом правая), и далее - нужное количество раз правая onEvent. Тот же вышеупомянутый прикол про занятость - повтор не начнется пока не отработает ВСЯ алгоритмическая ветка, начинающаяся в onEvent. В отличие от ранее описанного, после окончания активности ветки, активизируется не "следующая в расписании элемента", а та же самая.

Ну и так далее, примерно в том же стиле.... Грубо говоря: на любой Ваш вопрос - любой наш ответ :)


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2931
Откуда: г. Ярославль
Пока не надавали за офтоп, всё ж уточню свой вопрос. Вот есть у меня абстрактный интерфейс, и три реализации, одна для MySQL, другая для SQLite, третья для Sedna. Можно ли визуально показать такую конструкцию?


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Коротко: сегодня такую конструкцию показать нельзя

Подробнее: "завтра" будет можно.
И выглядеть (видимо) это будет примерно так: среда поддерживает (в смысле - обязательно будет) элемент "объекто-указатель", у которого одним из св-в является класс элемента (грубо говоря - идент схемы, элемента, и т.п.). При выборе такого св-ва элемент меняет свое обличие - приобретает иконку (с неким оверлеем, естественно) и набор точек именно этого класса. Плюс к этому, этот набор точек обладает возможностью индивидуального "оптичивания". Если для левых/нижних точек это просто режим видимости на схеме, то для правых/верхних - это еще и изменение функциональности.... И вот как-то этой фишке я не очень нахожу аналоги в известных мне ЯВУ.
Грубо говоря, при активизации элемента через "сигнал" на левую/нижнюю точку ответные сигналы активности возникают на нашем элементе объекто-указателе, если мы "оптичили" эти точки в элементе. В противном случае - на элементе-оригинале (на который и указывает наш элемент)

Ну вот, есть три реализации - значит есть три конкретных элемента/мультика в схеме. Эти элементы имеют служебную нижнюю точку - Obj. Берем и загоняем контекст этой уже конкретной точки этого конкретного элемента (реализации) в наш элемент ObjLinker через служебную левую. Или напрямую соединяем точку Obj с служебной верхней элемента ObjLinker. Ну может не напрямую, а через переключатель GetIndexData......

Вот и все "как это будет выглядеть".... Но завтра.... :?


Последний раз редактировалось Galkov Среда, 12 Август, 2009 11:03, всего редактировалось 1 раз.

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

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Что же Вы всё про тупик, да про тупик? Слово такое вообще не из моего лексикона, и этот форум - не исключение. Тем более, применительно к визуальным средам.
Galkov писал(а):
Рэйлвэй Каген писал(а):
Батон крошил только на front и VCL'и помянул в общепринятом смысле
Тогда нужны разъяснения к "общепринятому смыслу".
Вы писали: "Повторять это с VCL-ками, конечно можно, но непродуктивно. Хотя бы с эргономической точки зрения"
"Не продуктивность VCL" в общепринятом смысле - это 300К на пустую форму. Что, в свою очередь, является прямым следствием применения методов ООП в BackEnd-е
Чистая логика, ничего личного :)
о VCL-ках: просто по буквам - Visual Component Library. Чистый английский, ничего личного. :)

Признаюсь, коробило, когда приходилось рефакторить или сопровождать код, в котором связи Событие->Метод заведены через инспектор. Пока въедешь в полную схему.. Поэтому всегда переносил их в текст модуля. Да, в HiAsm'е такие связи визуальные(понятно, что и другие - тоже визуальные). Уже легче. Но структуры в них тоже нет. Они просто видны и всё. Есть начало и конец.

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

Не помешало бы ещё упорядочить связи по заранее объявленным критериям. Упрощающим понимание для других. Представьте - один инженер даёт другому собранную "макетку" и при этом добавляет: "Там всё понятно." Это же черезчур аскетично. Тем более, в наше время. Поэтому обозначили "яркие точки" и предложили Вам заглянуть в разделы форума о визуальном структурировании. Ну, чтобы не излагать их ещё раз в этой теме :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2009 11:36 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Galkov, Вы как всегда многословны. Я даже не представляю как Вы на пальцах можете объяснять такие сложные вещи.
Вот прикреплю скриншот схемы сделанной в последней сборке HiASM. Эта схема сделана по всем правилам, и будет понятна всем (большенству) пользователей HiASM.


Вложения:
Комментарий к файлу: Если обратить внимание, то при наведении мышкой на интересующую точку, виден весь путь (красная жирная линия) к этой точке.
hiasm2.JPG
hiasm2.JPG [ 205.81 КБ | Просмотров: 10200 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2009 12:38 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Рэйлвэй Каген писал(а):
Что же Вы всё про тупик, да про тупик?
Хорошо, договорились, не будем употреблять таковое слово. Обоюдно. Ну и конечно извиняюсь, и прошу сделать скидку "на новичка" - по началу все коллеги "на одно лицо". Это пройдет.

Рэйлвэй Каген писал(а):
Чистый английский, ничего личного :)
Ну хорошо, VCL себе - и VCL.... Чего не понял: в чем таки заключается "но непродуктивно". Вижу, что чего-то не нравится, а не пойму чего

Рэйлвэй Каген писал(а):
Но структуры в них тоже нет. Они просто видны и всё. Есть начало и конец.
Хм... Ровно тоже самое можно сказать про любое дерево/граф
У нас элементы - узлы этого графа, связи - дуги. В любой момент исполнения всегда можно указать "активный в данный момент" путь в этом графе.
Нет структуры - да что это такое Вы говорите :!: Да она понятней и очевидней (видна глазами и сразу) чем в любом скриптовом языке

Да, кстати, вот я упоминал про полное отсутствие у нас синтаксических ошибок... Так семантическая у нас таки есть одна. Это - цикличность вышеупомянутого графа. В простонародии называется - "кольцевание". Эту фигню я вижу с первого взгляда на схему.
А Вы, с первого ли взгляда в кодах пары десятков методов усморите взаимную рекурсию :?:
Не, ну надо же - структуры у нас нет :wink:

Рэйлвэй Каген писал(а):
Не структура. Визуальной структуры здесь нет
Если честно - никак не въеду, что вызывает у Вас дискомфорт, что в данном контексте вы называете структурой, и чего таки в супе не хватает
Давайте попробуем разобраться более подробно, что ли :oops:

Рэйлвэй Каген писал(а):
Не помешало бы ещё упорядочить связи по заранее объявленным критериям. Упрощающим понимание для других. Представьте - один инженер даёт другому собранную "макетку" и при этом добавляет: "Там всё понятно."
Может и не помешало бы... Давайте подробности - как без них на вопрос ответить-то
Но они у нас уже упорядочены как-то, вообще-то....
А понятность схемы зависит прежде всего от ее автора. Мы встречали и такие, где пьяный ежик *** сломает. Ну посылали автора таковой куда подальше, и всего делов.
Да, появились такие термины - читаемость схемы, дизайн схемы... А в электронике, так они всегда и были. И это правильно, даже если это занимает дополнительное время - как и любое грамотное документирование проекта.

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


P.S. Хотите верьте, хотите - нет: по некоторым деталям стиля рисования (да и грамматики) - я могу назвать автора схемы на скрине коллеги Pirr:lol:
Наверное, и мои схемы настолько же узнаваемы

P.S.S. Кстати говоря, в топике, откуда взят вышеупомянутый скрин - тоже как-то нет вопросов из серии "как это работает". Вообще-то, это есть экспериментальное подтверждение того, что "всем все понятно"


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Galkov писал(а):
P.S. Хотите верьте, хотите - нет: по некоторым деталям стиля рисования (да и грамматики) - я могу назвать автора схемы на скрине коллеги Pirr:lol:
Наверное, и мои схемы настолько же узнаваемы


Вот интересный момент. В том же Драконе идея - минимизировать вольности, размещение элементов для заданной структуры связей вычисляется однозначно и математически.

Я понимаю, что для схем другого рода, нежели алгоритмические, однозначно всё не разместишь. Но, мне кажется, надо к этому стремиться.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Pirr писал(а):
Вот прикреплю скриншот схемы сделанной в последней сборке HiASM. Эта схема сделана по всем правилам, и будет понятна всем (большенству) пользователей HiASM.


Нее, ребята, вычисления так совершенно не читаются. Ужас.
Это из пушки по воробью. Даже из пушечной батареи. В итоге видны одни лафеты пушек - а воробей - тю-тю :)

Нет, ну ещё можно иногда где-то деревом нарисовать..

И уж в любом случае часть взаимодействия с пользователем должна быть каменной стеной отделена от логики.

Кстати, независимо от интереса к Блэкбоксу в целом, настоятельно советую познакомиться с его способом организации форм и элементов управления. Скачайте http://store.oberoncore.ru/BlackBox/15/blackbox15re.7z, нажмите F1 и в открывшейся карте документации (на русском) найдите раздел "4. Формы".
Никакого ООП. Школьники могут разрабатывать уже со 2-3 занятия в ББ, полностью понимая принцип, а не следуя дебильным учебникам "Щёлкните 2 раза и впишите текст в обработчик".
(замечу, что формы-контролы - только узкий частный случай ББ-шной графики, поэтому их "ограниченность" не является проблемой, если нужно - выходим на уровень ООП-библиотеки составных документов и работаем с ней).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2009 14:54 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Galkov писал(а):
в чем-таки заключается "но непродуктивно".
Например: просто установление связи Событие->Метод между VCL-ками не всегда гарантирует правильную работу. Иногда важна последовательность/очерёдность установления этих связей. В графике связи обозначаются линиями. Т.е., обозначив связь, надо ещё куда-то залезть, чтобы обозначить/проверить последовательность/очерёдность. Неудобно/неэргономично/непродуктивно (по сравнению с линейной текстовой моделью), т.к. необходимо облазить несколько мест/окошек/менюшек по сравнению с одной строкой текста, размещённой в нужном месте исходника. Или думать, в каком порядке проводить линии на схеме, что вообще ни в какие рамки не лезет.

Galkov писал(а):
А Вы, с первого ли взгляда в кодах пары десятков методов усмотрите взаимную рекурсию
Нет. Потому и ЗА визуальные методы проектирования. При этом в курсе, что часть электронщиков свалила на текстовую нотацию(Verilog, VHDL).
Galkov писал(а):
Не, ну надо же - структуры у нас нет
Хорошо, есть. В первую очередь на компоненте - слева/снизу-направо/вверх. Вы её зафиксировали. Но тогда не остаётся возможности структурировать расположение межэлементных связей, кроме как использовать "шинные обозначения". Собственно, это Вы и делаете цветом связи. Пересечений не избежать. Представим вариант - непересекающиеся межэлементные связи, но что делать на плоском листе схемы, если структура связей непланарная? Вот, собственно, и все недостатки применённой структуры..
Galkov писал(а):
Хм... Ровно тоже самое можно сказать про любое дерево/граф
Не совсем так. Есть же, к примеру, ациклические графы, планарные и т.д. Их структура подчиняется некоторым правилам.


Замечу, что "читаемость схемы, дизайн схемы" не должны быть на уровне документирования проекта. Инструмент сам должен "вынуждать"(уже не раз говорилось в разных темах) строить работоспособную, хорошо читаемую схему.
"..Могу даже посты указать, где я выкладываю схему, а пользователь выставляет благодарность из серии "вот так оказывается надо делать, что бы было все понятно" - это только подтверждает, что достижение "читаемости схемы, дизайна схемы" в большей степени основано на интуитивном, эмпирическом уровне и "зависит прежде всего от ее автора".. Было бы лучше, если эти вещи опереть ещё и на краткий набор "вынуждающих" правил. Каких? В рамках HiAsm - не знаю :(


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Нее, ребята, вычисления так совершенно не читаются. Ужас.
Это из пушки по воробью. Даже из пушечной батареи. В итоге видны одни лафеты пушек - а воробей - тю-тю

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


Ну а если просто вычислительная формула - так это один элемент на формулу... Недавно мы диспутировали про читаемость схем типа рисования фракталов.... ((btw: если у Вас есть возможность принять схему с нашего сайта - сразу дам ссылочку)) Одна формула, один элемент из стандартного набора. Поскольку числа комплексные - две формулы
И вся проблема....
Грубо говоря, никто тупо не будет заниматься холиваром типа visual forever. Был такой детский возраст, но он уже закончился. Исходный критерий - это дело должно помогать думать. Точка.
Если Вам помогает лучше 10-строчный скрипт, чем три элемента - значит у Вас должна быть таковая возможность написать эти 10 строк.
Ровно так же, как и в электронике. Разработчик излагает свои мысли и идеи в виде схемы (чтобы некий САПР превратил его п/плату, прошивку чипа, и т.п..). Если в неком конкретном случае более понятна будет некая таблица (кросс какой-нибудь) - нарисуют таблицу, безо всяких холиваров.
А если кто-то из разработчиков будет рисовать такое, что коллеги его не будут понимать - его просто уволят к чертовой матери.
Ну это я к тому, что не возлагать на среду разработки компоновку схемы - тоже вполне приемлемый вариант

Илья Ермаков писал(а):
Кстати, независимо от интереса к Блэкбоксу в целом, настоятельно советую
Обязательно :)
Можно даже сказать - уже смотрю.


Последний раз редактировалось Galkov Среда, 12 Август, 2009 20:02, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Август, 2009 18:40 

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Рэйлвэй Каген писал(а):
Т.е., обозначив связь, надо ещё куда-то залезть, чтобы обозначить/проверить последовательность/очерёдность. Неудобно/неэргономично/непродуктивно (по сравнению с линейной текстовой моделью), т.к. необходимо облазить несколько мест/окошек/менюшек по сравнению с одной строкой текста, размещённой в нужном месте исходника. Или думать, в каком порядке проводить линии на схеме, что вообще ни в какие рамки не лезет.

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Про "не проверять последовательность" - тут старая, давно известная яма, в которую, засмотревшись в небо, попадают поклонники разного рода декларативных подходов в программировании.

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

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


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

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Илья Ермаков писал(а):
Про "не проверять последовательность" - тут старая, давно известная яма, в которую, засмотревшись в небо, попадают поклонники разного рода декларативных подходов в программировании.

Конечно же последовательность есть, и алгоритм есть, но я практически думаю на HiASM и схема работает так как я думаю. У меня проекты есть где около 900 элементов и 2500 связей используется. И ни разу я не ошибся, программа работает как надо. Для меня графическая схема - это и блок-схема, и проект и его реализация одновременно.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Значит, у Вас такой класс задач. Даже точнее - класс персональных приложений. Так?


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Кажется я начинаю понимать, откуда ноги растут у "планарной эргономики" и требований к среде "не давать рисовать неправильно"

Парни, вы бы сразу, открытым текстом сказали, что смотрите на HiAsm, а думаете о Драконе - много времени бы сэкономили :lol:
Надеюсь, никто не спешит, поэтому возьму пару дней таймаута на изучение, для более полного взаимопонимания

Ну и в свою очередь подкину Вам такое: http://www.rebelscience.org/Cosas/COSA.htm
Сам еще не все прочитал по буржуински-то (недавно лишь коллеги подкинули).
Мои педагогические способности - нулевые конечно же. А вот почитайте американца, он вас живо убедит, что прямо завтра же всем скриптовым языкам кердык наступит, и единственное спасение мира, это его проект.
Удивительно похожий (как мне кажется) на HiAsm. Основные отличия как раз в том, что у него полная свобода расположения точек, и отсутствие пересечений в его "набросках" (qsort как никак)
Но и у HiAsm есть одно преимущество - он ЕСТЬ :)


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

Зарегистрирован: Вторник, 04 Август, 2009 19:50
Сообщения: 33
Илья Ермаков писал(а):
Значит, у Вас такой класс задач. Даже точнее - класс персональных приложений. Так?

Я делал различные программы, клиент-серверные приложения, фоновые программы, службы, делал графические оболочки для консольных приложений и т.д.
Но основная сфера моих интересов это работа с СУБД.
Пока не разу не упирался в отсутствие какого либо элемента в HiASM, который необходимо былобы написать самому. Также ни разу не использовал InlineCode (вставку кода).


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Бизнес-приложения в основном, так? Для них характерно то, что их можно "задекларативить". В этом классе систем HiAsm - совсем не первым будет... Все CASE-ы как раз здесь хорошо и работают.

Системное программирование, встроенка - другой класс задач. САПР-ы нужны (и используются) другого рода, с упором на проектирование поведения во времени и взаимодействий. Тот же ДРАКОН, как пример. Но узкий достаточно - если сам по себе, и в текущей реализации ФГУП НПЦ АП.

В общем, тема необъятна и интересна. Не зря Вы подняли её :)


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9129
Откуда: Россия, Орёл
Galkov писал(а):
Ну и в свою очередь подкину Вам такое: http://www.rebelscience.org/Cosas/COSA.htm
Сам еще не все прочитал по буржуински-то (недавно лишь коллеги подкинули).

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

Не очень явно, но начало было заложено, в конце 90-х - швейцарские языки Active Oberon (операционная система A2) и Zonnon (http://oberoncore.ru/library/start - внизу описания языков). В АО - активные объекты, суперпараллелизм над общим адресным пространством. В Зонноне - явная спецификация протоколов взаимодействия.
viewforum.php?f=22
viewforum.php?f=21

Ответ Microsoft Research - экспериментальная операционная система Singularity (open-source, доступна документация).
viewtopic.php?f=60&t=904
Software-Isolated Processes, взаимодействие посредством обмена сообщениями по каналам, явная спецификация и контроль протоколов над этими каналами, безопасный язык и автоматическая память с самых нижних слоёв операционной системы, максимальный статический контроль компилятором. Как всегда, заимствованные и неплохо додуманные идеи обременены громоздкими фантазиями. От переизбытка средств и времени :)

Очень любопытный швейцарский эксперимент Композита: viewtopic.php?f=21&t=459
Идут ещё дальше, к компонентам, сообщениями и протоколам. И гипер-параллелизму. Миллионы параллельных процессов в общем адресном пространстве.

Microsoft Research вдогон к громоздкой Сингулярности пробует кое-что полегче - Axum, сильно смахивающий на Композиту :)
viewtopic.php?f=21&t=1594

Вот такая обстановка в области моделей программирования.


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

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 151
Galkov писал(а):
Но и у HiAsm есть одно преимущество - он ЕСТЬ :)
Rational Rose тоже есть. Однако всё это, даже в совокупности, не значит, что нет других технологий, которые стОит развивать. :mrgreen:


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Долго же я изучал Ваши материалы (одна компьютерра чего стоит), но куда денешься-то, если это необходимо для взаимопонимания :)
Ну вот что получилось пока:

1) Различие представлений "структуры программы" в HiAsm и ДРАКОН.

1.1) Давайте рассмотрим простенькое мероприятие по превращению текста структурированной программы в схему HiAsm. Исходим из того, что, как сделать таковое в ДРАКОН-схему - Вы знаете (и чего я совершенно не понимал в самом начале топика). Тут-то мы основную разницу и увидим.
Превращаем структурный блок в иконку с нужным изображением на ней (FOR, например), выносим стрелочку из этой иконки вправо к текстовому блоку, в котором теперь помещается уже только текст "подструктуры". Получилась иконка с одной правой точкой, от которой проведена связь к текстовому блоку. С которым проводим ту же самую процедуру, коль скоро он тоже является структурой. А если не является, то это назовем неким "атомом", которому тоже назначим иконку с одной левой точкой и поместим ее в библиотеку элементов. Кстати, о левых точках - это просто "входы в структуру". Соответственно, раз уж IF и FOR могут быть вложенными (да хоть и в самих себя же), то они естественно имеют левую точку.
Далее, вспоминаем, что в структуре (например, IF-THEN-ELSE-END) возможна не одна (как в FOR), а две подструктуры: TRUE-блок, и FALSE-блок. Все то же самое, но теперь у нашего структурного элемента будут две правые точки, от которых проведены линии к соответствующим блокам.
Одно "атомарное" действие, затем второе, затем третье - это ведь тоже описание структуры. И этот элемент структурирования у нас называется HUB, имеющий какое хочешь (вообще-то, ограничено сотней) количество правых точек.
Вспомним, кстати говоря, что сворачивание структурного блока в иконку - одно из основных пожеланий в плане "рюшечек" к IDE. А ведь это я не придумал, а просто прочитал на Форуме. Имеющее, безусловно, простое и логичное объяснение - разработчик хочет абстрагироваться от содержания структуры, и обозревать код (думать над ним) на более "глобальном" уровне. Ничего военного...
И чего у нас получается, после вышеозначенного сворачивания структурных блоков в иконки ??? А получается в явно нарисованном виде дерево структуры программы.
Именно структуры, и ничего другого. Поэтому я и не понимал вопросы про отсутствие структуры в наших схемах... У нас этого не может быть, потому что этого не может быть никогда (если по научному - не может быть по определению). Этим наше визуальное представление алгоритма (а я говорил пока только про алгоритмическую часть) отличается от ДРАКОНовского.
Спрашивается, зачем нужна схема программисту ??? Для того чтобы он мог в уме моделировать происходящее исходя из нарисованного (да хоть и написанного - без разницы). И эта модель в исполнении HiAsm несколько отличается от ДРАКОНовской. Если на ДРАКОН-схеме достаточно передвигать "черепашку" (пытаюсь использовать термины, встречающиеся на Форуме) по схеме, то у нас - нет, недостаточно. Мы должны ее двигать "на веревочке", имея ввиду, что она обязана (в ДРАКОНе - никому она ничего не обязана) вернуться назад. Не в том смысле, что об этом должен позаботиться программист - нет, не должен, она вернется, даже если он этого не хочет. Просто, без понимания такового, в его голове будет сидеть не очень адекватная модель происходящего. Например, некий элемент активизировал (отправил черепашку) по одной из своих правых веток. И пока она не вернется – у элемента нет никакой возможности активизировать некую другую. Да чего там активизировать - элемент вообще "заморожен", процессорное время отдано другим элементам, тем которые сейчас в правой ветке и находятся.
Грубо говоря, если в ДРАКОНе цикл моделируется в уме хождением черепашки «по кругу», то у нас - НЕТ. Никаких кругов, черепашка всегда возвращается обратно только по тому «следу», который сама же и проложила. А куда она денется-то, если она "на веревочке".

1.2) Возможен и другой подход, демонстрирующий разницу визуальных представлений ДРАКОНа и HiAsm. Представим себе макроикону «цикл ПОКА», внутри которой одна икона ВСТАВКА. Ну и, конечно, некий примитив/силуэт, на который ссылается икона ВСТАВКА. Так вот, в HiAsm эта макроикона вся целиком упаковывается в один элемент, из которой выходит визуальная связь, приходящая к той визуальной конструкции, которая будет описывать вышеозначенный примитив/силуэт (а там ведь аналогично – макроикона-вставка-примитив, и т.д.).
Т.е., в HiAsm визуализировано как раз то, чего в ДРАКОНе связано только именами.

1.3) Более коротко, но для кого-то может быть и более понятно: у нас не может быть нарушения принципов структурирования алгоритма по Дейкстре, потому что наши линии связи – это вовсе не GOTO, а CALL (хотя фактическое решение call/inline – это задача кодогенерации, а не визуального UI).

1.4) Предварительные выводы
Да, это немного сложнее, чем просто "абсолютно свободная черепашка"... Но знание сие вполне доступно школьникам - это есть просто экспериментально проверенный (нами) факт.
И самое главное, компенсируется пониманием структуры целиком. Это есть главное отличие, и это все-таки - есть Сила. Да, да - именно та Сила, которая "улучшает работу ума". Небольшой психологический барьер с ограничением свободы черепашки - и мы получаем доступ к «неограниченному источнику интеллектуальной энергии». Да пребудет с нами Сила (шутка юмору, конечно же)

2) Некоторые не тривиальные "шаблоны" ДРАКОНа в HiAsm. Для демонстрации действия Силы

2.1) Помню обсуждение визуализации исключений для ДРАКОНа. И в чем там была основная заморочка ???. Да в том, что в режиме "абсолютно свободной черепашки" не видно глобальное дерево структурных вложенностей. Кстати говоря, я не совсем понял, на чем же там сердце успокоилось все-таки... Ну да ладно.
Как у нас это будет выглядеть ??? Да элементарно... Элементик (TRY), с одной левой точкой - вход в структуру. Правая точка - дерево вложенных в нашу ловушку структур. Это очень правильно и наглядно (и я готов отстаивать эту позицию), что начало и конец структуры сосредоточены в одном месте :!: ((цикл FOR у нас это одна иконка, а не две, как в ДРАКОНе - начало цикла, и его конец))
Еще одна правая точка с названием onExcept. Если делать в стиле Forth, вполне этого и достаточно. К этой правой точке onExcept подключен некий алгоритм, который распознает «чужое» это, или «твое» исключение – по его "номеру". И, соответственно - либо просто скажет Raise (с тем же «номером» исключения, Raise - это элементик такой "атомарный", с одной левой точкой), либо только и совершит, что некую финализацию...
Все просто и очевидно: в штатном режиме, гуляя "на веревочке", черепашка вернулась бы, только обойдя все нужные ветки дерева. А при исключении - веревочку некий демон дернул так сильно, что черепашка сразу оказалась в элементе TRY, забывши все правила правильного поведения в элементах, являющимися узлами той ветви нашего дерева, по которым проходит ее веревочка. Откуда, уже по всем правилам, и попала на onExcept
Почему демон проснулся? Ну, либо мы "на ноль чего-то поделили", либо черепашка сама его "укусила", сказавши магическое слово Raise.
И все это видно на схеме глазами, а не посредством неких логических умозаключений: вот в этом месте стоит Raise, а вот именно в этом месте будет перехват – левее, ближе к корню дерева.
И попробуйте сказать, что я школьнику объяснил что-то неправильно :)

2.2) Параллельные процессы/потоки... Читал, читал - в аспекте ДРАКОНа. А теперь слухайте сюды
Синхронизация потоков, это ведь тоже некая простенькая структура, начинающаяся с WaitForSingleObject, и заканчивающаяся ReleaseMutex (ну или EnterCriticalSection/LeaveCriticalSection - если таковое будет угодно)
И у нас опять же - все просто и красиво: элемент с одной левой точкой doSafeWork и правой точкой onSafeEvent. Ну ладно, при более внимательном изучении вопроса, появятся еще и "аварийные" правые точки onWaitAbandoned, onWaitFailed, onWaitTimeOut. И все! Мне не надо рассказывать пользователю про необходимость освобождения мьютекса, после завершения критической к параллельному доступу работы с чем-то.
Просто алгоритмическую ветку, работающую с неким ресурсом, который допускает работу только по отдельности - пропускаем через такой элемент, и всего делов. Как бы даже и не придумаю сразу, чего тут еще обсуждать можно. Дешево и сердито, вроде.

3) Все вышесказанное относилось только к алгоритмической части творчества программиста. Но попробуем «скрестить ужа с ежом».
Потому что без такого «скрещивания» бывает крайне затруднительно. Ну, скажем - те же параллельные процессы... Есть два алгоритма, работающие в разных потоках, каждый использует с десяток каких-то переменных/данных (ресурсов, если по научному).
И тут на тебе – конфликт данных. Да, алгоритмы визуализированы, они схватываются глазом сразу, а вот обращение к общему ресурсу – сокрыто от глаз, и является, поэтому, миной замедленного действия. Зачем же мы тогда усиливали работу ума, если подрываемся на такой простой мине-ловушке.
Давайте, вместо написания в свойствах элемента некого магического имени переменной, просто покажем пальцем на некую иконку, символизирующую эту переменную. Примерно так у нас и сделано: есть некий элемент Memory (читай – ЗАПОМИНАТЕЛЬ), и к нему нарисована линия/линии (красным цветом, в отличие от алгоритмических связей) от всех других элементов, использующих нашу «переменную».
Чего мы этим достигаем ??? Пользователь нарисовал отдельно две алгоритмические ветки, работающие в разных потоках. И, в противовес чисто алгоритмическому стилю, обозначил дополнительно эти связи с «декларативными элементами». Каков результат – связей стало больше, они начинают пересекаться, и т.д.. А с другой стороны, ровно «шесть секунд» (симультанное восприятие) требуется пользователю, чтобы увидеть параллельное использование неких данных. Данных-то может быть много, а параллельное использование, например – только одно. И еще минута (уже сукцессивное восприятие), для более детального и профессионального анализа на критичность таковой ситуации (может оба алгоритма только чтением и занимаются)
Мины за пользователя никто, конечно же, не обезвредит, но каждая из них уже обозначена большим красным флагом.
Усилили мы работу ума программиста, расставивши «красные флажки» на схеме, или наоборот – только добавили «визуального мусора» ??? Мне представляется, что именно усилили. И призываю коллег поразмыслить именно над этим.

Что же у нас получилось с визуальным синтаксисом. Наряду с императивными элементами у нас в схеме стоит теперь и декларативный элемент. Декларативные связи мы пытаемся отделять от императивных - цветом, но и точки, к которым подключены эти связи – тоже не следует путать с императивными (которые мы обсуждали ранее). Так и возникла принятая у нас сегодня «схема»: точки, предназначенные для получения данных, мы располагаем сверху, а отдающие данные – снизу.
Вспомним еще, что элемент IF, кроме структурных единиц TRUE и FALSE занимается таки и сравнением, которое может быть тоже не самым тривиальным мероприятием. Да, теперь мы не сравниваем две именованные переменные, сказавши, что "это декларативная часть, и мы это не рисуем, потому что невозможно скрестить ежа с ужом". Возможно, теперь у нас на элементе IF есть две верхние точки для получения операндов для сравнения.
И что занимательно, именно после визуализации декларативных данных и связей с ними, в элементе IF не осталось чего писать, на неком языке программирования. Теряется свойство метаязыка, которому обязательно нужен некий язык для представления декларативных данных, и появляется магическая фраза «без единой строчки кода».
А разве не возникал такой вопрос при обсуждении ДРАКОНа ??? кажется а.к.а. Димыч за такое спрашивал... Так именно у нас и есть, что на это ответить. Например, что такое может получиться только после визуализации декларативных данных, и объединения «ежа с ужом». У нас это сделано таким образом... Может, есть более эргономичные варианты, например - расширением ДРАКОНа... Давайте смотреть. Но именно с этого надо начинать, видимо.

Однако может оказаться, что результат получения таковых данных для того же сравнения в элементе IF - тоже является неким нетривиальным алгоритмом.
Опять же, я не фантазирую, а просто вижу на форуме обсуждения ДРАКОНА предложения о превращении иконы ВОПРОС в аналог иконы ВСТАВКА - некий примитив с двумя выходами.
А вот, можете себе представить, есть у нас такая разновидность ЗАПОМИНАТЕЛЯ (с названием EventFromData), который перед тем как вернуть запрашиваемые у него данные, генерирует запрос ((сигнал, функциональный вызов, текст inline-алгоритма, отправляет черепашку: важны не слова, а соответствие сидящей в голове пользователя модели происходящего - реальной системе кодогенерации)) на свою правую точку. Возможно, что более понятным хинтом к этой правой точке было бы: «Ой, нас тут снизу спрашивают!».
Далее, пользователь рисует алгоритм (как бы, совершенно императивное действо), результатом которого является установка нужных значений в ЗАПОМИНАТЕЛЬ – что и будет возвращено в последствии как результат запроса. Т.е., у ЗАПОМИНАТЕЛЯ обязательно есть левая точка, предназначенная для установки (запоминания) в него новых значений.
Ну и каким элементом у нас тогда является ЗАПОМИНАТЕЛЬ: декларативным, или императивным ???
А никаким. Объявим таковые вопросы не имеющими смысла, по причине того, что акт «скрещения ужа с ежом» уже состоялся.
Наверное, настолько же бессмысленным, настолько в физике является вопрос: фотон (электрон, пи-мезон, и т.д. и т.п.), это волна или частица?
Кстати говоря, то же и про элемент FOR можно сказать. В алгоритмической ветке, которую этот элемент активизирует нужное количество раз, может потребоваться знание значения этого счетчика цикла. И чего теперь, по принципу разделения элементов на императивные и декларативные – заводить некий ЗАПОМИНАТЕЛЬ, непонятным образом связанный с элементом FOR ???
Да ни в коем случае :!:
Выкидываем этот принцип разделения на помойку, и заводим в FOR нижнюю (отдающую данные) точку с именем Position (например).

4) Дальнейшее развитие топологии в HiAsm

4.1) Ну хорошо, пока мы говорили о визуальном представление структуры алгоритма в виде дерева. А как быть с «дублированием кода»?
Нарисовал пользователь одну алгоритмическую ветку. Рисует вторую. И обнаруживает, что все последующие, необходимые для него действия – уже им же и нарисованы. Как какая-то часть предыдущей алгоритмической ветки. Что характерно: обнаруживает моментально – все ж таки симультанное восприятие.
Ситуация аналогична ДРАКОНовской, когда две разные макроиконы имеют в своем составе элементы ВСТАВКА, ссылающиеся на один и тот же примитив/силуэт. А у нас ведь как раз эта «ссылка» и визуализирована как связь.
Не дать пользователю объединить эти две (уже существующую, и требуемую к рисованию) ветки – себе дороже. Это настолько просто и понятно, по сравнению с рисованием некого «функционального вызова по имени» с выделением ветки в отдельную «функцию», что критику пользователя выдержать крайне затруднительно. Особенно, если ты придерживаешься взглядов, что инструмент для пользователя, а не наоборот. Опять же, критерием истины является не мой (Ваш, наш – не важно) логический вывод из некого понимания эргономики, а «психологический эксперимент». Можно и про бритву Окамы вспомнить: «функциональный вызов», непонятно из чего выходящая алгоритмическая ветка – это новые сущности, в противовес очевидному «соединению проводов».
Вот и получается, что дерево у нас превращается в граф, а задачу call/inline мы перекладываем на кодогенерацию, как бы это не было противно окружающим.
Мимоходом отмечу, что адекватного (в смысле оптимальности кодов) решения этой задачи у нас пока еще нет. Да и ЯВУ, которые осмеливаются этим заниматься – как-то не вижу. Скажем для «вертикальных» связей в подавляющем числе случаев нужен inline (в этом подавляющем числе случаев просто читаются некие значения – и все), а для алгоритмических веток – call (но тоже, далеко не всегда).
А деваться некуда, Front-End - первичен. Получается, что если для реализации таковых идей придется делать свой компилятор, то его придется делать :(

4.2) Далее, посмотрим, что происходит, если у пользователя возникает неистребимое желание сделать такое объединение веток, что граф становится циклическим. Как я уже отмечал в предыдущих постах, это у нас является запрещенным (хотя и не всегда) приемом, семантической ошибкой языка, называемой на сленге «кольцеванием». Источник такого «желания» пользователя – непонимание им наличия «веревочки» у черепашки, и желание выполнять чего-то в цикле. Проходит быстро, с первого раза (клинические случаи пока рассматривать не будем), но встречается - относительно регулярно.
Возможно ли потенциально убрать и это «недружелюбие» среды ??? Думаю – да. Тут должно быть что-то похожее на замену SendMessage на PostMessage. Т.е., наткнувшись на занятый маршрут (свою же веревочку), черепашка должна просто оставить данные, которые она несет - да прямо на дороге, считая свою миссию при этом выполненной. А, возвращаясь обратно, и обнаруживши послание (которое она сама же и оставила) - развернуться на 180 градусов, и повторить уже выполненную миссию, но с новыми (которые лежат на дороге) данными. Таковое «прикрытие» не сделано сегодня по неким причинам, связанным с совместимостью...

4.3) Ну и последний пока фактор – инкапсуляция.
Противоположной стороной нашей Силы (в сравнении с ДРАКОНом), является то, что наша схема в меньшей степени делится на фрагменты. Это понятно: расшифровка иконы ВСТАВКА может оказаться на другом листе, и выполняться даже другим разработчиком. А у нас это прямая и неразрывная визуализированная связь. Ну вот, мы можем «перегрузить лист информацией» значительно быстрей, чем на ДРАКОНе.
Понятно, что на бумаге у нас никто схемы не печатает, все только в среде, какие мониторы есть, с такими и работаем. Опыта с multi-touch – пока не имеем. Практически получается, что схемы, большие чем 200 элементов – перестают «читаться». Если по научному – перестает работать симультанное восприятие, видимо.
Против этого у нас тоже есть метод, похожий, возможно, на использование иконы ВСТАВКА в ДРАКОНе. Выделяем некоторую «географическую» область на схеме, <контекстное меню – поместить в...> - и дело в шляпе. Кусок схемы поместился в некий MultiElement, у которого есть все четыре вида точек (коль скоро соответствующие связи подходили к выделенному фрагменту схемы), как и у вышеописанных атомарных элементов.
Можно ли это сравнить с примитивом/силуэтом, на который ссылается элемент ВСТАВКА ??? Сравнить-то можно, только это не очень одно и то же будет.
Примитив/силуэт – это один какой-то алгоритм, а содержимое мультика – это несколько (по количеству соответствующих точек) алгоритмов, которые и не очень отделишь друг от друга, потому что они могут работать с одними и теми же данными. Да, после визуализации декларативных связей, появились проблемы с разделением алгоритмов, если они «лапают» одни и те же данные. Надо ли с этим бороться ??? Мое глубокое убеждение – НЕТ.
Потому что именно так устроена жизнь, как мне представляется. И лучше ее видеть таковой, какая она есть, чем создавать мифы про нее.

4.4) Немного философии.
Конечно, я описал «тупой» метод создания объекта «разработкой снизу». Но достойный внимания, хотя бы потому, что практически все через это проходят. Далее, пользователи начинают понимать (без усилий с нашей стороны, между прочим), что наиболее рационально этот прием работает, если большая функциональность требует меньшего количества интерфейсных точек.
Начинает приходить понимание и об абстрактном интерфейсе – наплевать чего там нарисовано внутри мультика, если ты точно знаешь назначение точек мультика. ((Причем, как-то так получилось, что он у нас сложнее «классического» определения))
Осознание этого «наплевать» - база для разделения работы над неким Проектом между многими разработчиками.
Ну и верхний полет (на данном этапе развития HiAsm) – это множественное использование «объектов этого класса».
Специально взял в кавычки.
Является ли это ООП, или является чем-то другим, или для того, чтобы являлось, еще чего-то надо добавить - судите сами. У Паниковского, конечно же, есть и свое мнение... Но я Вам его пока рассказывать не буду, а просто примерчик приведу из жизни инженера, который стал таки «программировать без программистов». И задам контрольные вопросы для размышления.
Вводная: собрал таки я железо, управляющее координатным столом – три (по количеству координат) отдельных модуля (контроллера на базе Atmega8-16), которые замыкают обратную связь от датчиков перемещения (ЛИР350) до электродвигателей. Естественно, все это добро связывается с компьютером, который и задает траекторию движения. Штатный программист пишет софт для штатной же работы Оператора в технологическом процессе. А как я (в смысле - инженер) отлаживать свое железо должен?
Сам пример: ну вот, рисую себе тестовую программу. Прежде всего – для работы с одним контроллером.
Это элементы GUI типа надписей, трек-баров, полей ввода, и прочая мутота. Ну и алгоритмы, которые по событиям от этих элементов и таймеров, формируют реальные «команды общения с контроллером»
Контрольный вопрос: схема, все это изображающая, какие знания отражает – императивные, или декларативные?
Или это все-таки объект, у которого алгоритмы (если по научному - методы) неотделимы от данных?
Для одного контроллера все прекрасно. Все это удовольствие я размещаю на Панели (это у нас такая GUI-разновидность мультика) и создаю еще две связанные копии этого мультика. Получившиеся три Панели я «приаттачиваю» к табу, и получаю инструмент тестирования всех трех контроллеров: с каждой закладки таба – своим. Они только и отличаются-то, что slave-адресом, который в одном из полей ввода и установлен.
Второй вопрос: если эти три Панели, не три экземпляра одного класса, тогда что же это такое?
А если это все-таки Объекты, то каким программированием я занимался в процессе их создания?

5) Простенький пример для критики
Как я уже отмечал в других постах, Автор среды HiAsm ДРАКОН-теорию не читал, и является в значительно большей степени практиком, чем теоретиком. И некоторые визуальные принципы, заложенные в среду, противоречат принятым в ДРАКОНе безоговорочно. Рисую простейший пример вычисления факториала для рассмотрения и критики визуальных решений.
Естественно, принятые нами решения обладают разной степенью важности. Есть некие базовые, от которых отступать было бы совершенно не разумно с нашей стороны. Например, если для устранения неких пересечений потребуется отменить «скрещивание ежа с ужом» - вряд ли имеет смысл рассматривать такие варианты. А конструктивная критика была бы очень интересна. Типа такой: «А если сделать не так, а по-другому – вот эдак? А если делать это как в ДРАКОНе, получится понятнее!»
Очень была бы интересна...
Заодно, я не поленился, и провел хронометрирование нашего кодинга. Поскольку встречал (и на этом Форуме в разделе ДРАКОНа - ТОЖЕ) глубокую убежденность, что рисовать схему неизмеримо дольше, чем настучать эквивалентный текст.
Совершенно необоснованную убежденность. Вот, смотрите:
Вложение:
Комментарий к файлу: Вычисление факториала
Factorial.png
Factorial.png [ 10.42 КБ | Просмотров: 9967 ]

От нажатия кнопы «Новый проект», до PrintScreen – 150 секунд. При этом большую часть времени расстановка контролов на форме занимает, да надписи всякие... А на выходе Вы видите работающее приложение, которое даже и «протестировали» (10! – посчитан) А ведь я не спортсмен, наоборот: люблю спешить не торопясь.
Грубо говоря, интерактивность среды – тоже может чего-то стоить. Т.е., я не только согласен в этом вопросе с Alexey_Donskoy, но и готов подтвердить его правоту экспериментальными результатами.

Да, если смотреть скрин, то понятно далеко не все. Все понятно - в среде, бумажный вариант даже и не рассматривается.
Хотя дополнительная (кроме скрина) информация, необходимая пользователю HiAsm (в смысле – узнающему базовые элементы по их иконке) выражается всего двумя строками: Math_?.Default=1.0; For_?.Start=2;
В среде он это увидит на панели свойств элементов.
В среде - много чего увидеть можно, в сравнении со скрином... На панели <Подсказка> постоянно отображается хинт на объект под курсором – на элементы, на точки элементов. Пользователь-то HiAsm все их, для приведенной схемы - наизусть и так знает. А свежему человеку – сложнее, наверное. Тут у меня глаз замыленный, и встать на позицию новичка - мне крайне трудно.
Вот пытаюсь, и не закачиваю «большую схему», скрин которой привел коллега Pirr. Но все равно – общий смысл проводимых там мероприятий, мне и по скрину понятен. Остались всякие подробности, типа конкретных значений конкретных свойств некоторых элементов. Закачаю, и через полчаса эта схема от своей будет неотличима...
А скринами мы, вообще-то - не обмениваемся.
Мы обмениваемся текстовыми скриптами, которые среда сразу же изображает как схему... В которых никто и разбираться не хочет (хотя там все прозрачно), их просто тупо копируют – <контекстное меню – Вставить>, и перед тобой схема. И наоборот: выделил кусок схемы - <контекстное меню – Копировать>, и в буфере винды скрипт для выделенного куска схемы.
Причем часто обмениваемся... Возникла мысль, в процессе беседы излагаешь ее в виде схемы – отдаешь коллеге. Он возражает, или делает какие-то добавления, путем некого исправления в схеме - и возвращает ее обратно... Не, ну совсем без слов не обходится, конечно же.
Ничего не напоминает :?: Мы обмениваемся знаниями, представленными в виде схемы (потому что это ТОЧНЕЕ, чем на великом и могучем) – мечта Владимира Даниеловича давно сбылась.
Вообще-то, получается почти по Мольеру: оказывается, мы всю жизнь «говорили Прозой», даже не подозревая этого :lol:

6) Каковы могут быть варианты дальнейшего развития
Как я отмечал ранее, при создании Проекта, математическим обоснованием никто особо не заморачивался. Можно даже сказать, что и создание супер-языка программирования – никто и в мыслях не имел. Делалось по принципу «давайте посмотрим, что получится». То, чего получилось, я могу рассказать со всеми подробностями, до мельчайших деталей.
Например, изложить все тонкие места в нашей технологии, и свое понимание о способах их преодоления. Что такое «без единой строчки кода», и возможно ли это в принципе. Можно ли в принципе, прекратить нескончаемый пока поток: «а сделайте мне это». Что сегодня невозможно сделать в HiAsm в принципе, и как это преодолеть. И наконец - конечен ли этот процесс усовершенствования.
Но излагать это логично при встречном конструктивном интересе :)

А вот то, чего будет с Проектом в будущем – тут возможны разные мнения. И все будут до какой-то степени обоснованы. Каково должно быть будущее, у того, что получилось сегодня – у меня есть свое мнение, но тут я могу ответственно говорить только о своем мнении. Если это будет интересно конечно.
Скажем, мне думается, что было бы логично, создать некую «стратегическую инициативу» по превращению HiAsm в будущий супер-язык программирования. Это конечно не преобразование системы познания человечества, но - все-таки…
Реально это или нет, об этом говорить пока рано, поскольку зависит от многих факторов. Например, от наличия математического обоснования проекта, сравнимого с аналогичным для Дракона. Но пока можно точно сказать, что математиков среди нашей команды нет.
И это далеко не единственный влияющий фактор, естественно. Но все эти вопросы открыты для конструктивного обсуждения. Точно могу сказать, что мне это - очень интересно


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

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


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

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


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

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