система типов защищает только от ошибок типов
тесты защищают от ошибок типов и ещё многих других ошибок
конечно, если есть время и деньги, можно делать двойную защиту от ошибок типов: и системой типов и тестами
я отношусь к тем людям, которые считают, что порой потраченные на удовлетворение компилятора ресурсы мозга можно было бы применить лучшим образом, особенно если отсутствие ошибок уже проверено тестами, но вот это своё мнение я доказывать не буду
Мы все отлично знаем, что защищенность через покрытие — иллюзия. Тесты пишут руками, они по определению менее надежны, чем встроенная в язык система проверки типов.
Вообще-то научные исследования говорят обратное: что защищённость через покрытие выше, чем через сильную типизацию.
Порадовало, что в тексте много про доверие. Доверие это действительно очень важная смазка общественной жизни, благодаря которой очень многое становится проще и лучше. Конечно, если общество достаточно зрелое, чтобы доверие было обоснованным.
Странно, я только что из Германии зашёл на gutenberg.org и скачал оттуда книгу Томаса Манна безо всяких предупреждений. Зашёл через крупнейшего немецкого провайдера, диапазоны адресов которого точно должны быть известны.
ну так я и написал "если". Проверить этот вариант — дело нескольких минут, но это не было сделано.
А вы попробуйте прокачать скилл и писать крутые штуки на уровне крутых прогеров, почему бы и нет ;)
потому что малы шансы того, что я один напишу код лучше, чем группа программистов, работавшая над той же задачей в реализации языка. Кроме того, если я учусь программировать, решая какую-то задачу, я не буду предлагать учебный проект в качестве библиотеки. А отношусь я так к квалификации автора потому, что за одну минуту ускорил его регекспы в два раза банальным улучшением.
Не уверен, что это верно. Насколько мне известно, Python использует рекурсивный backtracking, откуда растет экспоненциальная сложность.
согласен, это может оказаться неверным. Но это решение было бы сделать (или взять ещё одно готовое) быстрее, чем городить самому. А вот если бы после проверки оно оказалось ещё недостаточно быстрым, то имело бы смысл делать своё.
потому что регексп не магия, какие проверки в него напишешь, те и будут делаться. Поставил флаг i — будет проверка без учёта регистра, а не поставил — не будет её.
тесты защищают от ошибок типов и ещё многих других ошибок
конечно, если есть время и деньги, можно делать двойную защиту от ошибок типов: и системой типов и тестами
Вообще-то научные исследования говорят обратное: что защищённость через покрытие выше, чем через сильную типизацию.
у него там в комментариях писали, что будто бы у Rust реализация регекспов крутая
впрочем, это неважно, всё равно я вначале предложил оптимизированный регексп на префиксном дереве
да хотя бы и бенчмарком
ну так я и написал "если". Проверить этот вариант — дело нескольких минут, но это не было сделано.
потому что малы шансы того, что я один напишу код лучше, чем группа программистов, работавшая над той же задачей в реализации языка. Кроме того, если я учусь программировать, решая какую-то задачу, я не буду предлагать учебный проект в качестве библиотеки. А отношусь я так к квалификации автора потому, что за одну минуту ускорил его регекспы в два раза банальным улучшением.
согласен, это может оказаться неверным. Но это решение было бы сделать (или взять ещё одно готовое) быстрее, чем городить самому. А вот если бы после проверки оно оказалось ещё недостаточно быстрым, то имело бы смысл делать своё.
Иногда эта позиция бывает ошибочна, но это не повод называть её заблуждением :) Для большинства ситуаций она всё-таки справедлива.
в данном случае оценка сложности одинакова, потому что алгоритм один и тот же: сравнение строки с префиксным деревом — на регекспе или на питоне
есть, но не всегда используются, поэтому в среднем ускорение всё равно будет