Здравствуйте, tau797, Вы писали:
T>>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>>Оно ортогонально представлению в виде state-машины. T>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени.
Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
C>>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии. T>Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык T>не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности T>человека.
Вот именно. И я хочу увидеть его приложения в программировании.
C>>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов. T>О вполне реальных проектах я вам писал неоднократно.
Я не могу их посмотреть.
C>>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие. T>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например?
То было давно...
C>>А вот информатика — в полной заднице. T>Если не брать производство аппаратных средств, а теорию — то чушь.
Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
C>>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится. T>Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки
Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. Оно не полностью автоматическое, и в ряде случаев требует ручного вмешательства.
C>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>Точно, именно так ПО для парижского метро и делали.
Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
T>>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>>Вот это уже интереснее. Но опять, нет видимого результата. T>Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы?
Ты знаешь, я видел стооооооолько софта, который выглядит красиво и даже ещё и работает. Но если посмотреть у него под крышкой — там такой макаронный индусокод, что становится просто страшно.
C>>сколько там относится к техникам программирования, а сколько к технике организации работ. T>Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки.
Методы проектирования — нет. Методы документации — частично. Методы отладки — да.
C>>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность. T>"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем.
Учитывая, что бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов, которые ещё и часто ведут себя как попало, да ещё всё это и меняется с периодичностью раз в год, да ещё и надо всё это поддерживать за деньги в малую долю разработки ПО типа Шаттловского...
Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, tau797, Вы писали:
T>>>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>>>Оно ортогонально представлению в виде state-машины. T>>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени. C>Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
C>>>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии. T>>Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык T>>не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности T>>человека. C>Вот именно. И я хочу увидеть его приложения в программировании.
C>>>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов. T>>О вполне реальных проектах я вам писал неоднократно. C>Я не могу их посмотреть.
C>>>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие. T>>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например? C>То было давно...
C>>>А вот информатика — в полной заднице. T>>Если не брать производство аппаратных средств, а теорию — то чушь. C>Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
C>Смотрим: http://arxiv.org/list/cs/pastweek?skip=0&show=25 — сюда сейчас попадают практически все нормальные статьи по информатике.
C>Из русских попались только две статьи: C>http://arxiv.org/pdf/0902.4460 C>http://arxiv.org/abs/0902.4514
C>А вся "Russian Academy of Science" ( http://search.arxiv.org:8081/?query=Russian+Academy+of+Science&in=grp_cs ) проигрывает одному MIT: http://search.arxiv.org:8081/?query=MIT&in=grp_cs со счётом 110 против 3552 (точнее, немного меньше из-за случайных совпадений со словом MIT)!
C>Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
C>>>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится. T>>Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки C>Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. Оно не полностью автоматическое, и в ряде случаев требует ручного вмешательства.
C>>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>>Точно, именно так ПО для парижского метро и делали. C>Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
T>>>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>>>Вот это уже интереснее. Но опять, нет видимого результата. T>>Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы? C>Ты знаешь, я видел стооооооолько софта, который выглядит красиво и даже ещё и работает. Но если посмотреть у него под крышкой — там такой макаронный индусокод, что становится просто страшно.
C>>>сколько там относится к техникам программирования, а сколько к технике организации работ. T>>Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки. C>Методы проектирования — нет. Методы документации — частично. Методы отладки — да.
C>>>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность. T>>"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем. C>Учитывая, что бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов, которые ещё и часто ведут себя как попало, да ещё всё это и меняется с периодичностью раз в год, да ещё и надо всё это поддерживать за деньги в малую долю разработки ПО типа Шаттловского...
C>Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода.
Благодарю за критику, которая была высказана в ходе Вашей дискуссии. Я чрезвычайно ценю подобную критику и приветствую ее. Критика — воздух науки.
Приглашаю всех (кто интересуется языком Дракон и ситуацией вокруг него), на форум "Визуальный язык Дракон", где я принимаю участие в дискуссии программистов и отвечаю на серьезные и острые вопросы. Адрес форума Вам известен: http://forum.oberoncore.ru/viewforum.php?f=62
На Вашем форуме прозвучало критическое замечание, что язык ДРАКОН нельзя использовать для построения сложных программ.
Отвечаю: это не так.
Где используется программное обеспечение языка ДРАКОН?
В Научно-производственный центре автоматики и приборостроения имени академика Н.А.Пилюгина. Здесь реализован на практике и успешно эксплуатируется в течение 12 лет метод «Программирование без прикладных программистов», основанный на использовании языка ДРАКОН.
Созданная технология называется «Технология разработки алгоритмов и программ Графит-Флокс». http://forum.oberoncore.ru/viewtopic.php?f=62&t=1091
Разработка языка ДРАКОН и технологии Графит-Флокс длилась 11 лет (с 1986 по 1996 год). Она используется в следующих крупных ракетно-космических проектах (при разработке систем управления ракет-носителей и разгонных блоков космических аппаратов):
• разгонный блок космических аппаратов ДМ-SL (в рамках международного проекта «Морской старт»);
• разгонный блок космических аппаратов Фрегат;
• модернизированная ракета-носитель тяжелого класса Протон-М;
• разгонный блок космических аппаратов ДМ-03;
• разгонный блок космических аппаратов «Наземный старт» (Старт в пустыне);
• ракета-носитель легкого класса Ангара 1,2;
• ракета-носитель тяжелого класса Ангара-А5;
• и др.
Во всех перечисленных случаях был использован метод «Программирование без прикладных программистов» на основе языка Дракон. Программы на языке ДРАКОН выполняются бортовым компьютером БИСЕР. Этот компьютер создан для установки на борту ракет. Он управляет полетом ракеты, управляет бортовыми системами ракеты и выполняет множество других функций.
Впервые язык Дракон и технология Графит-Флокс были применены на разгонном блоке ДМ-SL (в рамках проекта «Морской старт»).
Первый пуск ракетного комплекса «Морской старт» состоялся 28 марта 1999 г в 5 час. 30 мин. по московскому времени (27 марта 1999 г. в 18 час. 30 мин. по тихоокеанскому времени) с морской стартовой платформы «Одиссей» в Тихом океане на экваторе в районе островов Кирибати.
Чтобы обеспечить этот пуск язык Дракон и технология Графит-Флокс активно использовались на всех этапах разработки системы управления, испытаний и подготовки к пуску в течение трех лет, начиная с 1996 года.
Можно ли использовать язык ДРАКОН при создании программ для обычных персональных компьютеров, ноутбуков, контроллеров и т.д.
Сегодня пока еще нет, нельзя. Для этого надо разработать инструментальные программы ДРАКОНа для персональных компьютеров, ноутбуков и контроллеров.
Такая разработка ведется участниками форума «Визуальный язык дракон» на сайте OberoneCore.ru. Но она еще не закончена.
За рамками ракетно-космической тематики уже сегодня язык ДРАКОН можно использовать для разработки алгоритмов, проектирования программ, создания протоколов взаимодействия и т.д.
Но завтра ситуация изменится. Можно надеяться, что в скором времени язык ДРАКОН получит широкое распространение.
Здравствуйте, Паронджанов, Вы писали:
П>За рамками ракетно-космической тематики уже сегодня язык ДРАКОН можно использовать для разработки алгоритмов, проектирования программ, создания протоколов взаимодействия и т.д. П>Но завтра ситуация изменится. Можно надеяться, что в скором времени язык ДРАКОН получит широкое распространение.
Неужели совсем никак нельзя показать реальные примеры применения ДРАКОНа, чтобы можно было посмотреть на реальный вид программ на нём?
А>На мой взгляд, беда всех этих средств (блок-схемы, UML) в непродуманности нотации (хотя Паронджанов и в рамках нотации блок-схем умудрился создать нечто значительное — путем установления ограничений), которая не дает возможности работать с насыщенными схемами – сложность восприятия растет быстрее сложности самой схемы.
Ошибка подхода.
Представление системы слищком плоское, потому что не продумана архитектура, а не из-за особенностей UML.
А>И вторая часть этой проблемы – практическая полезность схем, диаграмм. Если с ее помощью можно сделать только некоторый «скелет», набросок программного элемента, то совершенно очевидно, что рано или поздно встанет проблема синхронизации схемы с программным кодом. И здесь вопрос в том, что будет легче: либо плюнуть на синхронизацию и продолжать писать, держа при этом в голове всю сложность разрабатываемого элемента, либо делать изменения в схеме, и затем с помощью каких-то средств отражать эти изменения в коде.
Ошибка подхода.
При правильной декомпозиции схемы зарагивают по большей части архитектуру и ключевой функционал, которые меняться должны как можно реже.
Рисовать вообще всю систему целиком — это идиотизм.
"Неужели совсем никак нельзя показать реальные примеры применения ДРАКОНа, чтобы можно было посмотреть на реальный вид программ на нём?"
Я понимаю ситуацию так. Вы очень опытный и очень занятый специалист. Вы хотите затратить минимум времени: взглянуть на код и составить собственное мнение. Я с уважением отношусь к вашему желанию.
Но здесь есть трудности.
1. Дракон — это сознательно недоопределенный язык. Далеко не все решения, используемые в космосе, предлагаются для общего пользования.
2. Я предлагаю ТОЛЬКО маршрутную часть языка (то есть слепыш дракон-схемы). Все осталное (заполнение слепыша текстом и декларативную часть (описание данных и классов) не входит в состав моего предложения. Их надо делать заново. (Наши космические решения здесь вряд ли могут претендовать на что-то).
3. Я использую существенно другую математику. Решения, предложенные Дейкстрой и Хоаром, подвергаются значительной модификации и развитию.
4. И так далее.
5. Поэтому показ реальных кодов может дезориентировать. Чтобы этого не произошло, надо прочесть мою книгу "Как улучшить работу ума" (хотя бы главы 6--17, или хотя бы главы 6--12).
8. Прочитайте также Извлечение из документа "Язык ФЛОКС". (Там же). Но там Вы увидите коды примитива, а рекомендуемой конструкцией является не примитив, а СИЛУЭТ.
Паронджанов пишет: > > показ реальных кодов может дезориентировать. Чтобы этого не > произошло, надо прочесть мою книгу "Как улучшить работу ума"
Респект. Под столом )
--
WBR,
Serge.
Автору — извините, я далёк от обсуждаемой темы и сказанное никак не
относится к достоинствам и недостаткам предлагаемого. Просто фраза очень
понравилась.
hrensgory wrote:
> Автору — извините, я далёк от обсуждаемой темы и сказанное никак не > относится к достоинствам и недостаткам предлагаемого. Просто фраза очень > понравилась.
А еще совершенно необходимо овладеть навыками работы на дешкомпьютере!
Не для Cybera, а истины для и остальных, кто сюда заглянет.
T>>Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени. C>Вообще-то, конечный автомат не может представить много чего. Поэтому я и пишу "state-машина" (aka "автомат").
У меня слова "конечный" не было. Впрочем, бесконечный нетаймированный автомат тоже представить адекватно систему реального времени не может, конечно.
T>>У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например? C>То было давно...
Было, есть в настоящее время, и будет. http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%81%D1%8C%D1%8F%D0%BD%D0%BE%D0%B2,_%D0%92%D0%B8%D0%BA%D1%82%D0%BE%D1%80_%D0%9D%D0%B8%D0%BA%D0%BE%D0%BB%D0%B0%D0%B5%D0%B2%D0%B8%D1%87
C>Не чушь. Товарищи из буржуйских стран сейчас занимаются интересными вещами, у нас же практически ничего не происходит.
Если кое-кому о чем-то неизвестно, вынужден повториться, это не значит, что это отсутствует в природе. http://www.iis.nsk.su/preprints/abstracts_ru.shtml http://www.iis.nsk.su/projects/index.shtml http://www.iis.nsk.su/preprints/books/index_ru.shtml http://www.spiiras.nw.ru/modules.php?name=Content&pa=showpage&pid=16 http://www.ccas.ru/ http://space.iias.spb.su/ http://www.keldysh.ru/projects/projects-fr.html http://library.keldysh.ru/prep_ls.asp
C>Смотрим: http://arxiv.org/list/cs/pastweek?skip=0&show=25 — сюда сейчас попадают практически все нормальные статьи по информатике. Вот прямо все.
C>А вся "Russian Academy of Science" ( http://search.arxiv.org:8081/?query=Russian+Academy+of+Science&in=grp_cs ) проигрывает одному MIT: http://search.arxiv.org:8081/?query=MIT&in=grp_cs со счётом 110 против 3552 (точнее, немного меньше из-за случайных совпадений со словом MIT)!
Конечно, следует приветстовать, если человек интересуется, что происходит в его проблемной области в мире. В то же время низкопоклонство перед Западом приветствовать вряд ли стоит.
C>Ещё можно сравнить знаменитый курс MIT'а по программированию и наши курсы в университетах.
Можно сравнить. Не так плохи курсы во многих наших университетах, и не только в Москве и Санкт-Петербурге.
T>>при создании вами же упомянутой системы управления парижским метро 14 ветки используется T>>так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки C>Проблема тогда в том, что спека будет аналогом алгоритма. Там всё сложнее — их система позволяет проверять соблюдение инвариантов при создании кода. C>>>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>>Точно, именно так ПО для парижского метро и делали. C>Его делали немного по-другому, однако. Сначала сформировали спеку с набором инвариантов и гарантий, а потом следили за их соблюдением.
Все именно так, как я написал. Да, "спецификация" на B-языке по объему приблизительно соответствует записи программы на "обычном" языке программирования. Да, при этом она снабжается описанием инвариантов.
C>Что далеко ходить — система SAP R3 содержит около 250 миллионов строк кода. Т.е. гигабайты исходного кода. C>бухгалтерия — это часто как раз те же десятки взаимодействующих друг с другом процессов
Он не взаимодействуют в реальном времени, конечно же. И "бухгалтерские" программы по сути своей безнадежно последовательны. Вычислительной сложности в них тоже нет. Сложность там возникает в связи с объемами, это да.
Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно.
Здравствуйте, Паронджанов, Вы писали:
П>1. Дракон — это сознательно недоопределенный язык. Далеко не все решения, используемые в космосе, предлагаются для общего пользования.
Сферический дракон в вакууме?
П>5. Поэтому показ реальных кодов может дезориентировать. Чтобы этого не произошло, надо прочесть мою книгу "Как улучшить работу ума" (хотя бы главы 6--17, или хотя бы главы 6--12). П>6. С учетом этих оговорок сообщаю: П>7. Технология разработки алгоритмов и программ ГРАФИТ-ФЛОКС показана здесь П>http://wiki.oberoncore.ru/index.php/%D0%94%D1%80%D0%B0%D0%BA%D0%BE%D0%BD
Опять реклама...
П>9. Силуэт(на псевдокоде) можно посмотреть здесь П>http://forum.oberoncore.ru/viewtopic.php?p=18467#p18467 П>10. Силуэт (код) см. здесь: П>http://forum.oberoncore.ru/viewtopic.php?p=14688#p14688
Вот это уже гораздо более интересно — хоть какой-то реальный код. Но в текстовом виде оно было бы намного проще, особенно если использовать функциональный стиль.
П>11. Крайне желательно научиться пользоваться дракон-редактором Геннадия Тышова. П>12. Буду вам очень благодарен, если Вы сочтете возможным все последующие вопросы задаваь не здесь, а на форуме сайта OberoneCore.ru П>http://forum.oberoncore.ru/viewforum.php?f=62
Нет, мне (да и остальным) удобнее общаться здесь.
> Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно.
Почему не корректно?
Чтобы что-то с чем-то сравнивать нужно определить методику и привести
обе стороны к сравнимому виду. В области инженерии ПО такие методики
существуют уже давно, как и численные метрики измерения различных
характиристик создаваемого ПО, в том числе и его сложности.
Одной из таких метрик и, пожалуй, самой популярной, явлется количество
функциональных точек — функции, модуля, всей программы. Существуют
утилиты для измерения этой метрики для многих языков программирования.
В свете этой метрики ни супер-хитрые формулы учитывающие гравитацию всех
планет солнечной системы, ни real-time среда выполнения программы на ее
сложность никак не влияют, потому как не увеличивают переменные затраты
на создание ПО, а лишь являются технологическими аспектами (а формулы и
тест-данные их верификации вообще составляют обязательную часть ТЗ).
Здравствуйте, mazurkin, Вы писали:
>> Но говорить, что бухгалтерские программы сложнее программ управления космическими аппаратами некорректно. M>Почему не корректно?
Вы сами ниже отвечаете на свой вопрос. Потому что "сложность" оцениваете лишь в рамках своего понимания (метрики).
Слишком разные по природе объекты. Грубо говоря, "сложность" бухгалтерских программ проистекает от их объема ("план по валу — вал по плану" ). А сложность программ управления КА можно сравнить с принципиально иным качеством проблемы, вызываемым уровнем необходимых интеллектуальных затрат. Примерно как сложность (может, даже правильнее сказать трудность) отрытия огромного котлована соотносится со сложностью постройки радиоприемника.
M>Одной из таких метрик и, пожалуй, самой популярной, явлется количество M>функциональных точек — функции, модуля, всей программы. M>Если у вас есть другая метрика — давайте обсудим.
Если взять, к примеру, "метрику" количества параллельно исполняемых процессов? А число одновременно отсчитываемых таймеров?
Сразу сложность бухгалтерских программ станет околонулевой
M> real-time среда выполнения программы на ее M>сложность никак не влияют, потому как не увеличивают переменные затраты M>на создание ПО
Это, простите, полная глупость.
)
Вот прямо все.
