В целом ко фронту всё это менее применимо. Об этом сказано вначале статьи. Там где может быть неадекватный ввод, то, конечно, нужно всё тщательно проверять.
Вообще, сильная типизация дополняет идею хрустального кода тем, что выполнение контракта (формальное) отслеживается автоматически компилятором. Но по сути своей она, действительно, защитное программирование.
То есть компилятор отследит, что аозраст >=0, но не отсследит, что больше или равен 18.
Сама идея выдумывалась для малотипизированных языков. В рамках хрустального программироаания возраст проверяется 1 раз при заведении пользователя в систему. Везде далее считается, что он более 18 и не проверяется.
То что компилятор, транспайлер, обфускатор и т.п. отработали как надо — это даже не обсуждается. Конечно, для разработчика обременённого корпоративными правилами с кругами тестировщиков может быть удобнее в каждую функцию насовать по 100 проверок, только в конечном итоге это приводит к раздутым и тормозящим приложениям. Которые, зачастую, и глючат в придачу.
Подход «Хрустальный код» можно пприменять только тогда, когда ему следуют все участники разработки. И при абсолютно идеентичной исполнимой среде. И когда при падении ничего критичного для бизнеса не происходит.
Смотрите, в скомпилированной программе код практически всегда исполняется предсказазуемо, а вот на клиенте, да ещё и в интерпретируемом языке, который на разных версиях интерпретаторов исполняется, конечно, нужно обрабатывать как можно большее число ошибок.
При компилированном коде уже один лишний if в «горячем цикле» портит производительность. А во фронте это не так важно.
Фронт — это вообще отдельное царство, где у каждого пользователя свой браузер, разных версий. Не говоря о том, что пользователи могут любой бред вводить.
Спасибо за найденную неточность!. Идея была в том, что какие-то проверки кроме самих проверок могут делать что-то с данными. Делать их «корректнее». Например nil преобразовать в 0. Потом куда-то ещё передать результат построенный на неверном входе. И поэтому потеряется изначальная ошибка. И найти её будет невероятно трудно.
Спасибо за найденную неточность. Важно чтобы только ПЕРВЫЕ 10 лет убывали по важности в 2 раза.
А дальше нужно более плавное стремление к нулю, чтобы "классика" обесценивалась очень медленно.
Функция выбрана таким образом, чтобы быстрее всего инфляция была вначале, а потом замедлялась. Аналогия — классика в литературе, значение которой падает, но настолько медленно, что это совершенно незаметно.
А для этого лучше подходит арктангенс, так как у него более тяжелые "хвосты".
"Колокол" производной логистической функции более "сосредоточен" и имеет более тяжелую верхнюю часть и легкие хвосты. "Колокол" производной арктангенса (распределение Коши) более "расплывчат", имеет более тяжелые хвосты, что соответствует его медленному стремлению к нулю.
Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
Спасибо за коммент!
Кстати, насчёт tview, сколько килобайт добавляетт ваш проект к исполнимому файлу?
gccgo медленнее официального компилятора в 9 раз. Думаю версия для llvm примерно такого же уровня скорости.
Вы пробовали что-то из них в работе? Какие впечатления?
Ну а как тогда предлагаете делать быстрые программы? Если всё проверять, то будут тормоза.
Да и выглядеть будет такой раздутый код отвратительно.
В статье больше не про контракты, а про минимизацию проверок, которыми часто злоупотребляют в ущерб скорости.
В целом ко фронту всё это менее применимо. Об этом сказано вначале статьи.
Там где может быть неадекватный ввод, то, конечно, нужно всё тщательно проверять.
Да. В начале статьи я написал, что для собственных проектов использую.
Если соглашения и контракты забываются, то подход не применим.
Спасибо за коммент. Добавил в статью.
Вообще, сильная типизация дополняет идею хрустального кода тем, что выполнение контракта (формальное) отслеживается автоматически компилятором. Но по сути своей она, действительно, защитное программирование.
То есть компилятор отследит, что аозраст >=0, но не отсследит, что больше или равен 18.
Сама идея выдумывалась для малотипизированных языков. В рамках хрустального программироаания возраст проверяется 1 раз при заведении пользователя в систему. Везде далее считается, что он более 18 и не проверяется.
Да, Раст должен лучше подходить.
Статья по теме прямо. Вставил в свою статью ссылку на вашу
То что компилятор, транспайлер, обфускатор и т.п. отработали как надо — это даже не обсуждается. Конечно, для разработчика обременённого корпоративными правилами с кругами тестировщиков может быть удобнее в каждую функцию насовать по 100 проверок, только в конечном итоге это приводит к раздутым и тормозящим приложениям. Которые, зачастую, и глючат в придачу.
Подход «Хрустальный код» можно пприменять только тогда, когда ему следуют все участники разработки. И при абсолютно идеентичной исполнимой среде. И когда при падении ничего критичного для бизнеса не происходит.
Ссылку приведите, интересно
Браузер — это просто среда исполнения.
Смотрите, в скомпилированной программе код практически всегда исполняется предсказазуемо, а вот на клиенте, да ещё и в интерпретируемом языке, который на разных версиях интерпретаторов исполняется, конечно, нужно обрабатывать как можно большее число ошибок.
При компилированном коде уже один лишний if в «горячем цикле» портит производительность. А во фронте это не так важно.
Фронт — это вообще отдельное царство, где у каждого пользователя свой браузер, разных версий. Не говоря о том, что пользователи могут любой бред вводить.
Спасибо! Добавлено.
Спасибо за найденную неточность!. Идея была в том, что какие-то проверки кроме самих проверок могут делать что-то с данными. Делать их «корректнее». Например nil преобразовать в 0. Потом куда-то ещё передать результат построенный на неверном входе. И поэтому потеряется изначальная ошибка. И найти её будет невероятно трудно.
Спасибо за найденную неточность. Важно чтобы только ПЕРВЫЕ 10 лет убывали по важности в 2 раза.
А дальше нужно более плавное стремление к нулю, чтобы "классика" обесценивалась очень медленно.
Функция выбрана таким образом, чтобы быстрее всего инфляция была вначале, а потом замедлялась. Аналогия — классика в литературе, значение которой падает, но настолько медленно, что это совершенно незаметно.А для этого лучше подходит арктангенс, так как у него более тяжелые "хвосты".
"Колокол" производной логистической функции более "сосредоточен" и имеет более тяжелую верхнюю часть и легкие хвосты. "Колокол" производной арктангенса (распределение Коши) более "расплывчат", имеет более тяжелые хвосты, что соответствует его медленному стремлению к нулю.
Об этом и говорит автор поста. Что проблемы нпчинаются, когда число ядер у всех работающих вм больше, чем на хосте.
Не помню, говорил я это или нет. Но если в Hyper-V есть поддержка Huge Pages, то это может здорово помочь. Но Huge Page исключает переподписку по памяти.
Таблицы TLB должны быть нормальными у Эпик.
Я этот пример привёл потому, что исследовал его. Именно его. Аллокация происходит.
По логике её можно не делать. Указатель r и так аллоцирован. Можно его перезаписать. Но компилятор аллоцирует.