> Процесс отладки -- это неформализованный метод. Кустарный. Если бы он был действительно
> методом, была бы методика применения отладчика, которая гарантирует, что следование ей
> избавляет программу от багов.Если процесс отладки это "неформализованный метод", то и процесс непосредственного исполнения есть "неформализованный метод". Значить все программы кустарные? Баги в мозгу у программиста, машина исполняет ровно то, что требует от нее программист. Программист допустит в голове багу, значить программа будет бажной.
> В смысле вот я прошёлся по этой
> методике, получил программу, и теперь готов продавать программу внося в EULA
> пункт о моей материальной ответственности за каждый найденный баг в моей
> программе.
Корректны алгоритм будет корректно исполняться. И процесс отладки это верифицирует. Процесс отладки вам покажет почему инструкция сложения 2+2 вдруг в место ожидаемого результата 4, поместило в память результат 5. Или почему при записи 1 в бит памяти, вдруг там оказался 0. Понимаете к чему я веду, когда баги даже на уровне вычислительного аппарата.
> Это не ответ на мой вопрос. Если ты начинаешь сравнивать значения указателей
> из разных мест, то с большой вероятностью тебе придётся забить на
> инкапсуляцию.
Ну конечно не ответ, так как я не рассуждаю в ваших категориях. Если у меня нет в голове указателей или всякой инкапсуляции. А есть просто ячейка памяти.
> Вообще-то есть. Если ты возьмёшь любой плюс-минус серьёзный проект, и попытаешься туда
> заслать PR, то выяснится, что у них есть требования к оформлению
> кода, что у них есть запреты на использование каких-то синтаксических конструкций,
> есть принципы документирования кода, именования переменных, бла-бла-бла... Другое дело,
> что эти стандарты не распространяются на всю отрасль, а очень локальны.
это не стандарты, это правила, такие же правила как "взял память" - "освободи", "освободил память" - "не смей повторно освобождать" и т. д.
> Это было бы легче, но это не работает. GC ведь тоже не
> решает проблем. При этом он создаёт дополнительные проблемы, которые при этом
> местами не только привносят неудобств, они вообще недопустимы. В real-time приложениях
> рандомные задержки от GC сильно портят всё, потому что в real-time
> приложениях время отклика должно быть меньше заданной в ТЗ величины, и
> выполнение этого пункта ТЗ, должно быть доказано, а не просто заявлено
> программистом, что он сделал всё ок.
Ну вот ожидаемый ответ, а что есть собственно то же GC, разве не перекладывание ответственности с себя на другого (разработчика языка)? если программа на расте будет течь это разве будет проблема программиста? нет конечно, ибо программист на расте "избавлен" от этой проблемы заверением растовых разработчиков. И вина с ответственностью на них. А кого будет винить заказчик с убытками? Разработчиков раста?
> Нет. То что ты излагаешь здесь -- это мудрость принятая на опеннете,
> но любая мудрость -- это от тупости. Можно поверх на недетерминированной
> системы выстроить детерминированную. Мне в качестве примера нравится термодинамика: законы
> термодинамики выводятся из модели выстроенной на микропараметрах, которые описываются
> распределениями вероятностей, и таким образом модель стохастическая. Но из стохастической
> модели выводится детерминированная модель с макропараметрами, и уже на этой теоретической
> модели строится вполне детерминированный паровоз.
Хаос тоже детерминирован, и Бог детерминирован (закономерен)! Придумал новую мудрость.
> Если ты сто раз повторишь это утверждение, оно перестанет быть ложным и
> станет истинным.
Это мое мнение. Моя цель не переубедить вас, а донести свою мысль.
> Когда ты отлаживаешь, ты рассматриваешь все теоретические возможные состояния процесса?
> Нет же, ты рассматриваешь очень небольшое количество этих состояний. На основании
> своих наблюдений ты пытаешься рассуждениями доказать, что во всех нерассмотренных состояниях
> будет не хуже. Но -- хыхы -- тут ты упираешься опять
> в свою способность доказывать утверждения о коде. И по-хорошему, отладка --
> это костыль на те случаи, когда твоей способности недостаточно, чтобы решить
> проблему без отладки.
Кхмммм, когда я отлаживаю, я верифицирую задумку алгоритма в голове, если в голове бага, то и в отладке она проявится. А по всевозможные состояния дам ссылочки:
https://ru.wikipedia.org/wiki/%D0%9E%D0%...
https://ru.wikipedia.org/wiki/%D0%9E%D0%...
> Да, я о том и говорю. Я примерно так и делаю. По
> инерции после C я использовал отладчик в расте поначалу, а потом
> забил. Он нафиг не нужен.
И где гарантии безбажности? А ну да я забыл, их разработчики раста дают.
> Где можно почитать про эти правила, которым нужно следовать?
:) вспомнился фильм Бойцовский клуб.
Правило 1: Взял - отдай
Правило 2: Не смей отдавать дважды
Правило 3: .... и т.д. знатоки могут подсказать.
> А вот бизнесмен просто потеряет деньги, выплаченные програмисту. Бизнесмену нужны гарантии.
И как я понял программистам тоже нужны гарантии, а кто их даст? Такие же программисты?
> Ты когда-нибудь нёс материальную ответственность за баги в своём коде, которые просочились
> в продакшн?
Ответственность говорите? Разве не ответственность сидеть часами в отладчике и верифицировать написанный код на корректность, который будет использоваться в критически важных системах? Легче же выбрать раст и переложить ответственность на разработчиков раста, так ведь? Хорошо когда на все готовое, а если нужно это уметь хорошо готовить, то это сразу становиться проблемой? Бизнесс говорите, когда от двух строчек кода зависит жизнь человека.
