Особенности программирования БВК АМС

[Unispace]

Всегда есть люди, читающие по диагонали

Все люди субъективны, и все люди ошибаются. Только есть еще такие вроде вас, которые упрямо отстаивают собственные ошибки, игнорируя единственное мерило истины - практику.

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

[Штуцер]

Дублирование и троирование - это способ восстановления после аппаратных ошибок.

Эт Вы зря. "Горячее" дублирование и троирование - это способ не замечать аппаратных ошибок

Я бы разделил.
Дублирование - способ восстановления после аппаратных ошибок.
Требует, как правило анализа и принятия решения.
Троирование - это способ не замечать аппаратных ошибок.

[zyxman]

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

У меня уже достаточно практики с железом - оно мне уже стало скушно, и я перешел к сложным системам, в том числе к Эрлангу

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

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

[khach]

Троирование - это способ не замечать аппаратных ошибок.

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

[Unispace]

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

[Unispace]

Троирование - это способ не замечать аппаратных ошибок.

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

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

[zyxman]

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

А я самый скромный в мире человек :lol:

[Not]

А я самый скромный в мире человек :lol:

zyxman, вы общаетесь с фонтаном. Здесь нужен сантехник  

[Вадим Семенов]

Про ассемблер. Все как в этом мире. Чтобы чему-то научиться, нужно начинать с азов, с основ. Человек, начинавший программировать на асме, всегда будет программировать намного тщательнее, умнее и оптимальнее на любом языке, чем младой кодировщик, разговаривающий на языке очень высокого уровня  Я лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC  

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

[bs]

Ох уж мне эти подстольные программисты... ну да ладно - сам таким был  :wink:

[Unispace]

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

Осталось объяснить персонам, которые это не понимают. И не поймут, из всех дурацких околотехнических снобов, которых я видел - самые дурацкие были в среде "чистых" программистов. Им гораздо легче пространно витийствовать, чем что-то сделать в железе - это ведь  куда сложнее. Когда я учился, было хорошо видно такое разделение. Кто не умел толком ничего делать - шел в окошки и в нарождающиеся конторки, продвигающие всякие СУБД и ворды. Очень умно начинал рассуждать, только вот в среде промышленности они были пшиком. А теперь таких большинство. Пройдет еще одно поколение, взрощенное на снобизме высокого программирования - и мы уже не сможем снабдить ПО даже ФГ. Для этих людей мясо растет в пельменях. И так во всех сферах промышленности, потому что ее уже наполовину нет.

[zyxman]

Во вяском случае программист real-time и embedded систем уж точно должен понимать, как оно там физически работает.

Понимать должен. Но делать не должен.
Как раз именно в нынешнее время программист должен как и любой инженер уметь найти и применить готовое решение.
Потому что готовый отлаженный код экономит время и повышает надежность.

[Cyberax]

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

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

Так что же, они пишут его вовсе не на ассемблере. И даже не на С или С++ - так как цена ошибки слишком велика.

Они его пишут на специальном языке VDM, в котором корректность программ доказывается формально. Для исполнения используют высоконадёжные промышленные чипы.

[zyxman]

VDM тоже чистый функциональный подход.

[TAU]

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

VDM... ммммм... Это часом не язык для описания аппаратуры?

Или имеется в виду Венский подход к описанию семантики языков программирования?

Определения из Интернета:
http://www.encyclo.co.uk/define/VDM

[TAU]

если человек в достаточно молодом возрасте достаточно имел дело с машинами вроде PDP, Vax, m68k, там уже совсем другая ситуация наблюдается - там ведь есть богатый простор для оптимизации и для изощрений и это развивает мозг и позволяет лучше и быстрее воспринимать новое и эффективнее новое использовать

Я лучше взял бы человека лет 40, начинавшего на МК-61, чем 25летнего, не видевшего ничего глубже окошек VC  

Это же про меня! Про меня! :lol:

Значит, меня бы взяли Unispace не даст умереть с голоду на старости лет...

[TAU]

у НАСА... у нас...

Простите за личный вопрос, Вы работаете в НАСА?

ПО Mars Science Laboratory написано на С, содержит 2.5 миллиона строк кода и исполняет порядка 130 конкурентных процессов

Это который запускают сейчас? А откуда дровишки? не поделитесь?

По поводу Си же можно лишь пожалеть.

[TAU]

из всех дурацких околотехнических снобов, которых я видел - самые дурацкие были в среде "чистых" программистов

Да, есть подобное  

[bs]

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

Да эти утопические рассуждения не ведут никуда. Если так пойдет, то единственным логичным эволюционным исходом станет внедрение все более современных технических средств, которые позволят иметь и окошки, и реальное время  одновременно. И проблема будет решена. Не идеально, но реально :lol:

[zyxman]

VDM... ммммм... Это часом не язык для описания аппаратуры?

тут неплохое описание:
http://en.wikipedia.org/wiki/Vienna_Development_Method

Или имеется в виду Венский подход к описанию семантики языков программирования?

Не семантики языков, а СИСТЕМ вообще.
И да, Венский подход.