Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Если код формально верифицирован — ассерты можно тупо удалить. Формальная верификация — сильная, но дорогая техника доказательства корректности кода, которая полностью заменяет ЮТ и ассерты.
EP>Да, после верификации ассерты можно хоть удалить. Я этот пример привёл именно в качестве иллюстрации на тему опциональности assert'ов
А так же на тему ненужности assert'ов

EP>·>Если ты вдруг полагаешь, что где-то может быть ошибочное состояние (т.е. хочешь написать там ассерт), то
EP>·>либо воспроизведи это состояние тестом, т.е. ассерт не нужен;
EP>Протестировать внутреннее состояние далеко не всегда легко из вне. Assert же даёт самое ранее обнаружение, при этом крайне дешёв чтобы от него отказываться.
EP>Думаешь все твои тесты делают ненужными написанные ассерты? ОК — в чём проблема их оставить? Когда-нибудь ты, или кто-то другой ошибётся и assert таки выстрелит.
Проблема в том, что их не надо писать. Ассерт это такой индикатор лажи, когда программист поленился либо написать тест, либо продумать корректное поведение в ошибочной ситуации.

EP>·>либо почеши голову и убедись, что это состояние невозможно, т.е. ассерт не нужен.
EP>assert помимо всего прочего может ловить нарушения preconditions, а конкретнее выстреливать во время интеграции компонентов. Ты не можешь "почесать голову" и убедится в том, что все компоненты (которых ты ещё даже не видел) обязательно будут удовлетворят предусловиям.
EP>Более того, если например ты используешь чужой алгоритм с ассертами на предусловия — то ты фактически получаешь эти все проверки бесплатно.
Для этого есть более хорошие средства — явно кидаться ошибками, писать логи, или просто продолжить корректно работать.

EP>>>·>Оттестирован на требуемых спекой сценариях.
EP>>>У тебя в "cпеке" описаны все сценарии, для всех компонент на всех уровнях?
EP>·>Зачем на всех уровнях? Ошибка на уровне юнитов будет падать сразу с каким-нибудь bounds checking и видна немедленно и везде.
EP> bounds checking это лишь мизерная часть проверки ошибочных состояний, ассерты используются далеко не только для bounds checking.
Для чего ещё? Ну там null-checks, валидность параметров и т.п. Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.

EP>>>·>Гы-гы. Ведь явно не от хорошей жизни, им тупо пришлось использовать ассерты не по назначению.
EP>>>Без понятия — но проблемы в этом нет. Если нужен over-defenesive, то оставляй assert'ы и в release
EP>·>Это не имеет смысла, используют инструмент не по назначению. Это уже тогда не ассерты, а обычные проверки.
EP>Ассерты в первую очередь нацелены на поимку багов — нарушение инвариантов, вариантов, пред/пост-условий.
EP>У них семантика другая нежели чем у обычных проверок. Обычные проверки нельзя выкинуть даже из формально верифицированного кода.
Неотключённые ассерты в релизе по сути и есть эти сами обычные проверки. Т.е. были ассерты, а семантику поменяли.

EP>·>"Опциональный жесткий фейл". Это не звучит для тебя как оксюморон?
EP>Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
EP>При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы.
Если неразрешимы — они значит не нужны. Если разрешимы — то они должны фейлить и релиз.

EP>Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?
Нет. А у тебя ассерты есть вокруг каждого выражения?

EP>Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.
И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?

Здравствуйте, ·, Вы писали:

EP>>Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.
·>И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?

"Меньше" в чем померяно? На практике интеграционные тестируют "больше" если мерить так — количество сценариев * частоту использования сценария / количество добавленных строк.

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

Здравствуйте, gandjustas, Вы писали:

G>·>И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?
G>"Меньше" в чем померяно? На практике интеграционные тестируют "больше" если мерить так — количество сценариев * частоту использования сценария / количество добавленных строк.
Это в хорошей практике. А если брать среднее по больнице... с учётом того, что большинство тесты вообще не пишет...

Кстати, вопрос. Если все тесты проходят, но ассерт падает — значит ли это что ассерт валидный?

G>Юнит-тесты, несмотря на большое покрытие, обычно бесполезны для отлавливания ошибок на границах модулей. Кроме того большое количество UT затрудняет рефакторинг классов — много тестов ломаются, приходится править.
В сравнении с ассертами как оно? Ассерты тоже начинают ломаться внезапно.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, gandjustas, Вы писали:

G>>·>И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?
G>>"Меньше" в чем померяно? На практике интеграционные тестируют "больше" если мерить так — количество сценариев * частоту использования сценария / количество добавленных строк.
·>Это в хорошей практике. А если брать среднее по больнице... с учётом того, что большинство тесты вообще не пишет...
Ну и пусть не пишут, может проще проверять код другими способами. Эффективность это польза/затраты, затраты на тесты довольно высоки, по сравнению с другими способами.


·>Кстати, вопрос. Если все тесты проходят, но ассерт падает — значит ли это что ассерт валидный?
Каким образом проходят тесты при падающем ассерте? Ассерт падает только в продакшене?

G>>Юнит-тесты, несмотря на большое покрытие, обычно бесполезны для отлавливания ошибок на границах модулей. Кроме того большое количество UT затрудняет рефакторинг классов — много тестов ломаются, приходится править.
·>В сравнении с ассертами как оно? Ассерты тоже начинают ломаться внезапно.
С ассертами гораздо проще — они часть кода, который рефактортся.
Ну и правильные ассерты должны инварианты алгоритмов проверять, а инварианты при рефакторинге не меняются.

Здравствуйте, gandjustas, Вы писали:

G>>>"Меньше" в чем померяно? На практике интеграционные тестируют "больше" если мерить так — количество сценариев * частоту использования сценария / количество добавленных строк.
G>·>Это в хорошей практике. А если брать среднее по больнице... с учётом того, что большинство тесты вообще не пишет...
G>Ну и пусть не пишут, может проще проверять код другими способами. Эффективность это польза/затраты, затраты на тесты довольно высоки, по сравнению с другими способами.
Вручную, как же ещё.

G>·>Кстати, вопрос. Если все тесты проходят, но ассерт падает — значит ли это что ассерт валидный?
G>Каким образом проходят тесты при падающем ассерте? Ассерт падает только в продакшене?
Допустим, что ассерты отключены (не валят процесс), но условие не соблюдается.

G>>>Юнит-тесты, несмотря на большое покрытие, обычно бесполезны для отлавливания ошибок на границах модулей. Кроме того большое количество UT затрудняет рефакторинг классов — много тестов ломаются, приходится править.
G>·>В сравнении с ассертами как оно? Ассерты тоже начинают ломаться внезапно.
G>С ассертами гораздо проще — они часть кода, который рефактортся.
G>Ну и правильные ассерты должны инварианты алгоритмов проверять, а инварианты при рефакторинге не меняются.
Правильные тесты — тоже.

Здравствуйте, ·, Вы писали:

EP>>·>Если код формально верифицирован — ассерты можно тупо удалить. Формальная верификация — сильная, но дорогая техника доказательства корректности кода, которая полностью заменяет ЮТ и ассерты.
EP>>Да, после верификации ассерты можно хоть удалить. Я этот пример привёл именно в качестве иллюстрации на тему опциональности assert'ов
·>А так же на тему ненужности assert'ов

Это ты уже не знаешь к чему придраться. Иллюстрация была на тему опциональности, а не ненужности.
Если следовать твоим же рассуждениям о ненужности — то и bound checks не нужны, как и прочий defensive, ибо можно использовать формальную верификацию

EP>>Протестировать внутреннее состояние далеко не всегда легко из вне. Assert же даёт самое ранее обнаружение, при этом крайне дешёв чтобы от него отказываться.
EP>>Думаешь все твои тесты делают ненужными написанные ассерты? ОК — в чём проблема их оставить? Когда-нибудь ты, или кто-то другой ошибётся и assert таки выстрелит.
·>Проблема в том, что их не надо писать. Ассерт это такой индикатор лажи, когда программист поленился либо написать тест,

Это твои фантазии — я например использую ассерты одновременно с тестами.

·>либо продумать корректное поведение в ошибочной ситуации.

Предлагаешь продумывать поведение для каждого возможного поломанного инварианта?

·>или просто продолжить корректно работать.

Не получится — у тебя код пришёл в состояние в которое не должен был прийти по логике вещей — каким образом он в него пришёл ты не знаешь, глобальное состояние тоже не известно, а точнее может содержать неизвестно какие ошибки.

EP>>>>·>Оттестирован на требуемых спекой сценариях.
EP>>>>У тебя в "cпеке" описаны все сценарии, для всех компонент на всех уровнях?
EP>>·>Зачем на всех уровнях? Ошибка на уровне юнитов будет падать сразу с каким-нибудь bounds checking и видна немедленно и везде.
EP>> bounds checking это лишь мизерная часть проверки ошибочных состояний, ассерты используются далеко не только для bounds checking.
·>Для чего ещё?

Например инварианты класса. Классы (с private полями) это не просто группировка полей а-ля структуры (либо эмуляция структур через getters&setters) — это ещё и дополнительные инварианты наложенные на эти private поля.

·>Ну там null-checks

На C++ null-checks прячутся во внутрь небольшого набора классов, и раскидывать их по коду нет никакой необходимости.

·>валидность параметров

Для этого в том числе.

·>Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.

Ассерты используются вместе с тестами, а не вместо них.

EP>>У них семантика другая нежели чем у обычных проверок. Обычные проверки нельзя выкинуть даже из формально верифицированного кода.
·>Неотключённые ассерты в релизе по сути и есть эти сами обычные проверки. Т.е. были ассерты, а семантику поменяли.

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

EP>>·>"Опциональный жесткий фейл". Это не звучит для тебя как оксюморон?
EP>>Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
EP>>При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы.
·>Если неразрешимы — они значит не нужны.
·>Если разрешимы — то они должны фейлить и релиз.

Нет, неразрешимы означает что неразрешимы. Нужность/ненужность тут ортогонально — смотри например halting probelm

EP>>Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?
·>Нет. А у тебя ассерты есть вокруг каждого выражения?

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

EP>>Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.
·>И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?

Что значит важнее релиза? Я интеграционным тестированием называю в том числе и тестирование всего вместе.
В любом случае, даже если использовать другую терминологию и выделять ещё и системное тестирование — то мой поинт всё равно остаётся в силе — assert'ы отрабатывают на всех этапах тестирования.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>А так же на тему ненужности assert'ов
EP>Это ты уже не знаешь к чему придраться. Иллюстрация была на тему опциональности, а не ненужности.
EP>Если следовать твоим же рассуждениям о ненужности — то и bound checks не нужны, как и прочий defensive, ибо можно использовать формальную верификацию
Я просто не понял зачем ты это доказываешь. Тем более таким образом. Опциональность ассертов, точнее их отключение в release — это by design.

EP>>>Думаешь все твои тесты делают ненужными написанные ассерты? ОК — в чём проблема их оставить? Когда-нибудь ты, или кто-то другой ошибётся и assert таки выстрелит.
EP>·>Проблема в том, что их не надо писать. Ассерт это такой индикатор лажи, когда программист поленился либо написать тест,
EP>Это твои фантазии — я например использую ассерты одновременно с тестами.
Вредная привычка...

EP>·>либо продумать корректное поведение в ошибочной ситуации.
EP>Предлагаешь продумывать поведение для каждого возможного поломанного инварианта?
Да. Или лучше — не допускать ломание инвариантов.
А что по-твоему оно будет делать в релизе?

EP>·>или просто продолжить корректно работать.
EP>Не получится — у тебя код пришёл в состояние в которое не должен был прийти по логике вещей — каким образом он в него пришёл ты не знаешь, глобальное состояние тоже не известно, а точнее может содержать неизвестно какие ошибки.
Значит кинь исключение, сбрось дамп состояния в лог, етс.

EP>>>·>Зачем на всех уровнях? Ошибка на уровне юнитов будет падать сразу с каким-нибудь bounds checking и видна немедленно и везде.
EP>>> bounds checking это лишь мизерная часть проверки ошибочных состояний, ассерты используются далеко не только для bounds checking.
EP>·>Для чего ещё?
EP>Например инварианты класса. Классы (с private полями) это не просто группировка полей а-ля структуры (либо эмуляция структур через getters&setters) — это ещё и дополнительные инварианты наложенные на эти private поля.
Т.е. косяки дизайна в алгоритме затыкаются ассертами.

EP>·>Ну там null-checks
EP>На C++ null-checks прячутся во внутрь небольшого набора классов, и раскидывать их по коду нет никакой необходимости.
EP>·>валидность параметров
EP>Для этого в том числе.
Так что остаётся-то? Примеры можно? Так что тестами ну никак не покрывается?

EP>·>Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.
EP>Ассерты используются вместе с тестами, а не вместо них.
Я не говорю, что их невозможно использовать. Я говорю, что их не следует использовать, лучше заменять на что-то более надёжное: лучший дизайн алгоритмов, не допускающий всякую НЁХ, более качественное покрытие тестами и более качественную диагностику.

EP>>>У них семантика другая нежели чем у обычных проверок. Обычные проверки нельзя выкинуть даже из формально верифицированного кода.
EP>·>Неотключённые ассерты в релизе по сути и есть эти сами обычные проверки. Т.е. были ассерты, а семантику поменяли.
EP>Нет, так как после формальной верификации (либо например через несколько релизов без выстреливания assert'ов) их можно отключить, в то время как проверки не являются опциональными.
Ээээээ.. Ты что под формальной верификацией понимаешь?

EP>>>Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
EP>>>При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы.
EP>·>Если неразрешимы — они значит не нужны.
EP>·>Если разрешимы — то они должны фейлить и релиз.
EP>Нет, неразрешимы означает что неразрешимы. Нужность/ненужность тут ортогонально — смотри например halting probelm
halting problem это построение универсального алгоритма. Причём тут это? Программист обычно может чуть больше. По крайней мере в случае, когда хочет написать ассерт.

EP>>>Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?
EP>·>Нет. А у тебя ассерты есть вокруг каждого выражения?
EP>Нет, при этом это всё жёсткие фейлы.
EP>Жёсткие в том смысле что говорят о серьёзном баге, а не о том что кто-то умрёт.
Т.е. ты считаешь, что наличие серьёзного бага должно игнорироваться в проде?

EP>>>Перечитай ещё раз то, на что ответил — например про то что ассерты работают и при интеграционных тестах.
EP>·>И что? Интеграционные тесты как правило тестируют сильно меньше, чем юнит. И ещё меньше, чем возможно в релизе. Почему вдруг интеграционные тесты стали важнее релиза?
EP>Что значит важнее релиза? Я интеграционным тестированием называю в том числе и тестирование всего вместе.
EP>В любом случае, даже если использовать другую терминологию и выделять ещё и системное тестирование — то мой поинт всё равно остаётся в силе — assert'ы отрабатывают на всех этапах тестирования.
Но почему не в релизе-то?

Здравствуйте, ·, Вы писали:

·>Я просто не понял зачем ты это доказываешь. Тем более таким образом. Опциональность ассертов, точнее их отключение в release — это by design.

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

EP>>·>Проблема в том, что их не надо писать. Ассерт это такой индикатор лажи, когда программист поленился либо написать тест,
EP>>Это твои фантазии — я например использую ассерты одновременно с тестами.
·>Вредная привычка...

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

EP>>·>либо продумать корректное поведение в ошибочной ситуации.
EP>>Предлагаешь продумывать поведение для каждого возможного поломанного инварианта?
·>Да. Или лучше — не допускать ломание инвариантов.

Ага, за всё хорошее и против всего плохого.
Если у тебя инварианты и т.п. не ломаются, то непонятно зачем ты восхваляешь всякие defensive штуки типа range check?

·>А что по-твоему оно будет делать в релизе?

Кто оно? Баги?

EP>>·>или просто продолжить корректно работать.
EP>>Не получится — у тебя код пришёл в состояние в которое не должен был прийти по логике вещей — каким образом он в него пришёл ты не знаешь, глобальное состояние тоже не известно, а точнее может содержать неизвестно какие ошибки.
·>Значит кинь исключение, сбрось дамп состояния в лог, етс.

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

EP>>·>Для чего ещё?
EP>>Например инварианты класса. Классы (с private полями) это не просто группировка полей а-ля структуры (либо эмуляция структур через getters&setters) — это ещё и дополнительные инварианты наложенные на эти private поля.
·>Т.е. косяки дизайна в алгоритме затыкаются ассертами.

Шта? Как ты пришёл к этому выводу? Я говорю про инварианты классов, и они таки существуют.

EP>>·>Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.
EP>>Ассерты используются вместе с тестами, а не вместо них.
·>Я не говорю, что их невозможно использовать. Я говорю, что их не следует использовать, лучше заменять на что-то более надёжное: лучший дизайн алгоритмов, не допускающий всякую НЁХ, более качественное покрытие тестами и более качественную диагностику.

Ты так и не объяснил почему их не следует использовать, учитывая их минимальную цену. Пока всё сводится к "я их не использую, значит их не следует использовать".
И непонятно причём тут "лучший дизайн алгоритмов" — речи о том чтобы делать плохие алгоритмы не было. При этом "лучший дизайн алгоритмов" не избавляет от необходимости их тестирования, одним из аспектов которого являются в том числе assert'ы.

EP>>>>У них семантика другая нежели чем у обычных проверок. Обычные проверки нельзя выкинуть даже из формально верифицированного кода.
EP>>·>Неотключённые ассерты в релизе по сути и есть эти сами обычные проверки. Т.е. были ассерты, а семантику поменяли.
EP>>Нет, так как после формальной верификации (либо например через несколько релизов без выстреливания assert'ов) их можно отключить, в то время как проверки не являются опциональными.
·>Ээээээ.. Ты что под формальной верификацией понимаешь?

Доказывание свойств алгоритмов на формальном языке с автоматической проверкой правильности применения правил вывода и т.п.

EP>>>>Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
EP>>>>При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы.
EP>>·>Если неразрешимы — они значит не нужны.
EP>>·>Если разрешимы — то они должны фейлить и релиз.
EP>>Нет, неразрешимы означает что неразрешимы. Нужность/ненужность тут ортогонально — смотри например halting probelm
·>halting problem это построение универсального алгоритма. Причём тут это? Программист обычно может чуть больше. По крайней мере в случае, когда хочет написать ассерт.

Смотри выделенное — проверка далеко не каждого пред/пост-условия является разрешимой задачей.

EP>>>>Вот у тебя есть проверки пред/пост-условия вокруг каждого выражения?
EP>>·>Нет. А у тебя ассерты есть вокруг каждого выражения?
EP>>Нет, при этом это всё жёсткие фейлы.
EP>>Жёсткие в том смысле что говорят о серьёзном баге, а не о том что кто-то умрёт.
·>Т.е. ты считаешь, что наличие серьёзного бага должно игнорироваться в проде?

Это очевидно зависит от цены не игнорирования, от цены бага и т.п. Это компромисс — где-то уместный, а где-то нет.

EP>>В любом случае, даже если использовать другую терминологию и выделять ещё и системное тестирование — то мой поинт всё равно остаётся в силе — assert'ы отрабатывают на всех этапах тестирования.
·>Но почему не в релизе-то?

Я уже ранее говорил что в основном из-за производительности.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>·>Я просто не понял зачем ты это доказываешь. Тем более таким образом. Опциональность ассертов, точнее их отключение в release — это by design.
EP>Показываю опциональность, для того чтобы было видно семантическое отличие от обычных проверок. Таким образом — потому что самая красноречивая демонстрация того, что для корректного кода они не нужны.
Это не опциональность. Во-первых, верификация делает ненужным не только ассерты, но и многие виды тестов. Во-вторых, как часто попадаются проекты с верифицированным кодом? Один на миллион? Мне не попадались...

EP>>>·>Проблема в том, что их не надо писать. Ассерт это такой индикатор лажи, когда программист поленился либо написать тест,
EP>>>Это твои фантазии — я например использую ассерты одновременно с тестами.
EP>·>Вредная привычка...
EP>Почему? Потому что ты не используешь?
Да. Когда писал на Плюсах — использовал. Но тогда у меня опыта не было, да и практика юнит-тестирования была экзотикой. Потом перешел на Яву, там ассертов изначально не было, приходилось обходиться, а потом они появились (java5 афаир), но осмысленных применений им уже не нашлось.

EP>Даже если ты не веришь в то что они помогают в отлове багов, то всё равно остаётся аспект документирования пред/пост-условий и т.п. Причём это не просто текстовый комментарий, а реально выполняемая проверка, пусть даже только при тестировании.
Угу, что прекрасно делается юнит-тестами.

EP>При этом втыкаются непосредственно во время кодирования, не переключая контекст. И являются крайне дешёвыми.
TDD же.

EP>>>Предлагаешь продумывать поведение для каждого возможного поломанного инварианта?
EP>·>Да. Или лучше — не допускать ломание инвариантов.
EP>Ага, за всё хорошее и против всего плохого.
EP>Если у тебя инварианты и т.п. не ломаются, то непонятно зачем ты восхваляешь всякие defensive штуки типа range check?
Ломаются. Но я знаю, что в этом случае получу чёткий стек-трейс, а не UB.

EP>·>А что по-твоему оно будет делать в релизе?
EP>Кто оно? Баги?
Да. И баги тоже. Fail-fast, слышал?

EP>>>Не получится — у тебя код пришёл в состояние в которое не должен был прийти по логике вещей — каким образом он в него пришёл ты не знаешь, глобальное состояние тоже не известно, а точнее может содержать неизвестно какие ошибки.
EP>·>Значит кинь исключение, сбрось дамп состояния в лог, етс.
EP>Это же не "продолжить корректно работать" — ты не локализовал и не устранил причину, а лишь пытаешься собрать данные для последующего разбирательства и хоть как-то восстановиться.
Правильно. А как надо? Продолжить работать будто ничего не случилось?

EP>>>·>Для чего ещё?
EP>>>Например инварианты класса. Классы (с private полями) это не просто группировка полей а-ля структуры (либо эмуляция структур через getters&setters) — это ещё и дополнительные инварианты наложенные на эти private поля.
EP>·>Т.е. косяки дизайна в алгоритме затыкаются ассертами.
EP>Шта? Как ты пришёл к этому выводу? Я говорю про инварианты классов, и они таки существуют.
Т.е. инварианты "сами нарушились"?

EP>>>·>Может какая-то доля процента и будет чем-то интересным, но её лучше тогда явно протестировать.
EP>>>Ассерты используются вместе с тестами, а не вместо них.
EP>·>Я не говорю, что их невозможно использовать. Я говорю, что их не следует использовать, лучше заменять на что-то более надёжное: лучший дизайн алгоритмов, не допускающий всякую НЁХ, более качественное покрытие тестами и более качественную диагностику.
EP>Ты так и не объяснил почему их не следует использовать, учитывая их минимальную цену. Пока всё сводится к "я их не использую, значит их не следует использовать".
Ок. Насчёт цены согласен, об этом я уже писал. Если с тестами плохо, то использовать ЮТ получится дороже ассертов, получается компромисс — уж лучше что-то, чем ничего. В хорошо организованном проекте тесты дёшевы и ассерты становятся бессмысленны.

EP>И непонятно причём тут "лучший дизайн алгоритмов" — речи о том чтобы делать плохие алгоритмы не было. При этом "лучший дизайн алгоритмов" не избавляет от необходимости их тестирования, одним из аспектов которого являются в том числе assert'ы.
Ассерты это тестирование для убогих.

EP>>>Нет, так как после формальной верификации (либо например через несколько релизов без выстреливания assert'ов) их можно отключить, в то время как проверки не являются опциональными.
EP>·>Ээээээ.. Ты что под формальной верификацией понимаешь?
EP>Доказывание свойств алгоритмов на формальном языке с автоматической проверкой правильности применения правил вывода и т.п.
Ну... и зачем при наличии верификации вообще нужны ассерты? Откуда они возьмутся? Какой смысл их писать в верифицируемом коде?

EP>>>Нет, неразрешимы означает что неразрешимы. Нужность/ненужность тут ортогонально — смотри например halting probelm
EP>·>halting problem это построение универсального алгоритма. Причём тут это? Программист обычно может чуть больше. По крайней мере в случае, когда хочет написать ассерт.
EP>Смотри выделенное — проверка далеко не каждого пред/пост-условия является разрешимой задачей.
Не понял. И как ты проверишь с помощью ассерта неразрешимое предусловие? И чем это будет отличаться от ЮТ?

EP>>>Нет, при этом это всё жёсткие фейлы.
EP>>>Жёсткие в том смысле что говорят о серьёзном баге, а не о том что кто-то умрёт.
EP>·>Т.е. ты считаешь, что наличие серьёзного бага должно игнорироваться в проде?
EP>Это очевидно зависит от цены не игнорирования, от цены бага и т.п. Это компромисс — где-то уместный, а где-то нет.
Что именно это значит? Опять у тебя какой-то оксюморон, "серьёзный дешевый баг". Прям как "солидная фирма возьмёт в аренду дырокол".
Ок. Допустим у тебя есть ассерт какой-то. И ты считаешь, что цена велика. А в соседней строчке ещё один ассерт и цена мала. Ты включишь или выключишь ассерты в релизе?
Или ты ставишь ассерты только на дешевые баги? И зачем же тогда этими ассертами заморачиваться, время тратить на дешевую мелочёвку?

EP>>>В любом случае, даже если использовать другую терминологию и выделять ещё и системное тестирование — то мой поинт всё равно остаётся в силе — assert'ы отрабатывают на всех этапах тестирования.
EP>·>Но почему не в релизе-то?
EP>Я уже ранее говорил что в основном из-за производительности.
Ок, допишу ещё причину.
4. Плохо дело с языком, убогий компилятор, для преждевременной оптимизации. Приходится явно подсказывать компилятору какие проверки необязательны.

Здравствуйте, a_g_99, Вы писали:

__>Зарплата Senior Staff Engineer (Java/JavaScript) в Google ~ 250k в год
__>Зарплата Senior Engineer (Java/JavaScript) в Netflix ~ 350k в год

__>Зарплата Senior .Net Engineer в Microsoft ~ 80k в год

А если бы в Netflix на стеке MS жили, то было бы уже не 350k в год?

Здравствуйте, Farsight, Вы писали:

F>А если бы в Netflix на стеке MS жили, то было бы уже не 350k в год?
Было бы 80 или 100. В стеке MS главное что? Tools. Visual Studio, Sharepoint, все это. И кто будет платить за знание VS 350 велоинструктору?

Здравствуйте, a_g_99, Вы писали:

__>Было бы 80 или 100. В стеке MS главное что? Tools. Visual Studio, Sharepoint, все это. И кто будет платить за знание VS 350 велоинструктору?

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

Здравствуйте, Farsight, Вы писали:

F>Заболтать хотите? Я думал, что платят за решение задач. Это я, как бывший велоинструктор, говорю .

Чтобы решать сложные задачи нужна соотвествующая платформа. Невозможно решать задачи нетфликс на .net or php или дельфи. Это вам не педали крутить велоинструктор. Это другой уровень

Здравствуйте, a_g_99, Вы писали:

__>Чтобы решать сложные задачи нужна соотвествующая платформа. Невозможно решать задачи нетфликс на .net or php или дельфи.

Простите, но это болтология. Очередной треп на тему "Java vs .Net vs _ВАШ_ВАРИАНТ_". Я, пожалуй, пропущу .

__>Это вам не педали крутить велоинструктор. Это другой уровень

"Это вам не по кнопкам долбить и в экран пялится, это другой уровень" © Велоинструктор

Здравствуйте, Farsight, Вы писали:

__>>Чтобы решать сложные задачи нужна соотвествующая платформа. Невозможно решать задачи нетфликс на .net or php или дельфи.
F>Простите, но это болтология. Очередной треп на тему "Java vs .Net vs _ВАШ_ВАРИАНТ_". Я, пожалуй, пропущу .
Да что тут пропускать, кроме фактов. Покажи мне хоть одну low latency систему на .Net. Или клиент-серверную СУБД. Или Search Engine. Или framework/vm для mobile devices. Или тупо web server. Или clustering engine типа Spark/Hadoop/etc. Или MQ.
Вот и думай кому ещё нужет этот ваш .net/php/дельфи кроме как велоинструкторам.

Здравствуйте, ·, Вы писали:

·>Да что тут пропускать, кроме фактов. Покажи мне хоть одну low latency систему на .Net. Или клиент-серверную СУБД. Или Search Engine. Или framework/vm для mobile devices. Или тупо web server. Или clustering engine типа Spark/Hadoop/etc. Или MQ.
·>Вот и думай кому ещё нужет этот ваш .net/php/дельфи кроме как велоинструкторам.

Запахло Apache'м .

Так уж сложилось, что .net догоняющая платформа, со всеми вытекающими. Не приходило в голову?

Здравствуйте, Farsight, Вы писали:

F>·>Вот и думай кому ещё нужет этот ваш .net/php/дельфи кроме как велоинструкторам.
F>Запахло Apache'м .
Причем тут Апач?

F>Так уж сложилось, что .net догоняющая платформа, со всеми вытекающими. Не приходило в голову?
В каком месте догоняющая? Что именно удалось догнать? Так что не догоняющая, а просто отсталая. Тот же .net compact, подогоняли, да бросили ещё до Андроида.

Здравствуйте, Farsight, Вы писали

Уровень платформы определят salary. Уровень .net 80-140. Уровень Java 150-500. Вот она реальность. Те кто выбрал .net неудачник по умолчанию. Вот она реальность

Здравствуйте, ·, Вы писали:

·>как часто попадаются проекты с верифицированным кодом? Один на миллион? Мне не попадались...

Я тебе привожу иллюстрацию показывающую что в корректном коде они не нужны. ВСЁ! Какая разница как часто попадаются такие проекты?

EP>>Даже если ты не веришь в то что они помогают в отлове багов, то всё равно остаётся аспект документирования пред/пост-условий и т.п. Причём это не просто текстовый комментарий, а реально выполняемая проверка, пусть даже только при тестировании.
·>Угу, что прекрасно делается юнит-тестами.

Каким образом? Юнит-тесты в общем случае это набор входных и выходных векторов, которые помимо всего прочего хранятся отдельно от кода.

EP>>При этом втыкаются непосредственно во время кодирования, не переключая контекст. И являются крайне дешёвыми.
·>TDD же.

И причём тут TDD?

EP>>>>·>Для чего ещё?
EP>>>>Например инварианты класса. Классы (с private полями) это не просто группировка полей а-ля структуры (либо эмуляция структур через getters&setters) — это ещё и дополнительные инварианты наложенные на эти private поля.
EP>>·>Т.е. косяки дизайна в алгоритме затыкаются ассертами.
EP>>Шта? Как ты пришёл к этому выводу? Я говорю про инварианты классов, и они таки существуют.
·>Т.е. инварианты "сами нарушились"?

Не сами, а из-за бага, которые нужно отлавливать. Ассерты способствуют этому в том числе.

EP>>Ты так и не объяснил почему их не следует использовать, учитывая их минимальную цену. Пока всё сводится к "я их не использую, значит их не следует использовать".
·>Ок. Насчёт цены согласен, об этом я уже писал. Если с тестами плохо, то использовать ЮТ получится дороже ассертов, получается компромисс — уж лучше что-то, чем ничего.

Ещё раз, я не говорю про то что не нужно использовать тесты. Я использую и тесты и ассерты — совместно.

·>В хорошо организованном проекте тесты дёшевы и ассерты становятся бессмысленны.

Я использую и тесты и ассерты. А ты так и не объяснил почему нужно отказываться от крайне дешёвых ассертов, отрабатывающих в большем количестве случаев чем юнит-тесты. Они никак не мешают, пишутся не отходя от кассы, отрабатывают в огромном количестве состояний.
Может потому что ты веришь в то что юнит-тесты покрывают все граничные ситуации? Или хотя бы что ты их все локализовал? Очевидно ни то, ни другое не гарантируется, и непонятно почему нужно отказываться от дополнительного практически бесплатного средства?

EP>>И непонятно причём тут "лучший дизайн алгоритмов" — речи о том чтобы делать плохие алгоритмы не было. При этом "лучший дизайн алгоритмов" не избавляет от необходимости их тестирования, одним из аспектов которого являются в том числе assert'ы.
·>Ассерты это тестирование для убогих.

Ассерты не заменяют остальное тестирование — ты это сам придумал, и сам же с этим споришь.

EP>>>>Нет, так как после формальной верификации (либо например через несколько релизов без выстреливания assert'ов) их можно отключить, в то время как проверки не являются опциональными.
EP>>·>Ээээээ.. Ты что под формальной верификацией понимаешь?
EP>>Доказывание свойств алгоритмов на формальном языке с автоматической проверкой правильности применения правил вывода и т.п.
·>Ну... и зачем при наличии верификации вообще нужны ассерты? Откуда они возьмутся? Какой смысл их писать в верифицируемом коде?

Ещё раз, я иллюстрирую их опциональную семантику, смотри выделенное.

EP>>>>Нет, неразрешимы означает что неразрешимы. Нужность/ненужность тут ортогонально — смотри например halting probelm
EP>>·>halting problem это построение универсального алгоритма. Причём тут это? Программист обычно может чуть больше. По крайней мере в случае, когда хочет написать ассерт.
EP>>Смотри выделенное — проверка далеко не каждого пред/пост-условия является разрешимой задачей.
·>Не понял. И как ты проверишь с помощью ассерта неразрешимое предусловие? И чем это будет отличаться от ЮТ?

Смотри контекст:

·>>>"Опциональный жесткий фейл". Это не звучит для тебя как оксюморон?
EP>>Нет. Нарушение условия ассерта это жёсткий фейл, баг в программе. Точно также как и нарушение любого пред/пост-условия вокруг каждого выражения (а-ля Hoare Triple).
EP>>При этом несмотря на то что это жёсткие фейлы, в релизной версии нет даже и малой части всех этих проверок, а некоторые и вовсе неразрешимы.

·>Ок. Допустим у тебя есть ассерт какой-то. И ты считаешь, что цена велика. А в соседней строчке ещё один ассерт и цена мала. Ты включишь или выключишь ассерты в релизе?

Я же говорил уже выше — assert'ы разбивают на классы. В зависимости от заданного уровня при компиляции часть из них, либо все отключаются.
Подобное используется например в Bloomberg'е — 1, 2.

·>Ок, допишу ещё причину.
·>4. Плохо дело с языком, убогий компилятор, для преждевременной оптимизации. Приходится явно подсказывать компилятору какие проверки необязательны.

Ещё раз поясняю — assert'ы используются далеко не только для тех вещей которые автоматически проверяются в managed языках. Собственно наличие assert'ов в managed языках как раз тому подтверждение

Здравствуйте, a_g_99, Вы писали:

__>Уровень платформы определят salary. Уровень .net 80-140. Уровень Java 150-500. Вот она реальность. Те кто выбрал .net неудачник по умолчанию. Вот она реальность

Это феерично, спасибо!