Здравствуйте, Васильич, Вы писали:
В>Золотые слова. Работа программиста сравнима с работой инженера проектирующего самолет, но при этом обладает таким вреднейшим качеством, как кажущаяся легкость модификации уже сделанного.
Совершенно согласен, хотя никак не могу понять, почему же математики не производят аналогичного говнища, несмотря на то, что "легкость модификации" результатов их труда вполне сопоставима.
I> почему же математики не производят аналогичного говнища, несмотря на то, что "легкость модификации" результатов их труда вполне сопоставима.
это вызвано лишь ошибкой твоего восприятия: с ошибками программ ты встречаешься каждый день, а с ошибками математиков ты не встречаешься.
взять хотя бы теорему ферма — за последние сто лет разного рода математиками было сформированы, наверное, миллионы доказательств ее правильности и все они оказались неверными, кроме последнего.
Здравствуйте, HrorH, Вы писали:
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Если рассматривать программирование через призму управления сложностью, то всё получается гораздо лучше, чем обычно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, HrorH, Вы писали:
HH>> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH>> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
IT>Если рассматривать программирование через призму управления сложностью, то всё получается гораздо лучше, чем обычно.
Извините, можно для тупых поподробнее или может быть ссылки на какую-то литературу.
Здравствуйте, VsevolodC, Вы писали:
VC>Здравствуйте, vsb, Вы писали:
vsb>>Программы без ошибок появятся, когда появится искусственный интеллект.
VC>ИИ не "появится", его создадут. И тоже с ошибками...
При этом способность совершать ошибки будет заложена в сам ИИ
Здравствуйте, DarkGray, Вы писали:
DG>это вызвано лишь ошибкой твоего восприятия: с ошибками программ ты встречаешься каждый день, а с ошибками математиков ты не встречаешься.
По-моему это самоуспокоение, тем более, что таким же образом можно попытаться убедить меня, что и у инженеров ошибок не меньше, но ведь это уж точно не так, о том, как работают инженеры какое-никакое представление у меня есть.
Здравствуйте, HrorH, Вы писали:
IT>>Если рассматривать программирование через призму управления сложностью, то всё получается гораздо лучше, чем обычно. HH>Извините, можно для тупых поподробнее или может быть ссылки на какую-то литературу.
Здравствуйте, HrorH, Вы писали:
HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
А если это не так и причина в другом? Делая какое-то конечное умозаключение останавливаем мыслительный процесс, чтобы сказать что-то на вроде
HH> Программирование — еще молодая область, возможно лет через сто появится нормальная методология разработки, которая позволит человеку не совершать ошибок...
возможно через сто лет. Почему сто лет, почему не сейчас? Зачем ждать сто лет, тем более, что большинство явно не доживёт?
I>о том, как работают инженеры какое-никакое представление у меня есть.
ты свой единичный опыт, что инженеры работают "лучше", чем программисты — распространяешь на всю отрасль: что все инженеры работают лучше, чем программисты. на основании чего ты делаешь такой переход?
Шаттл с 6 космонавтами, например, взорвался по инженерным причинам, а не по программным.
При этом тот же Фейнман говорит, что это была не случайность, и что состояние инженерного комплекса было много хуже, чем программного.
В итоге хотелось бы заметить, что система проверки программного обеспечения компьютеров действительно показывает себя как высококачественная. Судя по всему, там нет места постепенному самообману путем снижения норм, что весьма характерно для систем безопасности твердотопливных ракета-носителей и основных двигателей шаттла. Для вящей убедительности добавлю, что руководство недавно предлагало прекратить такие сложные и дорогие испытания за их ненадобностью в последнее время истории запусков шаттла.
При этом с двигателями было все намного хуже:
За 250 000 секунд работы основные двигатели отказывали, вероятно, раз 16.
Список некоторых проблем (и их состояния):
Трещины лопаток турбины в топливных турбонасосах высокого давления (ТТНВД). (Возможно, решена.)
Трещины лопаток турбины в кислородных турбонасосах высокого давления (КТНВД). (Не решена.)
Пробой линии форсажного искрового воспламенителя (ФИВ). (Возможно, решена.)
Отказ контрольного вентиля для выпуска газов. (Вероятно, решена.)
Эрозия корпуса ФИВ. (Вероятно, решена.)
Растрескивание листового металла корпуса турбины ТТНВД. (Вероятно, решена.)
Повреждение футеровки труб для охлаждения ТТНВД. (Вероятно, решена.)
Отказ выходного коленчатого патрубка основной камеры сгорания. (Вероятно, решена.)
Смещение сварного шва входного коленчатого патрубка основной камеры сгорания. (Вероятно, решена.)
Субсинхронный вихрь КТНВД. (Вероятно, решена.)
Система аварийного отключения ускорения полета (частичный отказ системы с резервированием). (Вероятно, решена.)
Растрескивание подшипников. (Частично решена.)
Вибрация с частотой 4 000 герц, которая приводит некоторые двигатели в нерабочее состояние. (Не решена.)
Многие из этих, на первый взгляд, решенных проблем были видны уже на ранних стадиях использования новой конструкции: 13 из них появились в первые 125 000 секунд эксплуатации двигателя и только 3 – во вторые 125 000 секунд. Естественно, никогда нельзя быть уверенным, что все недостатки устранены; однако, возможно, в отношении некоторых недостатков стремились устранить не ту причину. Вполне разумно предположить, что в следующие 250000 секунд может произойти, по крайней мере, один сюрприз: вероятность равна 1/500 на двигатель на задание.
[..]
Инженеры в Рокетдайне, где производятся двигатели, оценивают полную вероятность как 1/10 000. Инженеры в Маршалле оценивают ее как 1/300, тогда как руководство НАСА, которому эти инженеры отправляют свои отчеты, утверждает, что вероятность равна 1/100 000. Независимый инженер, дающий НАСА консультации, счел разумной оценкой 1 или 2 к 100
[..]
Медленный сдвиг в направлении снижения коэффициента безопасности можно увидеть во множестве примеров.
Основная разница: это есть ли ОТК и как он построен. У инженеров есть лишь преимущество, что они на 100 лет больше потратили на выстраивание ОТК для проверки качества своей работы. А также сложностью входа на инженерный рынок: большинство решений делается уже существующими компаниями, у которых наработана школа ОТК. в программировании из-за его сильной изменчивости и низкого порога входа: есть большая доля новичков, которые не имеют выстроенного подхода к ОТК. В тоже время большое кол-во новичков и низкий порог входа обеспечивает бурное развитие отрасли.
добавлю, что очень важный показатель надежности системы: это запас прочности.
при этом в инженерной отрасли не ставится под сомнение необходимость такого запаса.
в программировании же до сих пор многие считают, что запас прочности это неважно — и используют тот же C/C++, которые не имеет запаса прочности вообще, и любая малейшая ошибка может привести к произвольным катастрофическим последствиям.
Здравствуйте, DarkGray, Вы писали:
DG>ты свой единичный опыт, что инженеры работают "лучше", чем программисты — распространяешь на всю отрасль: что все инженеры работают лучше, чем программисты. на основании чего ты делаешь такой переход?
По меньшей мере половина проблем возникавших со всякими электронными штуковинами, которыми я пользовался, были софтверного, а не хардверного характера. Причем повседневную битву с (Windows) компьютером, на работе или дома я не считаю, не считаю также и проблемы неудобства пользования, в конце концов это субъективно. Только зависания, неожиданные перезагрузки и т.п. Вот возьмем мобильный телефон, там и компьютер, и радиопередатчик, и дисплей, и аккумулятор, все на таком уровне, который еще 20 лет назад был недостижим. Это же хайтек не хуже космоса и ядреного оружия, просто продается за копейки по причине массового производства. И все ведь работает как часы, проблемы только с говняным софтом. А что в софте том такого сложного?
Здравствуйте, DarkGray, Вы писали:
DG>которые не имеет запаса прочности вообще, и любая малейшая ошибка может привести к произвольным катастрофическим последствиям.
Здравствуйте, DarkGray, Вы писали:
DG>в программировании же до сих пор многие считают, что запас прочности это неважно — и используют тот же C/C++, которые не имеет запаса прочности вообще, и любая малейшая ошибка может привести к произвольным катастрофическим последствиям.
C++ говоришь? А вот у меня был телефон Siemens, так тот иногда начинал вдруг крайне медленно реагировать, похоже мусор собирал, гад.
Здравствуйте, HrorH, Вы писали:
HH>А как же повторное использование кода?
С повторным использованием всё впорядке. Предполагается, что программа состоит из большого числа узлов, блоков, назовите как угодно. Каждый узел получает, что-то на вход и отдаёт что-то на выходе. По факту это принцип электросхемы. Аналогично Юникс пайпс, язык FP Джона Бэкуса, APL.
HH>Или это была шутка?
Нет, но смеяться можно
I>Только зависания, неожиданные перезагрузки и т.п.
непонятно, почему ты считаешь, что это чисто софтварные проблемы.
это может быть вызвано вплоть до физических проблем, когда состояние бита меняется космическим излучением.
насколько я помню, для не ECC-памяти — это оценивается как три случая в год при непрерывной работе устройства.
Здравствуйте, HrorH, Вы писали: HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
Если предположить, что багов не должно быть вообще, то создание программы вырождается в нерешаемую задачу. Баги не побочный эффект программирования, баги это необходимый элемент программы. Собственно, любую программу можно представить как набор [потенциальных] багов.
Собственно, не стоит воспринимать баги как ошибки. Думаю, стоит говорить о недоработках.
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.
А вот это тебе только кажется. Если бы писали то, что приходит в голову, жизнь была бы чудесной. Я не знаю, куда приходит то, что обычно пишут в коде, но это явно не голова.
HH> Есть ли какой-то способ проектирования, который бы позволил если не избавиться от ошибок, то хотя бы минимизировать их число? HH> Может ли существовать какой-то паттерн мышления, которому надо следовать, чтобы добиться этого?
Нет. Нет.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, IT, Вы писали: IT>Если рассматривать программирование через призму управления сложностью, то всё получается гораздо лучше, чем обычно.
Если рассматривать программирование через призму управления сложностью, то либо ошибок нет вообще в принципе, либо любая конструкция по дефолту является ошибкой.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, DarkGray, Вы писали:
DG>непонятно, почему ты считаешь, что это чисто софтварные проблемы. DG>это может быть вызвано вплоть до физических проблем, когда состояние бита меняется космическим излучением. DG>насколько я помню, для не ECC-памяти — это оценивается как три случая в год при непрерывной работе устройства.
Не, ну я ж профи. Проблемы-то повторяются, во многих случаях я их репродуцировать могу.
Здравствуйте, Ромашка, Вы писали:
IT>>Если рассматривать программирование через призму управления сложностью, то всё получается гораздо лучше, чем обычно. Р>Если рассматривать программирование через призму управления сложностью, то либо ошибок нет вообще в принципе, либо любая конструкция по дефолту является ошибкой.
Не вижу в твоём утверждении логической связи между тем, что после 'если' и после 'то'.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
Если бы писали то, что приходит в голову, жизнь была бы чудесной. Я не знаю, куда приходит то, что обычно пишут в коде, но это явно не голова. 
