Космический софт

[Алексей Кириенко]

Ответить на сообщение 2005 года в 2025-м - это ли не некропостинг? 

Упс ! Не заметил . Но тема интересная и поднять ее будет неплохо.
Например в свете использования ИИ и прочих нейросетевых технологий .    

[TAU]

1. М-да, «как всё запущено»!

2. «Система визуального программирования «Дракон» — нет слов! Нет, во времена «Бурана» это была футуристическая по самое не могу разработка из будущего... Но сейчас? (И даже в 2014-м)
Вспоминать эту поделку?? Серьезно?! Народ, у меня нет слов! 

3.    У еще бы HiASM вспомнили (https://hiasm.com)

4. (Дело в том, что у них полно нигде не документированных причуд и крайне неявных особенностей, и да, схемы «супер-визуальных» сред разработки — это близко не алгоритм.)

5. "И публикация.." Не открывается .

1. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.

2. См. пункт первый. И если есть претензии к языку - высказывайте по существу.

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

4. Схема алгоритма его вполне себе задает. Будете спорить?

5. Здесь попробуйте https://cyberleninka.ru/article/n/puti-povysheniya-nadezhnosti-i-kachestva-programmnogo-obespecheniya-v-kosmicheskoy-otrasli

[Алексей Кириенко]

1. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.

Надеюсь что вы правы. (Просто я несколько лет назад стакивался с "Драконом", то что он надежнее  того-же HiАsm-а несомненно, но уровень разработки в плане поддержки современных инструментов и методик  показался мне чудовищно низким  )

Основная суть проблемы "супер-визуального" программирования и прочих кейс-сред разработки что их внешняя наглядность иногда достигается крайне непрозрачными методами.

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

 Нет если набраться опыта  то преодолеть  особенности "зеро-кодинга" и супер-визуального программирования частично возможно, но гарантий того, что сложная программа не будет "зависеть от фазы Луны и отраженного света Венеры "   гораздо меньше чем при классическом программировании.
(у "классики"   существенно меньше "зазор" между кодом, алгоритмом его  реализаций и скрытыми неявными условиями эксплуатации )         
Зы
Сейчас я не более чем "кустарно практикующий программирование любитель-дилетант". Так что разумеется  ни на какую  истину  любой  инстанция я  претендовать не могу

[Алексей Кириенко]

4. Схема алгоритма его вполне себе задает. Будете спорить?

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

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

[TAU]

4. Схема алгоритма его вполне себе задает. Будете спорить?

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

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

Ваши "множественное наследование" и "дженерики" в программировании "на космос" практически не применяются. Из-за излишней сложности и связанных с ней опасностей. Просто - значит надежно!

А дополнительная информация в самых разных видах, само собой, при визуальном программировании в космической отрасли используется. Даже изначальный ГРАФИТ-ФЛОКС состоит из двух частей в названии не случайно.

[TAU]

1. Вы просто не в теме. В порядке инструменты и в штатной эксплуатации. Уже на протяжении долгих лет.

Основная суть проблемы "супер-визуального" программирования и прочих кейс-сред разработки что их внешняя наглядность иногда достигается крайне непрозрачными методами.

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

1. Для космоса стараются не доводить до слишком "сложных" программ. Используется декомпозиция.

2. Инструменты для разработки "на космос" сами по себе проходят более качественную проверку, нежели в коммерческом ширпотребе.

3. Построенные программы проходят многостадийную отладку на НОК.