Ответственность программистов за баги

>хорошо, давайте с этой стороны зайдём - докажите это утверждение

Пруфлинк со своей стороны я привел. Теперь твоя очередь опровергать

нет, то что Вы привели на пруфлинк не покатит, ищите хотя бы здесь обоснования Вашей позиции, если своим мозгом не думается

Так о том и речь что математическая индукция это не индукция также как и морская свинка совсем не морская и совсем не свинка

>// глупый вопрос - глупый ответ

вы не знакомы с риторическими вопросами?

знаком, а вот Вы, смотрю, не очень

>неявно - практически всё время в данном топике

это твое личное умозаключение

да - моё личное, всё что тут я пишу содержит так или иначе моё личное умозаключение, и что, как это влияет на обсуждаемый вопрос?

Но компьютерная программа сама является моделью. Поэтому потенциально можно учесть все факторы

на практике этого никто не делает, подумайте почему

>поясните как «инстанция по допуску проектов к строительству» может предотвратить, к примеру, обваливание крыши по причине скрытого дефекта в опорной балке?

Никак. За это отвечает ОТК завода по выпуску балок.

Но будем считать это «аппаратной» проблемой.

Инстанция по допуску к строительству сможет исключит обвал здания по причине рас;%:«№?ва/необразованности проектировщиков.

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

А капиталист вообще может подумать: а давайте посчитаем, что дешевле, инстанция по контролю проектов с кучей инженеров + отделы ОТК при заводах + образоветльные курсы или стопицот таджиков с ведрами цемента и шпателем + развитое похоронное бюро при каждом доме.

И не исключено, что последний вариант таки дешевле.

Ecтественно дома - это косвенная аналогия. Но в определнном смысле очень наглядная.

>на практике этого никто не делает, подумайте почему

без учета всех факторов имеем неполную индукцию и следствия смотри выше

>поясните как «инстанция по допуску проектов к строительству» может предотвратить, к примеру, обваливание крыши по причине скрытого дефекта в опорной балке?

допустив к строительству ООО «Пизанская башня» закупающую у ЧП Джамшута балки неизвестного происхождения которые вероятно являются отбраковкой

а зачем это ООО занимается закупкой у вышеозначенного ЧП балок не получив допуск к строительству, не поясните?

которые вероятно являются отбраковкой

Вы не следите за мыслью, ещё раз, специально для Вас: скрытый дефект, который проявится у 1 балки из 1000, спустя некоторое время после строительства, как может комиссия его предотвратить?

>знаком, а вот Вы, смотрю, не очень

погда почему отвечаете? Риторические вопросы разве подразумевают ответ?

>Вы не следите за мыслью, ещё раз, специально для Вас: скрытый дефект, который проявится у 1 балки из 1000, спустя некоторое время после строительства, как может комиссия его предотвратить?

если бы скрытые дефекты встречались бы с такой частотой то дома бы падали, посчитай сколько балок в среднего размера 15-этажке. К тому же должен имется запас прочности за чем комиссия и следит

>поясните как «инстанция по допуску проектов к строительству» может предотвратить, к примеру, обваливание крыши по причине скрытого дефекта в опорной балке?

Никак.

значит всё же нужен багтрекер?

А капиталист вообще может подумать: а давайте посчитаем, что дешевле, инстанция по контролю проектов с кучей инженеров + отделы ОТК при заводах + образоветльные курсы или стопицот таджиков с ведрами цемента и шпателем + развитое похоронное бюро при каждом доме.

И не исключено, что последний вариант таки дешевле.

Вы забыли про иски и репутацию

>Вы забыли про иски и репутацию

Напомнить чем занимался протагонист «бойцовского клуба»? Ну в смысле работа

>на практике этого никто не делает, подумайте почему

без учета всех факторов имеем неполную индукцию и следствия смотри выше

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

>Вы не следите за мыслью, ещё раз, специально для Вас: скрытый дефект, который проявится у 1 балки из 1000, спустя некоторое время после строительства, как может комиссия его предотвратить?

если бы скрытые дефекты встречались бы с такой частотой то дома бы падали, посчитай сколько балок в среднего размера 15-этажке. К тому же должен имется запас прочности за чем комиссия и следит

ну как валенок :) предлагаю Вам больше не влезать в чужие разговоры, ибо Вы их смысла категорически не понимаете

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

>>поясните как «инстанция по допуску проектов к строительству» может предотвратить, к примеру, обваливание крыши по причине скрытого дефекта в опорной балке?

Никак.

значит всё же нужен багтрекер?

С 2 записями в год - не нужен.

Как я уже и сказал - балка - это аппаратные проблемы.

Программа - это блок с входными и выходными данными. И, в отличие от балки, в реальной жизни он точно такой же как и на бумаге.

Да даже та же балка и материаловедение уже исследовано до такой степени, что при правильном контроле брак исключен.

Вы забыли про иски и репутацию

ничего не стоит изменить законодательство. Репутация никого не волнует, если все такие.

>Вы не следите за мыслью, ещё раз, специально для Вас: скрытый дефект, который проявится у 1 балки из 1000, спустя некоторое время после строительства, как может комиссия его предотвратить?

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

> Строят же модель усилителей или бругой радиотехники. Чем принципиаьно программа хуже?

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

Если эта задача не решаема для системы, то значит и системы никакой нет

Подмена понятий. Задача построения системы и задача формального доказательства безошибочной работы системы очень слабо друг с другом связаны.

> На настоящий момент балки можно проверить на гомогенность прямо на заводе, либо доказать, что при соблюдении техпроцесса балки выходят гомогенными.

Потом балки, конечно, будут гнуться и ломаться при комнатной температуре, но нам будет пофигу, потому что мы доказали невозможность этого :)

> Ты бы пошел к врачам которые не несут ответственности за предоставляемое лечение и диагностику?

У нас других врачей-то и нет.

Ну то бишь они, _возможно_, понесут ответственность когда-то там, но я уже буду холодным. А мне вот очень расходится в том, чтобы оставаться теплым, ламповым и живым.

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

Это немного другое. И как врач будет отвечать если пациента не удалось вылечить, и он умер?

Смысл тирады Реймонда был в том, что от багов избавиться в принципе не реально. Это не конвейер для автомобилей, где есть инструкция и при ее соблюдении продукт получается гарантированно таким как его ожидали. Тут же все намного сложней.
Вычитать из зарплаты за каждый баг считаю вообще бредом.
Я считаю так. Плодит работник бажный код, не удовлетворяет его качество, — уволить. А выпуск качественного продукта целиком зависит от руководства, от них зависит компетентность персонала, его заинтересованность, и так далее...

Ну ты поняла )) Можно тебя в джаббер к себе добавить? Не возражаешь?

да пожалуйста, особенно если учесть что у меня больше нет ни icq, ни jabber.. ни чего либо другого

Баги нужно быстро исправлять, а не искать крайнего.

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

ну вот, такая ёмкая тема для инсинуаций закончилась так банально - слив и попытка перевода стрелок... унылый кактус Вы, мужчина

>значит всё же нужен багтрекер?

С 2 записями в год - не нужен.

тогда зачем же в приличных хозяйствах таки заводят его (даже если и в виде бумажной папочки)?

Как я уже и сказал - балка - это аппаратные проблемы.

Программа - это блок с входными и выходными данными. И, в отличие от балки, в реальной жизни он точно такой же как и на бумаге.

ну сейчас, и у аппаратного обеспечения и у программного есть архитектура, и балка - это тоже архитектура

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

допуск всё равно присутствует, не существует однородных балок *SURPRISE*

>> Строят же модель усилителей или бругой радиотехники. Чем принципиаьно программа хуже?

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

Как будто бы программы имеют большое.

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

А может сразу миллиард состояний? А? или триллион?

Этот конечный автомат отлично дробится на блоки блоков.

Подмена понятий. Задача построения системы и задача формального доказательства безошибочной работы системы очень слабо друг с другом связаны.

Если ты построил систему, и не знашь работает она или нет, то такая система гавно, что мы и наблюдаем на протяжении 20-30 лет минимум.

>> На настоящий момент балки можно проверить на гомогенность прямо на заводе, либо доказать, что при соблюдении техпроцесса балки выходят гомогенными.

Потом балки, конечно, будут гнуться и ломаться при комнатной температуре, но нам будет пофигу, потому что мы доказали невозможность этого :)

Очень толсто.

>тогда зачем же в приличных хозяйствах таки заводят его (даже если и в виде бумажной папочки)?

Потому, что 2 записи в год тоже надо как-то в архив сдать.

>>На настоящий момент балки можно проверить на гомогенность прямо на заводе, либо доказать, что при соблюдении техпроцесса балки выходят гомогенными.

допуск всё равно присутствует, не существует однородных балок *SURPRISE*

Допуск учитывается при доказательстве *SURPRISE*.

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

Пусть Реймонд убьется об стенку.

>>Как я уже и сказал - балка - это аппаратные проблемы.

Программа - это блок с входными и выходными данными. И, в отличие от балки, в реальной жизни он точно такой же как и на бумаге.

ну сейчас, и у аппаратного обеспечения и у программного есть архитектура, и балка - это тоже архитектура

Нет. Рассчет проекта производится на бумаге с использованием табличных данных по материалам. Проект «исполняется» на материалах. Проект == программа, материалы == «аппарат».

Если аппарат в действительности отвечает заявленным параметрам, то правильно рассчитанный проект будет исполнятся безошибочно.

>>Смысл тирады Реймонда был в том, что от багов избавиться в принципе не реально.

Пусть Реймонд убьется об стенку.

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

> да пожалуйста, особенно если учесть что у меня больше нет ни icq, ни jabber.. ни чего либо другого

Уважаю жутко :)

> Как будто бы программы имеют большое.

Твои - не знаю. Любая система от миллиона строк кода - считай, необъятное.

Этот конечный автомат отлично дробится на блоки блоков

Может, продемонстрируешь в действии с методологией последующего формального доказательства? А то чесать языком все горазды.

Если ты построил систему, и не знашь работает она или нет, то такая система гавно, что мы и наблюдаем на протяжении 20-30 лет минимум.

Юнит-тесты по всем пунктам требований + тесты на устойчивость + высокое покрытие кода + анализ оставшихся непокрытых строк + проверка в реальных условиях, если этого требует специфика ПО — вполне достаточно для того, чтобы считать систему годной для промышленного применения.

Как его увижу обязательно передам.

>И только не говорите что это неправильно! Если от деятельности больше ущерба чем пользы то за что платить зарплату?

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

Естественно, соотношение (число ошибок) / (число фичей) > 1 много в каких областях говорит о человеке не в его пользу. Тем не менее, в области деятельности, где никто не знает, с какой стороны подъехать и как начать, это нормально. Другое дело, что непосредственно кодинг такой областью деятельности не является. А вот в алгоритмах/логике работы на начальных этапах это, имхо, допустимо.

>> Как будто бы программы имеют большое.

Твои - не знаю. Любая система от миллиона строк кода - считай, необъятное.

откуда такой вывод?

И да - полностью монолитные программы на миллион строк не нужны. Да таких и не бывает.

> Юнит-тесты по всем пунктам требований + тесты на устойчивость + высокое покрытие кода + анализ оставшихся непокрытых строк + проверка в реальных условиях, если этого требует специфика ПО — вполне достаточно для того, чтобы считать систему годной для промышленного применения.

Добавлю к этому: формально доказать корректность работы проекта размером с ядро линакса вообще нереально, а если и реально, то не нужно никому (пока доказательство будет готово, проект устареет).

Можно доказать корректность применяемых фундаментальных алгоритмов (да и нужно, если они еще не), можно доказать соответствие реализаций этим алгоритмам; можно построить набор тестов, обеспечить 100% покрытие кода, после чего доказать, что тесты охватывают комбинации входных данных либо исчерпывающе, либо в достаточных для промышленного использования в рамках практического применения. А вот формально доказывать безошибочность всего огромного комплекса — да ну его нафих.

>> Пусть Реймонд убьется об стенку.

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

Как я уже говрил: выгодно таджиков с ведрами цемента вместо инженеров.

Только в IT почему-то все вверх дном.

>> Этот конечный автомат отлично дробится на блоки блоков

Может, продемонстрируешь в действии с методологией последующего формального доказательства? А то чесать языком все горазды.

берем любую CAS. В ней есть блоки отвечающие за решение определенных проблем. У блоков есть интерфейс (переменные на входе и переменные на выходе).

Или может мне еще тут дипломную работу по доказательству какой-то системы написать, ради срача годного?

> >Твои - не знаю. Любая система от миллиона строк кода - считай, необъятное.

откуда такой вывод?

Из комбинаторики прямиком.

И да - полностью монолитные программы на миллион строк не нужны. Да таких и не бывает.

MPlayer. Firefox.

Вообще, приходилось ли тебе, о чудный пришелец из Страны Безбажных Проектов, слышать об интеграционных тестах? А вот оказывается, есть такой зверь. И оказывается, очень нужный и ценный зверь. Потому что даже оттестированные отдельно модули, со 100% покрытием тестами, могут взять и не запахать вместе.

>> Этот конечный автомат отлично дробится на блоки блоков

Может, продемонстрируешь в действии с методологией последующего формального доказательства? А то чесать языком все горазды.

да и кто сказал, что это легко?

> >Ты, конечно, пишешь сложные информационно-расчетные системы без единого бага и заработал на третью виллу и пятый роллс-ройс в счет экономии на QA?

Как я уже говрил: выгодно таджиков с ведрами цемента вместо инженеров.

Я тебя спрошу опять: есть у тебя проект, который ты можешь показать и который не содержит ни одного бага? Сколько ты мне заплатишь, если я в нем хотя бы один баг найду?

За словишки-то надо отвечать. Теория теорией, а прикладная практика — это прикладная практика, где частенько все на удивление не так.

>> И да - полностью монолитные программы на миллион строк не нужны. Да таких и не бывает.

MPlayer. Firefox.

и в каком месте mplayer или firefox монолитный? потому что статически собран, лол?

Нет, он конечно и не идеально модульный, но и не полностью монолитный.

Монолитная программа в данном конексте - эта которая имеет один большой массив глобальных переменных, без функций и т.п.

Вообще, приходилось ли тебе, о чудный пришелец из Страны Безбажных Проектов, слышать об интеграционных тестах? А вот оказывается, есть такой зверь. И оказывается, очень нужный и ценный зверь. Потому что даже оттестированные отдельно модули, со 100% покрытием тестами, могут взять и не запахать вместе.

Вот потому, что не проводят формального доказательства функционирования системы на основе данных блоков, так и случается. Очередной костыль/таджик с цементом.

ЧТД.

>> Как я уже говрил: выгодно таджиков с ведрами цемента вместо инженеров.

Я тебя спрошу опять: есть у тебя проект, который ты можешь показать и который не содержит ни одного бага? Сколько ты мне заплатишь, если я в нем хотя бы один баг найду?

Возьми тотже axiom. Разработка ведется с помощью Literal Programming с формальным доказательством.

Баги там только на стыке с интерфейсом с ОС. Объясняется тем, что современная система так уж разрабатывается, как уже сказано.

За словишки-то надо отвечать. Теория теорией, а прикладная практика — это прикладная практика, где частенько все на удивление не так.

Естественно. Ибо никто не хочет платить лишние деньги, если и так сойдет. Про что и речь, собсно.

>Добавлю к этому: формально доказать корректность работы проекта размером с ядро линакса вообще нереально, а если и реально, то не нужно никому (пока доказательство будет готово, проект устареет).

Вот потому формально Линукс, да весь Software World - гавно.

>Программа - это блок с входными и выходными данными. И, в отличие от балки, в реальной жизни он точно такой же как и на бумаге.

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

В отличие от балки, у которой окружением является просто не так хорошо предсказуемая природа, у софта окружение по определению работает с ошибками. Чтобы эти ошибки не мешали работе софта, добавляются костыли по имени workaround. Алгоритмы усложняются кучей workaround'ов, в итоге даже самая тривиальная проверенная на бумаге логика может работать уже совсем не так, как на бумаге.

И это исключая огрехи самих разработчиков и тех, кто ставил задачу.

> Вот потому формально Линукс, да весь Software World - гавно.

Но ведь работает же. Иногда. И этого вполне хватает.

Лучшее — враг хорошего. Думаешь, от хорошей жизни придумали?