Здравствуйте, serg0s, Вы писали:
C>>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим. S>А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований.
Это примитив в виде кода они будут выглядеть не хуже.
S>>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю. S>Обида – не повод для критики. Давайте говорить по существу вопроса.
Где ты видишь обиду?
S>>>Конечно, автор со своими идеями отстал лет этак на 15-20, но тем не менее, его идеи направлены на борьбу именно со сложностью. C>>Нет, не направлены. S>Этим только подтверждаете (см. абзац 1 ответа).
Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода.
Дальше сложность лежит в проектировании системы — разбивке её на модули, организации расширяемости и т.д. Именно это и является сейчас реальным полем исследований. К примеру, книга GoF как раз занимается организацией паттернов проектирования кода — из-за чего и является must read для программиста. Именно по этой причине сейчас появляется интерес к DSL.
А, да. Ещё сейчас широкие массы начинают интересоваться и функциональным программированем — это уже затрагивает и код внутри методов. Жаль только, что автор книги о нём не знает.
Здравствуйте, Cyberax, Вы писали:
C>>>Вот про это, пожалуйста, не надо. Мне принцип нафиг не интересен, если на практике он неприменим. S>>А как же с первой частью моего ответа? Посмотрите диаграммы, убедитесь в том, что они таки существуют. А это значит, что Ваше утверждение не имеет оснований. C>Это примитив в виде кода они будут выглядеть не хуже.
Но все-таки существенно больше 20 строк
S>>>>(Это кстати практически во всех книгах наблюдается – не только у Паронджанова) C>>>Обычно в книгах и не утверждается, что они претендуют на серебряную пулю. S>>Обида – не повод для критики. Давайте говорить по существу вопроса. C>Где ты видишь обиду?
Обычно таким образом и обижаются. Может, Вы и не обиделись, но выглядит это именно так.
C>Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода.
Мы с Вами, очевидно, работаем над системами разного рода – соответственно и мнения различаются. Для примера приведу одну из разработок: протокол локальной сети и его программное обеспечение.
Здесь характерна многозначность и многофакторность в алгоритмах, и все это на уровне методов, причем особо не спасает функциональная, да и любая другая декомпозиция – как говорится – хоть вдоль хоть поперек – все едино. Поневоле приходится как-то упрощать представление – в том числе и за счет графики – чтобы справиться именно с логической сложностью. Кстати, есть еще один источник на эту тему, не знаю, известен ли он Вам. Хотел проверить его на каком-нибудь примере, да пока руки не доходят.
C>Дальше сложность лежит в проектировании системы — разбивке её на модули, организации расширяемости и т.д. Именно это и является сейчас реальным полем исследований. К примеру, книга GoF как раз занимается организацией паттернов проектирования кода — из-за чего и является must read для программиста. Именно по этой причине сейчас появляется интерес к DSL.
По поводу DSL. По моему, судьба этого направления будет гораздо печальнее судьбы SQL. А ведь в конце 80х – начале 90х о нем говорили примерно также, как сейчас про DSL. Очередная панацея. Все эти шумихи и моды — для верующих. А начнешь разбираться – и опять дежавю.
Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов.
Так что не стоит создавать очередных идолов – их и так хватает в нашем мире.
Очевидно, дело в том, что Ваш ум ориентирован на текстовое представление. Поэтому Вы и не видите особого смысла в графике. Наверное, примерно также Вы относитесь и к UML.
В этом нет ничего ни хорошего ни плохого. Просто есть люди с разным складом ума. Это означает однако, что мы зря с Вами спорим на эту тему: просто потому, что для меня очевидно одно, а для Вас – другое. Для Вас графика не имеет смысла, для меня – наоборот. У каждого свой опыт и свои сложившиеся представления. Так что не стоит копья ломать.
Здравствуйте, serg0s, Вы писали:
C>>Это примитив в виде кода они будут выглядеть не хуже. S>Но все-таки существенно больше 20 строк
"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально можно оценивать возможности системы.
К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода.
C>>Объясняю подробнее: сложность в современных системах обычно НЕ ЛЕЖИТ в коде отдельных методов. Это этап, который проходится программистом за полгода. S>Мы с Вами, очевидно, работаем над системами разного рода – соответственно и мнения различаются. Для примера приведу одну из разработок: протокол локальной сети и его программное обеспечение.
Что такое "протокол локальной сети"?
Я писал десятки (если не больше) протоколов, включая и простую реализацию TCP/IP. В предпоследний раз мне пригодился пакет из Boost'а для реализации state-машины, а в последний раз — поддержка замыканий в языке. На уровне методов ничего сложного там нет — прочитать/записать данные и каким-то образом сменить состояние.
В документации к протоколу тоже разве что графическая state-диаграмма помогает.
S>По поводу DSL. По моему, судьба этого направления будет гораздо печальнее судьбы SQL. А ведь в конце 80х – начале 90х о нем говорили примерно также, как сейчас про DSL. Очередная панацея. Все эти шумихи и моды — для верующих. А начнешь разбираться – и опять дежавю.
Вообще-то, никто не говорит про серебряные пули, кроме авторов рекомендуемых книг. DSL — просто ещё один инструментарий для борьбы со сложностью.
Причём тут сравнение с SQL — мне лично не понятно.
S>Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов.
GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна.
Вот подобная рода работа и была бы ценна.
S>Очевидно, дело в том, что Ваш ум ориентирован на текстовое представление. Поэтому Вы и не видите особого смысла в графике. Наверное, примерно также Вы относитесь и к UML.
Именно. Причём не я один — я не знаю ни одного сколь-либо большого проекта (хмм... да даже и сколь-либо малого), разработка которого ведётся с помощью UML.
Здравствуйте, Cyberax, Вы писали:
C>"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально можно оценивать возможности системы. C>К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода.
Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму. Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент.
Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Дело не в авторе, повторяю, дело в Вас, в серьезном различии мышления его и Вашего. В силу этого вряд ли Вы сможете понять его плюсы. А минусы есть у всех без исключения, и топтаться на них – дело элементарное. Гораздо сложнее хотя бы попробовать понять.
Опять же повторюсь: не стоит копья ломать на этой теме – толку не будет. Хотя может быть, Вы когда-нибудь признаете право других на мышление, альтернативное Вашему – тогда может еще можно будет поговорить.
C>Я писал десятки (если не больше) протоколов, включая и простую реализацию TCP/IP. В предпоследний раз мне пригодился пакет из Boost'а для реализации state-машины, а в последний раз — поддержка замыканий в языке. На уровне методов ничего сложного там нет — прочитать/записать данные и каким-то образом сменить состояние. C>В документации к протоколу тоже разве что графическая state-диаграмма помогает. десятки (если не больше) протоколов — это явный перебор. Не стоит так подставляться.
Это как раз показывает, что Вы писали не протокол, а уровень приложения для протокола. Там все действительно так как Вы описываете. А это две большие разницы.
C>Вообще-то, никто не говорит про серебряные пули, кроме авторов рекомендуемых книг. DSL — просто ещё один инструментарий для борьбы со сложностью. C>Причём тут сравнение с SQL — мне лично не понятно.
Сравнение с SQL – только в отношении поднятой вокруг средства шумихи. И там и здесь шум гораздо больше результата. Кроме того, это тоже своего рода прикладной язык – для СУБД.
S>>Что касается паттернов и GoF, так это люди просто поделились своим опытом. Когда я читал о паттернах, то почти в половине случаев отмечал, что когда-то это уже было в моей практике, и решено либо схожим образом, либо альтернативным. Вряд ли это следует называть сколь-нибудь существенным шагом вперед – простой обмен опытом, не более. Кстати, у них тоже имеется некоторая доля фетишизации этих самых паттернов. C>GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна. C>Вот подобная рода работа и была бы ценна.
Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более.
C>Именно. Причём не я один — я не знаю ни одного сколь-либо большого проекта (хмм... да даже и сколь-либо малого), разработка которого ведётся с помощью UML.
Я тоже далеко не в восторге от UML. Но скорее всего, по другой причине, уже писал об этом, не буду повторяться. Много было шуму, а результат весьма скромный.
Здравствуйте, serg0s, Вы писали:
C>>"Существенно" — это система в миллион строк кода. Ну или хотя бы в 100000 строк. На таких объёмах уже реально S>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму. Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент. S>Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Нет, он просит чтобы автор привел пример пример ПОЛЕЗНОЙ системы. Ну не волнует никого, как система реализована на уровне методов.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, serg0s, Вы писали:
C>>К примеру, в ядре Линукса сейчас примерно 9 миллионов строк кода. S>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего?
Да. Не в тексте книге, а на CD с примерами к ней и/или на сайте автора. Блин, да просто бы любой сторонний проект вполне бы подошёл.
S>Чтобы она стала никому не нужной? Вы представляете ее объем? Вы вобще видели когда-нибудь такую книгу? Допустим гипотетический случай (хотя на такое пойдет только сумасшедший): автор привел-таки такую диаграмму.
Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world".
S>Так Вы же первый не станете ее читать. У Вас наверняка найдется другой аргумент.
Я смогу её запустить и посмотреть что получится.
S>Короче говоря, Вы требуете от автора, чтобы он стал сумасшедшим. Комментарии как говорится излишни.
Нет. Я не требую ничего необычного.
C>>В документации к протоколу тоже разве что графическая state-диаграмма помогает. S>десятки (если не больше) протоколов — это явный перебор. Не стоит так подставляться.
Что удивительного в том, что мне пришлось за долгие годы встретиться с кучей протоколов?
S>Это как раз показывает, что Вы писали не протокол, а уровень приложения для протокола. Там все действительно так как Вы описываете. А это две большие разницы.
Что значит "уровень приложения для протокола"? Я писал именно сам TCP/IP стек (принимающий пакеты напрямую с сетевой карты), сам протокол ARP, когда-то делал минимальный DNS, много раз повторял HTTP-клиенты и серверы и т.д.
Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт.
C>>Причём тут сравнение с SQL — мне лично не понятно. S>Сравнение с SQL – только в отношении поднятой вокруг средства шумихи. И там и здесь шум гораздо больше результата. Кроме того, это тоже своего рода прикладной язык – для СУБД.
Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом.
C>>GoF — это именно работа по категоризации паттернов, реально используемых программистами, с обсуждением их преимуществ и недостатков. Этим она и полезна. C>>Вот подобная рода работа и была бы ценна. S>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более.
Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут.
Приветствую еще одного участника нашего затянувшегося спора .
AJD>Нет, он просит чтобы автор привел пример пример ПОЛЕЗНОЙ системы.
Видите ли, в нашем с Cyberax диалоге нет ни одного слова о полезности применительно к книге. Допускаю, что Cyberax подразумевал это, но согласитесь, трудно понять то, что не говорится, а подразумевается.
А система управления ядерным реактором – не полезная? Мне кажется, Вы несколько не тот акцент хотели высказать.
Возможно, речь идет о полезности для читателя. Так ведь Вы и Cyberax не единственные читатели. Ну не нашли ничего для себя – так я тоже в подавляющем большинстве книг для себя ничего не нахожу. Это не повод для критики. Если книга для меня бесполезна, я просто ее не беру. Но это не значит, что она для других не полезна. Люди все разные, каждому нужно свое. А книга Паронджанова нашла своего читателя – кто-то даже компилятор сделал для дракона.
Хотя, повторяю, есть у него и минусы, и немало – но в другом.
AJD> Ну не волнует никого, как система реализована на уровне методов.
Дело в том, что язык дракон построен на базе граф-схем алгоритмов (по ГОСТ). А они предназначены для представления алгоритмов, то есть для уровня, соответствующего методам. Если Вас волнует что-то другое – так это же не повод для дискуссии о драконе. Меня тоже далеко не только это волнует. И системные вопросы очень интересуют. Готов на эти темы разговаривать, и уже говорю. Например, в этом топике. Только мы здесь говорим о книге Паронджанова и его драконе. Хотя уже очень сильно отклонились . И похоже, спор грозит стать бесконечным .
Здравствуйте, Cyberax, Вы писали:
S>>Иначе говоря, Вы предлагаете автору приводить в книге блок-схемы, которые были бы эквивалентны как минимум, 100000 строк кода? И для чего? C>Да. Не в тексте книге, а на CD с примерами к ней и/или на сайте автора. Блин, да просто бы любой сторонний проект вполне бы подошёл. C>Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world".
Вы запускали TeX? Кнут из разряда тех же сумасшедших. Только гениальных, которым можно. А поскольку написал библию, то ему все простили. Да и цель у него была на порядок сложнее, чем дракон. Кроме того, тогда был большой разнобой в языках, поскольку очень много народу писало на ассемблерах. И изобретение TeX было вынужденной мерой, только способом выбраться из этой ситуации, не более. Хотел охватить как можно больше народу. Он там прямо так и пишет. Сейчас этого нет, и такие подвиги бессмысленны. И пошел он на это только потому что взялся за глобальную задачу. Так что Вы предлагаете сопоставлять несопоставимое, а значит, подобные аргументы бессмысленны. Все равно что сравнить например, космический корабль и автомобиль. Возьмите пример хотя бы более-менее аналогичный дракону, поскромнее – скажем, Кернигана, Страуструпа или Вирта (хотя и это на мой взгляд несопоставимо). Почувствуйте разницу.
А почему бы Вам не потребовать 100000 строк от GoF? Или они для Вас – вне критики?
C>Я смогу её запустить и посмотреть что получится.
И на чем же Вы хотите ее (диаграмму) запустить? А если не на чем, то опять автор виноват?
Вы это серьезно? По-моему, без юмора относиться к таким заявлениям сложно.
C>Нет. Я не требую ничего необычного.
??? Вы требуете от автора гениальности Кнута – и это называется «ничего необычного»? Так можно и черное назвать белым.
C>Что значит "уровень приложения для протокола"? Я писал именно сам TCP/IP стек (принимающий пакеты напрямую с сетевой карты), сам протокол ARP, когда-то делал минимальный DNS, много раз повторял HTTP-клиенты и серверы и т.д. C>Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт.
Уровень приложения – так и называется. В описаниях протоколов есть.
Так все-таки – написанные или использованные? Разница огромная.
C>Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом.
Но заявлено было куда бОльшее. Говорилось, что он станет языком для простых юзеров (не программистов). А побеждать было некого – такого класса и для этих целей серьзных языков больше не было. И он занял подобающее ему место, но далеко не то, что ему приписывали.
S>>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более. C>Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут.
Если не новое, то значит, где-то уже было. В таком случае назовите первоисточник.
Здесь Вы ошибаетесь. Опробованы были, и не слабо, и в серьезных разработках. И не только опробованы. Посмотрите на сайте. Да и в книге есть об этом. А уверенность – это опять же из области веры.
Предлагаю этим ограничить дискуссию. Тема исчерпана, количество информации стремится к нулю, а количество слов – растет. И конца этому не видно.
А на мое первое высказывание так и не было адекватного поста (.
Здравствуйте, serg0s, Вы писали:
C>>Другие авторы, однако, умудряются делать подобное. К примеру, код TeX'а у Кнута занимает примерно эти 100000 строк, что подтверждает хотя бы саму возможность "литературного программирования" в проектах длиннее "hello world". S>Вы запускали TeX?
Я им пользуюсь.
S>Кнут из разряда тех же сумасшедших. Только гениальных, которым можно. А поскольку написал библию, то ему все простили. Да и цель у него была на порядок сложнее, чем дракон. Кроме того, тогда был большой разнобой в языках, поскольку очень много народу писало на ассемблерах. И изобретение TeX было вынужденной мерой, только способом выбраться из этой ситуации, не более.
Опять мимо. TeX написан на Паскале (точнее, на C-WEB), и прежде всего является практической утиллитой — он документы форматирует.
S>Хотел охватить как можно больше народу. Он там прямо так и пишет. Сейчас этого нет, и такие подвиги бессмысленны. И пошел он на это только потому что взялся за глобальную задачу. Так что Вы предлагаете сопоставлять несопоставимое, а значит, подобные аргументы бессмысленны. Все равно что сравнить например, космический корабль и автомобиль. Возьмите пример хотя бы более-менее аналогичный дракону, поскромнее – скажем, Кернигана, Страуструпа или Вирта (хотя и это на мой взгляд несопоставимо). Почувствуйте разницу.
Керниган помогал писать первый Юникс на С, Страуструп писал на С++ компилятор С++, Вирт создал несколько компиляторов. У них у всех был практический опыт применения их языков.
Единственный чистый академик в современной информатике, которого я знаю, — это Дийкстра.
S>А почему бы Вам не потребовать 100000 строк от GoF? Или они для Вас – вне критики?
Авторы GoF систематизировали уже существующие знания, в том числе и по проектам гораздо большего размера. Так что к ним претензий нет.
C>>Я смогу её запустить и посмотреть что получится. S>И на чем же Вы хотите ее (диаграмму) запустить?
На компьютере. И не надо отмазываться сложностью реализации. Интепретаторы (да даже и компиляторы) языков при использовании современных инструментальных средств делается даже второкурсниками в качестве курсовых.
S>А если не на чем, то опять автор виноват?
Да.
S>Вы это серьезно? По-моему, без юмора относиться к таким заявлениям сложно.
Если это так, то книгам автора — в помойку.
C>>Нет. Я не требую ничего необычного. S>??? Вы требуете от автора гениальности Кнута – и это называется «ничего необычного»? Так можно и черное назвать белым.
Нет. Я не требую труда уровня Кнута. Я просто требую КАКУЮ-НИБУДЬ ПРАКТИЧЕСКУЮ РЕАЛИЗАЦИЮ его идей!!
C>>Если считать использованные мной протоколы, то счёт уже на десятки (если не на сотни..) пойдёт. S>Уровень приложения – так и называется. В описаниях протоколов есть.
Ссылку, на спеки, пожалуйста. Я знаю термин "уровень приложения" в модели OSI, но причём он тут — мне не понятно.
S>Так все-таки – написанные или использованные? Разница огромная.
Написанные, написанные.
C>>Ну в общем SQL победил — сейчас это практически единственный используемый язык для работы с данными, и самый распространённый при этом. S>Но заявлено было куда бОльшее. Говорилось, что он станет языком для простых юзеров (не программистов). А побеждать было некого – такого класса и для этих целей серьзных языков больше не было. И он занял подобающее ему место, но далеко не то, что ему приписывали.
Он используется и простыми пользователями. Причём даже там где и надо — в аналитике.
S>>>Паронджанов по крайней мере излагает новое. А GoF – это лишь хорошее рацпредложение – ничего нового нет. Систематизация, конечно, тоже нужное дело. Но не более. C>>Он не излагает новое, он предлагает некоторые идеи, которые даже не были опробованы на практике. И я уверен, что и не будут. S>Если не новое, то значит, где-то уже было. В таком случае назовите первоисточник.
Графического программирования? Это ещё в "Mythical Man-Month" про схемы было написано. Вообще, систем графического программирования было полно. Ни одна не прижилась.
S>Здесь Вы ошибаетесь. Опробованы были, и не слабо, и в серьезных разработках. И не только опробованы. Посмотрите на сайте. Да и в книге есть об этом. А уверенность – это опять же из области веры.
Ну покажите мне эти "разработки" — ткните носом. Чтоб я мог скачать и посмотреть как оно там всё круто работает.
Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось.
Я кстати попрощался с Вами еще в прошлом посте. Жаль что Вы этого не поняли.
Говорю открытым текстом: До свидания.
Здравствуйте, serg0s, Вы писали:
S>Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось.
Его и не было изначально.
S>Я кстати попрощался с Вами еще в прошлом посте. Жаль что Вы этого не поняли. S>Говорю открытым текстом: До свидания.
Да пожалуйста. Таких обиженных тут толпами ходят — кто с Обероном, кто с ТРИЗом. Теперь вот и "Дракон" в этот список добавится.
Здравствуйте, Cyberax, Вы писали:
S>>Это уже не разговор. Это базар. Чем дальше в лес тем больше дров. Посты все больше а толку уже никакого не осталось. C>Его и не было изначально.
Видите ли, Cyberax, вы прямо-таки погрязли в спеси. Построянно требовать якобы отсутствующего применения графического языка Паронджанова — значит не удосужиться ознакомиться хотя бы с минимумом информации о нем.
А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ.
http://ru.science.wikia.com/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D
"К 1998 году все работы по системному программированию были завершены. На базе ДРАКОНА была построена автоматизированная технология проектирования программных систем ( CASE -технология) под рабочим названием «Графит-Флокс»., включающая в себя обширный комплекс программных средств: процедурный редактор, декларативный редактор, базу данных, транслятор, анализатор, кодогенератор и т.д. Автоматизированная Дракон-технология прошла испытания в работе над такими проектами, как : международный космический проект «Морской старт» ( Sea Launch ), российско-французский космический проект «Фрегат», модернизация ракеты-носителя «Протон-М». Поскольку результаты были стабильно высокими, руководство Пилюгинского центра приняло решение использовать дракон-технологию во всех последующих проектах"
Здравствуйте, tau797, Вы писали:
T>Видите ли, Cyberax, вы прямо-таки погрязли в спеси. Построянно требовать якобы отсутствующего применения графического языка Паронджанова — значит не удосужиться ознакомиться хотя бы с минимумом информации о нем. T>А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ.
Я их не видел, и не знаю что там внутри, и почему-то мне кажется, что там ничего технологически сложного нет. Конечно, для управления полётом нужны специальные мат. модели, но их сложность не относится к программированию.
Я когда-то лично делал софт управления устройствами. Фактически получается просто большая state-машина, где нужно аккуратно следить за переходами. Кстати, там действительно были полезными диаграммы состояний. Опять же, немного зная наши НИИ — там могли писать код на том, что выгодно защищающему докторскую диссертацию, а не на том, что лучше всего бы подошло.
С точки зрения надёжности — как-то графический подход не впечатляет. Например, у НАСА есть система верификации корректности кода, которую они используют для части систем ( http://javapathfinder.sourceforge.net/ ). Для Ады (и С++) есть Coverity и куча других средств. Всё доступно и можно пощупать руками. Ещё можно вспомнить парижское метро с полностью доказаным софтом.
Для "Дракона" же нет _ничего_. Например, на форуме "Дракона" — вообще полный детский сад. Простите, но когда редактор всемогущего языка написан (криво) на _Дельфи_ — это просто смешно ( http://forum.oberoncore.ru/viewtopic.php?p=21559#p21559 ). Так что я по-прежнему хочу увидеть хоть один реальный проект. И самое прикольное, что я продолжаю быть увереным, что мне ничего не покажут.
Видите ли, Cyberax, вы упорствуете в своих заблуждениях и ограниченности. T>>А ВЕДЬ ОНА ПРИМЕНЯЕТСЯ, И ДОСТАТОЧНО ДАВНО И УСПЕШНО, ПРИ СОЗДАНИИ ВЕСЬМА СЕРЬЕЗНЫХ И ОТВЕТСТВЕННЫХ ПРОГРАММНЫХ СИСТЕМ — СИСТЕМ УПРАВЛЕНИЯ КОСМИЧЕСКОЙ ТЕХНИКОЙ. C>Я их не видел, и не знаю что там внутри
Тем не менее, находите возможным заявить:
C>почему-то мне кажется, что там ничего технологически сложного нет
Не могу удержаться и не процитировать народную мудрость: "Когда кажется — крестятся".
C>сложность не относится к программированию
Что значит "сложность не относится к программированию"? Кто решает, "к программированию" или нет относится сложность построения системы управления реального времени с высочайшими требованиями к надежности? В данной предметной области приходится иметь дело с весьма сложными системами и ситуациями, требующими синхронизации многих параллельно протекающих процессов с различными вариантами как в логическом, так и временном пространствах. При этом в современных КА задачи эти решаются именно с помощью бортового ПО.
C>Я когда-то лично делал софт управления устройствами. C>Фактически получается просто большая state-машина, где нужно C>аккуратно следить за переходами.
"Большая state-машина" — это, по-Вашему, "просто"?
При этом вы еще оставляете "за скобками" реальное время.
C>Кстати, там действительно были полезными диаграммы состояний.
Ага, все-таки хоть что-то признаете, это уже хорошо.
C>Опять же, немного зная наши НИИ — там могли писать код на том, C>что выгодно защищающему докторскую диссертацию, а не на том, C>что лучше всего бы подошло.
Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности? Почитайте там выше — и "Морской старт", и прочее. Да и "Буран" прошу не забывать — для него этими самыми людьми была разработана передовая технология создания высоконадежного бортового ПО, с десятикратным ростом производительности труда!
C>С точки зрения надёжности — как-то графический подход не C>впечатляет
Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему?
C>Например, у НАСА есть система верификации корректности кода, C>которую они используют для части систем ( C>http://javapathfinder.sourceforge.net/ ) C>Для Ады (и С++) есть Coverity и куча других средствЭто хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС
C>Всё доступно и можно пощупать руками... C>Для "Дракона" же нет _ничего_. Например, на форуме "Дракона"
Не там ищете. Хотя вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС. "Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет.
C>Ещё можно вспомнить парижское метро с полностью доказаным C>софтом
Очень сильное заявление. Зуб дадите?
C>Например, на форуме "Дракона" — вообще полный детский сад. C>Простите, но когда редактор всемогущего языка написан (криво) C>на _Дельфи_ — это просто смешно (
Форум — это форум, там, так сказать, народная "инициатива снизу". Кстати, насколько я помню, написано и не на Дельфи
(что вы, между прочим, имеете против дельфи?).
Впрочем, речь не о том. А о ГРАФИТ/ФЛОКС в НПЦ АП — реальной системе на серьезном предприятии, используемой успешно в серьезных проектах — «Морской старт»,«Фрегат»,«Протон-М».
C>что я по-прежнему хочу увидеть хоть один реальный проект. И C>самое прикольное, что я продолжаю быть увереным, что мне C>ничего не покажут
Ну если вы в упор не видите — кто ж вам виноват.
Не уверен, что вы вообще адекватно способны оценить сложность проектов по созданию космической техники. Особенно по сравнению с так называемыми "реальными проектами" в мейнстриме ИТ.
Здравствуйте, tau797, Вы писали:
C>>сложность не относится к программированию T>Что значит "сложность не относится к программированию"?
То и значит. Решение сложного диффура численными методами — это вопрос вычислительной математики. С точки зрения программирования — в большей части вычислительных методов нет ровно никакой сложности, хоть на Фортране можно их писать (собственно, чаще всего на нём и пишут).
C>>Я когда-то лично делал софт управления устройствами. C>Фактически получается просто большая state-машина, где нужно C>аккуратно следить за переходами. T>"Большая state-машина" — это, по-Вашему, "просто"? T>При этом вы еще оставляете "за скобками" реальное время.
Причём оно здесь?
C>>Кстати, там действительно были полезными диаграммы состояний. T>Ага, все-таки хоть что-то признаете, это уже хорошо.
Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал.
C>>Опять же, немного зная наши НИИ — там могли писать код на том, C>что выгодно защищающему докторскую диссертацию, а не на том, C>что лучше всего бы подошло. T>Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности?
Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового.
T>Почитайте там выше — и "Морской старт", и прочее. Да и "Буран" прошу не забывать — для него этими самыми людьми была разработана передовая технология создания высоконадежного бортового ПО, с десятикратным ростом производительности труда!
Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код.
C>>С точки зрения надёжности — как-то графический подход не C>впечатляет T>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему?
Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто.
C>>Например, у НАСА есть система верификации корректности кода, C>которую они используют для части систем ( C>http://javapathfinder.sourceforge.net/ ) C>>Для Ады (и С++) есть Coverity и куча других средств T>Это хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они T>должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС
Нельзя доказать корректность того, чего ещё нет. Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
C>>Для "Дракона" же нет _ничего_. Например, на форуме "Дракона" T>Не там ищете. Хотя вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС.
Для меня её всё равно что не существует.
T>"Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет.
Странно, вот NASA открыто публикует многие свои инструменты, стандарт Ады — открытый и доступный всем.
C>>Ещё можно вспомнить парижское метро с полностью доказаным C>софтом T>Очень сильное заявление. Зуб дадите?
Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть.
C>>Например, на форуме "Дракона" — вообще полный детский сад. C>>Простите, но когда редактор всемогущего языка написан (криво) C>на _Дельфи_ — это просто смешно ( T>Форум — это форум, там, так сказать, народная "инициатива снизу". Кстати, насколько я помню, написано и не на Дельфи T>(что вы, между прочим, имеете против дельфи?).
Написано на Дельфи (я посмотрел). Против Дельфи я ничего не имею, но "Дракон" же в 10 раз увеличивает производительность труда, да? Значит можно было бы переписать редактор "на коленке" за неделю, даже с учётом переписывания всего VCL!
C>>что я по-прежнему хочу увидеть хоть один реальный проект. И C>самое прикольное, что я продолжаю быть увереным, что мне C>ничего не покажут T>Ну если вы в упор не видите — кто ж вам виноват.
Не вижу. Мне нужно всего-то посмотреть исходный код проекта.
T>Не уверен, что вы вообще адекватно способны оценить сложность проектов по созданию космической техники. Особенно по сравнению с так называемыми "реальными проектами" в мейнстриме ИТ.
Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании.
Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, tau797, Вы писали:
C>>>сложность не относится к программированию T>>Что значит "сложность не относится к программированию"? C>То и значит. Решение сложного диффура численными методами — это вопрос вычислительной математики. С точки зрения программирования — в большей части вычислительных методов нет ровно никакой сложности
Речь вовсе не шла о вычислительной математике.
C>>>Я когда-то лично делал софт управления устройствами. C>>Фактически получается просто большая state-машина, где нужно аккуратно следить за переходами. T>>"Большая state-машина" — это, по-Вашему, "просто"? T>>При этом вы еще оставляете "за скобками" реальное время. C>Причём оно здесь?
При том, что многими системами необходимо управлять в реальном масштабе времени.
C>Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал.
Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа?
T>>Как вам не стыдно вот так, походя, оскорблять кучу незнакомых вам людей? За которых лучше всего говорят результаты их деятельности? C>Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового.
"Я не вижу" и "в моей области" не значит, что этого нет в природе. "Есть многое на свете, друг Горацио..."
Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены.
C>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код.
А вы легендами питаетесь? Или фактами?
"Программное обеспечение БЦВК не имеет аналогов среди отечественных систем управления летательных аппаратов как по масштабам и объему разработки, так и по многообразию и сложности решаемых задач... Сложность разработки ПО для ОК состояла в том, что наряду с традиционными для КА задачами управления движением впервые все задачи управления и контроля бортовых систем были реализованы с помощью управляющих программ БЦВК. Значительное число (более 50) бортовых систем и разнородность их задач потребовали различных подходов при реализации управляющих программ. Создание ПО усложнялось большим числом внешних связей как с цифровыми абонентами (БЦВМ сложных систем и приборы, воспринимающие коды БЦВК), так и с получателями релейных команд, с которыми БЦВК общается через дешифраторы. Обеспечение управления движением ОК оказалось весьма трудным делом, что объясняется достаточно сложной динамйческой схемой ОК как объекта управления и принципиально новыми для отечественного и мирового авиа- и ракетостроения задачами: аэродинамическим спуском в плотных слоях атмосферы с гиперзвуковой скоростью, приведением в район ВПП посадочного комплекса и "безмоторной" автоматической посадкой на ВПП. Выполнение этих задач потребовало тесного взаимодействия программ управления движением с программами бортовых систем, причем режимы управления движением, как правило, являются определяющими. Для орбитального управления движением ОК вследствие большого числа нештатных ситуаций характерно многообразие режимов работы с произвольной последовательностью их выполнения. ПО обеспечивает парирование отказов двигателей орбитального маневрирования при выведении, межорбитальных переходах и при сходе с орбиты, ведет учет расхода горючего и окислителя и, при необходимости, регулирование центровки ОК и его номинальной посадочной массы путем слива излишков топлива через тракт двигателей. В случае отказов ракетных блоков I и II ступеней РН СУ ОК обеспечивает в автоматических режимах его аварийное возвращение на ВПП стартового комплекса путем выполнения маневра возврата или выхода на одновитковую траекторию. Высокие требования к точности управления движением обеспечиваются применением усложненных алгоритмов с учетом факторов, которыми ранее пренебрегали. Важной особенностью управления бортовыми системами является программное управление их резервированием. Сложная логика управления избыточностью требует проведения коммутации соответствующих схем и элементов строго по циклограммам управления, поэтому БЦВК не только анализирует числовые значения контрольных величин, но и задает и контролирует временные соотношения в ходе выполнения полетных задач. Алгоритмы управления бортовыми системами проектируются разработчиками систем автоматического управления и передаются программистам для кодирования в системе команд БЦВК. Программы БЦВК отрабатываются автономно на универсальных ЭВМ, где их коды проверяются на соответствие исходным алгоритмам управления. После этапа автономной отработки программы БЦВК проходят комплексные испытания с реальным БЦВК и аппаратурой бортовых систем. Это сложный и наиболее трудоемкий этап разработки ПО, в ходе которого вскрываются не только программные, но и алгоритмические ошибки, вызванные неверным комплексным проектированием или недопониманием сложных аспектов функционирования реальной аппаратуры. При разработке ПО БЦВК достигнуть корректности алгоритмов столь большого комплекса управления было сложно, поэтому для интеграции отдельных программ в единый комплекс ПО потребовалась строгая дисциплина их написания, выдержанная с помощью специализированного языка высокого уровня, что позволило описать не только бортовые алгоритмы управления, но и поведение реальной аппаратуры для моделирования процесса управления на универсальных ЭВМ... Большие информационные потоки, циркулирующие между БЦВК и смежной аппаратурой, заставляют каналы ввода-вывода БЦВМ работать с предельной загрузкой... Для предстартовой подготовки (ПСП) ОК впервые в отечественной практике был применен резервированный вычислительный комплекс на базе общепромышленных ЭВМ, которые позволяют на высоком уровне решать вопросы индикации и документирования ПСП, а их универсальные программные средства — существенно облегчить написание и отладку ее программ, сэкономить время и людские ресурсы. Впервые в отечественной практике на базе трех ЭВМ для осуществления пусковых операций был создан трехканальный синхронный вычислительный комплекс, в котором совместная работа каналов резервирования обеспечивалась специально разработанным аппаратно-программным механизмом, использующим метки начала цикла БЦВК.
Анализ исходных данных для написания программ показал наличие в них большой "информационной загрузки", а опыт предшествующих разработок ПО — неизбежность огромных потерь времени вследствие коррекций в алгоритмах, кабельных связях, адресах абонентов и параметрах признаков. Для автоматизации этого процесса и исключения ручного труда и во избежание внесения дополнительных ошибок была создана информационная система, включающая базу данных с адресами контролируемых параметров и кодовыми конструкциями, принимаемыми или посылаемыми от проверяемой аппаратуры, а также специальный язык описания исходных данных, позволяющий автоматизировать процесс формирования программ на языке универсальной ЭВМ. При таком способе составления программ испытаний при изменениях в электрических схемах или программах БЦВК новые данные вносятся в базу данных информационной системы, которая автоматически определяет новые адреса и кодовые конструкции. Таким образом, коррекция связана лишь с автоматической перетрансляцией программы без изменения текста программы. Такая технология создания ПО позволила в сжатые сроки создать единый бортовой и наземный комплексы ПО общим объемом около 100 Мбайт"
T>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто.
Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул...
C>>>у НАСА есть система верификации корректности кода, ... есть Coverity и куча других средств T>>Это хорошо и чудесно, конечно. Однако обратили ли вы внимание на то, что верифицируют эти системы отнюдь не все интересные качества программы, а кроме того — они T>должна на входе получить готовую программу. А не относятся к этапу проектирования, как ГРАФИТ/ФЛОКС C>Нельзя доказать корректность того, чего ещё нет.
Можно предложить технологию программирования, которая обеспечит создание корректного ПО.
C>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос.
T>>вам русским языком написали о существовании технологии разработки программ, поддержанной соответствующими средствами автоматизации — ГРАФИТ/ФЛОКС. C>Для меня её всё равно что не существует.
Потрясающий по силе аргумент.
T>>"Пощупать" вы ее не можете по вполне понятным причинам — она применяется на предприятии, занимающемся проектами с очень высокой степенью секретности, в том числе, например, системой управления "Тополей М". Это не значит, что системы нет. C>Странно, вот NASA открыто публикует многие свои инструменты
Как вы думаете, все?
C>Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть.
Спасибо за ссылку, очень интересно! Может, еще чем поделитесь? Особенно интересно по поводу "B-метода".
Вот вам взамен: www.hardline.ru/1/12/1059/
Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского...
C>>>я по-прежнему хочу увидеть хоть один реальный проект. И самое прикольное, что я продолжаю быть увереным, что мне ничего не покажут T>>Ну если вы в упор не видите — кто ж вам виноват. C>Не вижу. Мне нужно всего-то посмотреть исходный код проекта.
Вряд ли вам покажут код системы управления "Тополем"...
C>Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании.
Вы каким-то странным произвольным образом отделяете "программирование" от обеспечения качества ПО (тут не только тестирование, тут много вопросов, связанных как раз с методами проектирования и верификации иными средствами — в том числе с применением графических средств).
C>Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт.
Хоть стой, хоть падай. Выше я уже привел данные по причинам сложности ПО "Бурана". Что вы имеете в виду, какие причины "сложности" в бухгалтерских программах??! Там вообще примитивная арифметика и последовательные вычисления.
Здравствуйте, tau797, Вы писали:
T>>>"Большая state-машина" — это, по-Вашему, "просто"? T>>>При этом вы еще оставляете "за скобками" реальное время. C>>Причём оно здесь? T>При том, что многими системами необходимо управлять в реальном масштабе времени.
Оно ортогонально представлению в виде state-машины.
C>>Я никогда не отрицал, что в нишевых областях некоторые части UML (и аналогичных им графических методов) бывают полезными. Блин, да я даже в этой теме об этом писал. T>Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа?
Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии.
У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов.
C>>Да совсем не стыдно. Я от российских НИИ не вижу пока в моей области ровно ничего нового. T>"Я не вижу" и "в моей области" не значит, что этого нет в природе. "Есть многое на свете, друг Горацио..." T>Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены.
Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие.
А вот информатика — в полной заднице.
C>>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код. T>А вы легендами питаетесь? Или фактами?
Я знаю лично человека, который писал код для Бурана.
T>При таком способе составления программ испытаний при изменениях в электрических схемах или программах БЦВК новые данные вносятся в базу данных информационной системы, которая автоматически определяет новые адреса и кодовые конструкции. Таким образом, коррекция связана лишь с автоматической перетрансляцией программы без изменения текста программы. Такая технология создания ПО позволила в сжатые сроки создать единый бортовой и наземный комплексы ПО общим объемом около 100 Мбайт"
Т.е. они создали что-то типа SCADA с графическим представлением узлов и соединений. Вполне обычная практика, даже я что-то подобное делал.
Я всё же хочу увидеть применение ДРАКОНа в качестве языка программирования общего пользования.
T>>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто. T>Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул...
Без исходников продираться через дебри невнятных описаний — бессмысленно.
C>>Нельзя доказать корректность того, чего ещё нет. T>Можно предложить технологию программирования, которая обеспечит создание корректного ПО.
Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится.
C>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация. T>Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос.
Ага. "Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet." (c) Ферма.
C>>Странно, вот NASA открыто публикует многие свои инструменты T>Как вы думаете, все?
Достаточно заметную часть.
C>>Что "сильное"? К примеру, смотри: http://www.bmethod.com/dl/thierry_lecomte/TL_FM2008_Metro_Platform_Screen_Doors_Control_Command_Systems.pdf — и это отчёт не по всему софту, там ещё много чего другого интересного есть. T>Спасибо за ссылку, очень интересно! Может, еще чем поделитесь? Особенно интересно по поводу "B-метода".
Это применение работ по доказательству кода, на эту тему тонны литературы написаны.
T>Вот вам взамен: www.hardline.ru/1/12/1059/ T>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского...
Вот это уже интереснее. Но опять, нет видимого результата.
T>>>Ну если вы в упор не видите — кто ж вам виноват. C>>Не вижу. Мне нужно всего-то посмотреть исходный код проекта. T>Вряд ли вам покажут код системы управления "Тополем"...
Так почему нет ничего другого-то??
C>>Сложность в "космических" проектах не лежит в сложности программирования. Она лежит в обеспечении качества и тщательном тестировании. T>Вы каким-то странным произвольным образом отделяете "программирование" от обеспечения качества ПО (тут не только тестирование, тут много вопросов, связанных как раз с методами проектирования и верификации иными средствами — в том числе с применением графических средств).
Почитай отчёт о создании софта для Шаттлов. Заметь сколько там относится к техникам программирования, а сколько к технике организации работ.
Это близкие области, но далеко не одно и то же.
C>>Мейнстримовая бухгалтерия запросто может по объёму и сложности технологий превышать космический софт. T>Хоть стой, хоть падай. Выше я уже привел данные по причинам сложности ПО "Бурана". Что вы имеете в виду, какие причины "сложности" в бухгалтерских программах??!
Обыкновенные.
T>Там вообще примитивная арифметика и последовательные вычисления.
А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность.
Увы, конструктивного диалога с вами не получилось в силу вашего упорства в заблуждениях и ограниченности мышления C>Здравствуйте, tau797, Вы писали:
T>>>>"Большая state-машина" — это, по-Вашему, "просто"? При этом вы еще оставляете "за скобками" реальное время. C>>>Причём оно здесь? T>>При том, что многими системами необходимо управлять в реальном масштабе времени. C>Оно ортогонально представлению в виде state-машины.
Нет. Обычный (нетаймированный) автомат неспособен адекватно описать систему реального времени.
T>>Вот и замечательно. Значит, готовы признать свою ошибку, принести извинения и признать полезность ГРАФИТ/ФЛОКСа? C>Нет. Пока мне их не продемонстрируют, так как в книге их пиарят вовсе не как нишевые технологии.
Если бы вы потрудились почитать книгу Паронджанова, то наверняка обратили бы внимание на то, что пропагандирует он свой язык
не в качестве средства программирования, а как некий универсальный язык для описания алгоритмических аспектов в том числе деятельности
человека.
C>У меня by default недоверие к технологиям, которое можно вылечить только реальным кодом реальных проектов.
О вполне реальных проектах я вам писал неоднократно.
T>>Не исключено, кстати, что и в вашей области вы просто недостаточно осведомлены. C>Меня не особо интересуют другие области. Я и так знаю, что физики у нас хорошие.
У нас и программисты хорошие. О школе академика Ершова что-нибудь слышали, например?
C>А вот информатика — в полной заднице.
Если не брать производство аппаратных средств, а теорию — то чушь.
C>>>Про софт Бурана ходят легенды — его писали "мартышковым" методом. Т.е. любого кто хотя бы понял ТЗ садили писать код. T>>А вы легендами питаетесь? Или фактами? C>Я знаю лично человека, который писал код для Бурана.
И что? Он с вами подробно делился технологией разработки?
Да и вообще — делать столь далеко идущие выводы на основании единичного наблюдения некорректно.
C>Т.е. они создали что-то типа SCADA с графическим представлением узлов и соединений. Вполне обычная практика, даже я что-то подобное делал.
Попытка принизить чужое выдающееся достижение словами "вполне обычная" вас совсем не красит.
По поводу заявления о "подобном" Вот создали бы вы ПО для "Бурана" — тогда бы и заявляли "я что-то подобное делал".
T>>>>Как он может вас "впечатлять" или "нет", если у вас просто отсутствует информация на эту тему? C>>>Она не отсутствует, её просто нет. Когда-то я этим интересовался и искал публикации — нет их просто. T>>Дело в значительной степени в традиционной секретности работ, осуществляемых в космической промышленности и ВПК в СССР/России. Впрочем, кое-что я ниже упомянул... C>Без исходников продираться через дебри невнятных описаний — бессмысленно
Неверный посыл.
C>>>Нельзя доказать корректность того, чего ещё нет. T>>Можно предложить технологию программирования, которая обеспечит создание корректного ПО. C>Нет. Доказательство соответствия программы и спецификации — это нетривиальная задача. Просто так оно само не получится.
Я не говорил, что задача — тривиальная. Кстати, при создании вами же упомянутой системы управления парижским метро 14 ветки используется
так называемая "B-технология", именно позволяющая генерировать гарантированно соответствующие спецификации программы. И они в этом не одиноки
C>>>Если у нас есть спецификация алгоритма, достаточно подробная, чтобы доказать её корректность, то это УЖЕ будет почти что готовая его реализация.
Точно, именно так ПО для парижского метро и делали.
T>>Вы не правы, хотя рамки сообщения на форуме не позволяют мне подробно осветить здесь этот вопрос. C>Ага. "Cuius rei demonstrationem mirabilem sane detexi. Hanc marginis exiguitas non caperet." (c) Ферма.
Типа того
C>на эту тему тонны литературы написаны.
Ну, спасибо вам большое за конструктивное сотрудничество.
T>>Вот вам взамен: www.hardline.ru/1/12/1059/ T>>Вы, кстати, жаловались на отсутствие публикаций — можете посмотреть и другие труды Крюкова, Петренко, Смелянского... C>Вот это уже интереснее. Но опять, нет видимого результата.
Меня утомила ваша "непробиваемость". Полет "Бурана" транслировался по ТВ. Существует множество телепередач и иных материалов, посвященных этому знаменательному событию. "Фрегаты" и "Протоны-М" стартуют с завидной регулярностью. Пуски также демонстрируются по ТВ. Может, со зрением просто проблемы?
Дальше вы уже перешли на хамство, что вынуждает меня отказаться от продолжения дискуссии с вами. Позволю себе напомнить,
что на брудершафт мы, слава Богу, не пили. C>Почитай отчёт о создании софта для Шаттлов. Заметь
C>сколько там относится к техникам программирования, а сколько к технике организации работ.
Технология программирования включает в себя и методы проектирования, и методы документирования, и методы отладки.
C>А ещё необходимость обеспечивать бизнес-процессы, отражающие гибкость реального мира. Где и скрывается вся сложность.
"Бизнес-процессы" — поганое модное словечко. Если же рассматривать суть, то "сложность" процессов в бухгалтерии вряд ли сопоставима со сложностью управления в реальном времени десятками взаимодействующих друг с другом и с внешней средой систем.
.
. И похоже, спор грозит стать бесконечным 
Зуб дадите?
— кто ж вам виноват.
Вот создали бы вы ПО для "Бурана" — тогда бы и заявляли "я что-то подобное делал".