DRAKON.SU

Текущее время: Четверг, 22 Февраль, 2018 19:58

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




Начать новую тему Ответить на тему  [ Сообщений: 375 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 19  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 11 Апрель, 2008 08:57 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
TMX писал(а):
зачем использовать не очень удачную архитектуру процессора, когда для ВМ стековый гораздо удобнее?... Да и Forth еще жив.

Тогда прямо напрашивается вопрос - а не пробовали ли Вы Форт-процессоров? (хотя вряд ли, если Вы не производитель ПЛК, а только пользователь?). Дело в том, что смену архитектуры аппаратной части также имеет смысл рассматривать, вместе с языками программирования, этот момент обычно все как-то упускают...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Апрель, 2008 21:39 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3537
Откуда: Москва
ДЛЯ А.Н. ДОНСКОГО

Уважаемый Алексей Николаевич!

Рад нашей новой встрече. Все таки мир очень тесен.
Хочу повторить то, что уже писал Вам в личном послании.
Благодарю Вас за то, что Вы обратили внимание на мою книгу "Как улучшить работу ума. Алгоритмы без программистов — это очень просто! М.: Дело, 2001." И написали на нее обстоятельную рецензию: "Эргономика информационных представлений".
http://simulators.narod.ru/review_um.htm
http://www.arbinada.com/main/node/56
Ваша рецензия мне особенно дорога — ведь она была первой.

Вторая рецензия появилась в Вестнике Российской академии наук в рубрике «Размышления над новой книгой»: Безель Я.В. Можно ли улучшить работу ума? Новый взгляд на проблему // Вестник РАН, Том 73, №4, 2003. С. 363—365.
https://www.ras.ru/publishing/rasherald ... e2fd61f6fa
Примечание.Не обращайте внимание на сообщение Ошибка в сертификате безопасности этого веб-узла. Это Академия наук, они выше таких мелочей. Так что (если Вам интересно посмотреть рецензию Я.В.Безеля) смело жмите на строку Продолжить открытие этого веб-узла (не рекомендуется).

В свое время Вы говорили о моей новой книге. Рад сообщить, что эта книга уже вышла:
Паронджанов В.Д. Почему мудрец похож на обезьяну, или Парадоксальная энциклопедия современной мудрости. М.: РИПОЛ Классик, 2007. 1154с.
Буду рад, если она Вам понравится.

С глубоким уважением
Владимир Паронджанов


Последний раз редактировалось Владимир Паронджанов Пятница, 11 Апрель, 2008 22:54, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Апрель, 2008 22:37 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
Рад нашей новой встрече. Все таки мир очень тесен.

Уважаемый Владимир Данилович!

Собственно, сюда я и пришёл по Вашему приглашению на Арбинаде :) И встретил здесь очень интересных людей, за что хочу Вас в очередной раз поблагодарить!

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

Вопросов много и спорных, и неоднозначных - тем интереснее ;)

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

С уважением, Алексей Донской.

P.S. Повторно искренне советую сменить название языка, пока не поздно и он с нашими общими усилиями не получил широкого распространения (почему, надеюсь объяснить при личной встрече)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Апрель, 2008 11:32 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Даже после непродолжительного знакомства с Драконом и создания одной-единственной схемы, я обнаружил, что по-новому стал смотреть на обычный текст программ. Лучше стал видеть структуру, задаю новые вопросы к тексту при чтении.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Апрель, 2008 14:06 

Зарегистрирован: Среда, 09 Апрель, 2008 17:42
Сообщения: 21
Ответ А.Донскому:

1. Я ближе к производителям ПЛК - наша группа занимается программированием микроконтроллеров в составе целевых устройств - телемеханика, управление, бытовая техника, управление экспериментом и т.п. Каждый проект был по-своему интересен и поучителен.
В том числе, намечались работы и по реализации дешевого специализированного ПЛК - в процессе составления ТЗ пришлось изучить и языки МЭК и другие используемые производителями ПЛК. Собственно, тогда и CoDeSys рассматривали как вариант и Forth, последний оказался слишком непривычен конечному пользователю (в цеху, где настраивают установки). Если же пользователь - сам разработчик, то есть Forth используется для переносимости, то решение весьма заманчивое.
Проблема - внутрисистемные средства отладки ориентированы на ассемблер и С.
Библиотеки свободных и коммерческих ОС, TCP/IP стеков, протоколов связи и примеры производителей - тоже.
Проект должен быть достаточно большим, длительным и многоцелевым, чтобы использование Forth себя оправдало.

2. По поводу таблички для процессоров. У меня недостаточно опыта, чтобы делать подобные обобщения (единственное, могу сказать, что для реализации виртуальной машины, выполняющей несложные вычислительные задачи и программируемой на ЯВУ, на мой взгляд, удобнее стековый процессор).
Когда я выбираю процессор, архитектура играет не самую важную роль (проектов с большими потоками данных, требующих ЦПОС не попадалось).
играют роль:
интерфейсы на борту,
объем памяти,
реальное быстродействие (и здесь у RISС, кстати, нет преимуществ перед CISС), в том числе при работе с устройствами в/в.
корпус,
условия работы, энергопотребление,
объем Errata,
надежность производителя (смена поколений процессоров и т.п.).
Практически для всех микроконтроллеров есть компилятор С, часто бесплатный.
Вопрос архитектуры встает в последнюю очередь. Да и здесь не все так однозначно - специфика микроконтроллеров в том, что они редко используются для чисто вычислительных задач, а в основном для обмена с устройствами ввода-вывода. Хотя есть электрические счетчики, РЗА, кореллометры и т.п., но там имеет смысл DSP ставить, на мой взгляд.
Опять же механизм обработки прерываний и наличие ПДП играют не последнюю роль.
Часто бывает, что компилятор сводит на нет преимущества архитектуры: например, вызов функции из-под прерывания обычно приводит к сохранению всех регистров общего назначения в стеке.

3. Почему я упомянул о стековом процессоре:
сейчас мы как раз реализуем переносимую виртуальную машину, для использования на PC и на целевой платформе с возможностью отладки.
Она нужна для выполнения задач, написанных на упрощенном С - в процессе разработки компилятора выяснилось, что разбор синтаксических выражений фактически через стек проходит, т.е. стековая машина - наиболее подходящий вариант.
Насколько я понял, gcc примерно так и работает - компилирует для обобщенного стекового процессора, а потом уже из ассемблера - еще раз для целевого процессора.
На Softcrat.ru есть пример "резинового стека".
Java - также стековая машина.
Собственно, я говорил о том, что если возникла необходимость в каком-то кросс-языке или кросс-виртуальной машине, то реализовывать МЭК (на мой взгляд - наглое продвижение разработок частных фирм-основателей) - далеко не лучший вариант.


Последний раз редактировалось TMX Воскресенье, 13 Апрель, 2008 06:58, всего редактировалось 1 раз.

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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Владимир Паронджанов писал(а):
... Это Академия наук, они выше таких мелочей.

Уточню ради справедливости: это Президиум РАН. Особое явление природы. Им действительно всё ... далеко внизу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 14 Апрель, 2008 17:08 

Зарегистрирован: Понедельник, 14 Апрель, 2008 16:14
Сообщения: 5
Здравствуйте.
Я не программист, я технолог. Работаю в банке. При описании бизнес процессов мы пользуемся технологическими схемами нарисованными в нотации языка Дракон.
Описание бизнес процессов, выполненное с использованием "традиционных" инструментов (например BpWin, ARIS и др.) не нашли понимания у наших визави - согласующих подразделений банка. Они не понимали этих схем, не понимали что, как и когда им необходимо делать, где их зона ответственности.
Со схемами на Драконе - все иначе. Из минусов - увеличилось время согласования схем :shock: , т.к. схемы стали понятны и логичны, и соответственно более детальны. Схемы мы рисуем просто в Визио. Самая большая схема имеет размер три склеенных между собой листа формата А3. По понятным причинам я не могу привести пример схем.

Дракон мне настолько понравился, что в нем я нарисовал алгоритмы выполнения....асан йоги.

Уважаемый Владимир Данилович!
Большое спасибо Вам за Дракон!
Сейчас читаю Вашу последнюю книгу "Почему мудрец...". После прочтения первых глав стало грустно.

С уважением, Иван.


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

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

Очень интересная ветка получилась.

Мы с Борисом Рюмшиным, как авторы ОберонКоре, имеем к вам предложение - организовать небольшой ресурс по Дракону. Можем сделать для этого следующее:
Во-первых, выделить в этом форуме отдельный тематический блок "Визуальный язык Дракон".
Во-вторых, сделать раздел в wiki.oberoncore.ru, который драконтузиасты будут заполнять материалами. Для начала стоит, конечно, опубликовать книгу Владимира Даниловича в PDF, вместе со связанными статьями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 06:11 

Зарегистрирован: Понедельник, 25 Февраль, 2008 08:42
Сообщения: 38
КИЕ писал(а):
Дракон мне настолько понравился, что в нем я нарисовал алгоритмы выполнения....асан йоги.

Не могли бы вы послать эти алгоритмы на мой почтовый ящик? (ain-2@narod.ru)
Заранее спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 07:19 

Зарегистрирован: Понедельник, 14 Апрель, 2008 16:14
Сообщения: 5
ain писал(а):
Не могли бы вы послать эти алгоритмы на мой почтовый ящик?


Уважаемый ain.
Я нарисовал интеллект карту по статье Виктора Бойко "Практика йоги в русле сутр Патанджали" (http://www.realyoga.ru). Там даны два алгоритма выполнения асан - базовый и "продвинутый". Именно по ним я и нарисовал ДРАКОН-схемы. Сейчас Виктор Сергеевич смотрит карту и пишет свои замечания, после чего, я надеюсь, общая карта будет опубликована на указанном интернет ресурсе. Да и, честно говоря алгоритмами их можно назвать условно.

Илья Ермаков писал(а):
Мы с Борисом Рюмшиным, как авторы ОберонКоре, имеем к вам предложение - организовать небольшой ресурс по Дракону


Было бы просто здорово!


Вложения:
Комментарий к файлу: Вот пример базового алгоритма выполнения асан
.jpg
.jpg [ 83.88 КБ | Просмотров: 7235 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 07:45 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 71
Откуда: Россия, Орёл
Цитата:
Вот пример базового алгоритма выполнения асан

Страсть какая! :shock:
:mrgreen:


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 143
Откуда: Россия, Орёл
Мне кажется, что по правилам, выход должен быть один. В данном случае - отдельная ветка силуета "Выход из асаны" и в ней просто конец.

А как на самом деле?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 11:46 

Зарегистрирован: Понедельник, 14 Апрель, 2008 16:14
Сообщения: 5
Евгений Темиргалеев писал(а):
Мне кажется, что по правилам, выход должен быть один. В данном случае - отдельная ветка силуета "Выход из асаны" и в ней просто конец


Да, Евгений, Вы правы, спасибо. Поправлю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 12:57 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
КИЕ писал(а):
Работаю в банке. При описании бизнес процессов мы пользуемся технологическими схемами нарисованными в нотации языка Дракон.

Вот это уже сильный аргумент!

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 13:25 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Надо пропагандировать асан шире. Особенно в части молчания ума.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 13:36 

Зарегистрирован: Понедельник, 14 Апрель, 2008 16:14
Сообщения: 5
Alexey_Donskoy писал(а):
А можно немного подробнее (в рамках приличия ).

Дык можно, наверное :wink:

Сначала создаются функциональные схемы, т.е. именно то, что Вы, Алексей, называете алгоритмическим слоем (кстати, спасибо за термин, взял на вооружение :) ). Эти схемы призваны ответить на вопросы:
- последовательность проведения операций;
- зона ответственности подразделений;
- результат, достигаемый в результате проведения оперции и реализации бизнес процесса.

Схемы не отвечают на вопрос посредоством чего достигается выполнение операции.

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

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

После чего возможно два варианта, либо прямое написание ТЗ по согласованным схемам, либо разработка более детальных схем, с привязкой к ПО, статусами, документами и т.д. И дальнейшим написанием ТЗ.

Я понимаю, что "вершиной мастерства" было бы просто передача схем программистам (про генерацию кода, на основе схем, остается только мечтать) с пропуском этапа написания ТЗ. Но такое пока не получается. По "другим" причинам. Увы. :(

Alexey_Donskoy писал(а):
Не напрягает ли необходимость "ручного" отслеживания всех допустимых вариантов развития событий?


Алексей, а что делать, приходиться. Пока даже не представляю где здесь можно вставить "автомат". С другой стороны банковская деятельность в РФ очень регламентированна со стороны ЦБ. Шаг влево, шаг вправо - расстрел.

С уважением, Иван.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 15:36 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
Info21 писал(а):
Надо пропагандировать асан шире. Особенно в части молчания ума.

Молчание ума просто необходимо. Кроме асан йоги, есть и другие способы.
Но вот, ведь мы тут программированием занимаемся... Тут ум нужен, и воспитывать его нужно.
Противоречивые требования, как их решить? Почти коан получился ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 15 Апрель, 2008 15:49 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
КИЕ писал(а):
- зона ответственности подразделений;

вот тут... как Вы это делаете в Драконовских алгоритмах? Просто, выделяя и группируя действия?
Насколько (не)оправдано было бы совместное использование соответствующих UML-диаграмм? Или они таки принципиально не обязательны в данной задаче?

КИЕ писал(а):
Alexey_Donskoy писал(а):
Не напрягает ли необходимость "ручного" отслеживания всех допустимых вариантов развития событий?

Алексей, а что делать, приходиться. Пока даже не представляю где здесь можно вставить "автомат". С другой стороны банковская деятельность в РФ очень регламентированна со стороны ЦБ. Шаг влево, шаг вправо - расстрел.

Только регламент уж очень странный. Обычно в час Х, когда уже всё должно работать вчера, они ещё не в состоянии объяснить регламент... Это система... Ещё в 1997, когда вводили новый план счетов, Ассоциация разработчиков банковских систем собирала нас незадолго до... Присутствующий представитель ЦБ не сказал ровным счётом ничего вразумительного... Кстати, как там сегодня - баланс в тысячах ещё не отменили? ;)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 06:23 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Alexey_Donskoy писал(а):
Info21 писал(а):
Надо пропагандировать асан шире. Особенно в части молчания ума.

Молчание ума просто необходимо. Кроме асан йоги, есть и другие способы.
Но вот, ведь мы тут программированием занимаемся... Тут ум нужен, и воспитывать его нужно.
Противоречивые требования, как их решить? Почти коан получился ;)


Побольше способов, побольше!
И распространять их поширше, поширше!
А воспитанием именно молчания ума как-то педагогическая наука пренебрегает, так что противоречия на данном историческом этапе нет, считаю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Апрель, 2008 11:03 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 935
Откуда: Россия, Чебоксары
Вниманию Владимира Паронджанова!

Хотите по схеме - пойдём по схеме!

Владимир Паронджанов писал(а):
Чтобы устранить отмеченные погрешности, надо:
    • Три иконы ВЫХОД ИЗ АСАНЫ превратить в три иконы «Адрес» и прицепить их к нижней горизонтальной линии.
    • Добавить справа еще одну ветку. В иконе «Имя ветки» написать ВЫХОД ИЗ АСАНЫ.
    • Ниже поместить икону «Действие». И написать в ней «Выйти из асаны». Еще ниже поместить икону «Конец» и написать в ней слово Конец.

Вот типичный пример увеличения сложности. На мой взгляд, неоправданного. Сформулируем поточнее:
Отказ от единообразного изображения графа алгоритма - большой недостаток.
Да, я понимаю, что это - компромисс. И что пересечения линий - это плохо. Но, ИМХО, разрыв линий (адрес) - гораздо хуже. Нарушается целостность восприятия, требуются дополнительные усилия.

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

Владимир Паронджанов писал(а):
А так получается, что Ваш асанщик полностью пассивен. Он просто плывет по течению. И не делает никаких усилий. Он ни к чему не стремится. Как будто он живой труп (во второй ветке). Неужели это действительно так?...Может быть, Ваш «алгоритм» описывает не то, что асанщик ДЕЛАЕТ, а то, что с ним (асанщиком) ПРОИСХОДИТ. В таком случае Вы используете Дракон за рамками его полномочий. Большой беды в этом нет. Но при этих условиях почти все мои замечания теряют силу. Потому что это уже не алгоритм, а что-то вроде декларативного описания.

В принципе смысл именно в том, чтобы отключить ум, желания, стремления... Иначе останется возбуждение, которое не позволит достичь результата... Но это не относится к данной теме ;)
А к теме относится, как мне кажется, то, что всё-таки это алгоритм. Потому что есть последовательность состояний, и есть необходимость отслеживать эти состояния... В данном случае несколько размыается разница между алгоритмом и диаграммой состояний... или потоковой диаграммой... И этот момент я бы записал в плюс!

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 375 ]  На страницу Пред.  1 ... 8, 9, 10, 11, 12, 13, 14 ... 19  След.

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


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

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


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

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