AZ
Т-34 85
а почему подхватили-то? Почему не сказали "пиздишь, там изи"?
чтобы так скзаать нужно разбираться
Size: a a a
2020 March 08
Т8
безопасный системный язык это всегда мощная система типов, на которую у тебя аллергия
окей, ОТНОСИТЕЛЬНО безопасный
AZ
Можешь расшифровать что здесь написано?
функция принимаен на вход ненулевой инт (а), ненулевой беззнаковый инт (б) и возвращает некое число с и пруф, что с меньше чем а или б
Т8
В средневековье считалось что домовой ссыт в молоко из-за чего оно киснет
?
p
функция принимаен на вход ненулевой инт (а), ненулевой беззнаковый инт (б) и возвращает некое число с и пруф, что с меньше чем а или б
1. Ты предлагаешь для каждой операции в программе писать теорему?
2. В теореме можно тоже ошибиться
2. В теореме можно тоже ошибиться
AZ
только тут косяк, оно может быть больше чем б, так что компилятор бы мне сказал что яхерню написал
AZ
1. Ты предлагаешь для каждой операции в программе писать теорему?
2. В теореме можно тоже ошибиться
2. В теореме можно тоже ошибиться
1. это проще чем тест
2. от этого уже ничего не спасет
2. от этого уже ничего не спасет
Т8
если ты опишешь требования
то если забудешь минус то тебе компиль скажет
sub :: NonZeroInt a -> NonZeroUInt b -> (Int c, c < a && c < b)то если забудешь минус то тебе компиль скажет
а если я сделал всё правильно, а компилятор меня ебёт - может быть такое?
AZ
1. Ты предлагаешь для каждой операции в программе писать теорему?
2. В теореме можно тоже ошибиться
2. В теореме можно тоже ошибиться
выдержка из https://habr.com/ru/post/193722/
При эксплуатации уже написанной программы интересует ровно одно: как часто оно падает, бибикает и всё портит. Так вот, в сравнении с python — несравнимо реже. Да, при должной обработке напильником можно словить утёкший в toplevel exception, но вероятность этого крайне мала (я видел один раз за всё время использования среди всех программ).
Вероятность глупых ошибок значительно меньше. И когда я говорю «значительно», это это не в теории, а на практике, то есть по наблюдению за одним и тем же продуктом, написанным большей частью одними и теми же людьми на Хаскеле и Питоне.
Питон, как и любой другой динамически типизированный язык — это сплошная мина замедленного действия. Обо всех плохих ситуациях надо думать явно, плюс никто не страхует от мелких локальных ошибок или небрежностей. Ошибки либо проявляются в рантайме, либо их можно либо прятать в неявное except: pass (что ещё хуже). Object of type 'NoneType' has no method — наше всё. А если эта ошибка оказывается в редкой ветке — тогда мина получается совсем замедленная и срабатывает тогда, когда код уже давно «стабильный и хорошо себя показавший», и вообще, 300 дней аптайма.
Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.
На Хаскеле таких ошибок, ошибок уровня «ой, в этом ветвлении забыл проверить» или «перепутал возвращаемый тип» в программах не появляется. Программисты это аргументируют удобной системой типов, которая позволяет на этапе компиляции отловить большую часть таких ошибок, плюс язык, позволяющий писать главное, не отвлекаясь на счёт индексов массивов и временные переменные. Им виднее.
По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.
Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.
При эксплуатации уже написанной программы интересует ровно одно: как часто оно падает, бибикает и всё портит. Так вот, в сравнении с python — несравнимо реже. Да, при должной обработке напильником можно словить утёкший в toplevel exception, но вероятность этого крайне мала (я видел один раз за всё время использования среди всех программ).
Вероятность глупых ошибок значительно меньше. И когда я говорю «значительно», это это не в теории, а на практике, то есть по наблюдению за одним и тем же продуктом, написанным большей частью одними и теми же людьми на Хаскеле и Питоне.
Питон, как и любой другой динамически типизированный язык — это сплошная мина замедленного действия. Обо всех плохих ситуациях надо думать явно, плюс никто не страхует от мелких локальных ошибок или небрежностей. Ошибки либо проявляются в рантайме, либо их можно либо прятать в неявное except: pass (что ещё хуже). Object of type 'NoneType' has no method — наше всё. А если эта ошибка оказывается в редкой ветке — тогда мина получается совсем замедленная и срабатывает тогда, когда код уже давно «стабильный и хорошо себя показавший», и вообще, 300 дней аптайма.
Тесты, которые «покрывают весь код», к сожалению, совсем не покрывают «все возможные типы входных данных» (которые, внезапно, динамические) и совсем не спасают от ошибок типизации.
На Хаскеле таких ошибок, ошибок уровня «ой, в этом ветвлении забыл проверить» или «перепутал возвращаемый тип» в программах не появляется. Программисты это аргументируют удобной системой типов, которая позволяет на этапе компиляции отловить большую часть таких ошибок, плюс язык, позволяющий писать главное, не отвлекаясь на счёт индексов массивов и временные переменные. Им виднее.
По опыту разборов найденных ошибок я могу сказать, что большая часть ошибок, с которыми мы сталкивались — это либо ошибка в ТЗ (то есть ошибка вашего покорного слуги), либо неправильно понятое ТЗ программистами. Но не локальная ошибка или забывчивость.
Из этого вытекает парадоксальный вывод: баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией, потому что в языке с динамической типизацией очередное место, где вдруг внезапно вылез NoneType, поправил и ладушки, а на Хаскеле надо с алгоритмом разбираться да по повводу неясности ТЗ с другими людьми ругаться.
Т8
то, что ты не видел, что их кто то используют, не значит, что их не используют. у меня во дворе арбузы не растут, но я отдаю себе отчёт в том, что они есть
покажи, как их юзать в Java или в JavaScript
p
1. это проще чем тест
2. от этого уже ничего не спасет
2. от этого уже ничего не спасет
Ну правильному написанию этого кода с теоремами думаю нужно дохрена времени потратить. Несколько лет писать прежде чем допрешь как писать так, чтобы покрыть весь код теоремами и чтобы он хорошо читался.
Т8
чтобы так скзаать нужно разбираться
ну, вот. Кто разобрался - тот академик
AZ
Т-34 85
а если я сделал всё правильно, а компилятор меня ебёт - может быть такое?
может, это же как борровчекер, только не для лайтфаймов
AZ
тогда ты переписываешь чтобы он понял что всё ок или юзаешь ансейф
p
Т-34 85
а если я сделал всё правильно, а компилятор меня ебёт - может быть такое?
Значит ты сделал что-то нелогичное
AZ
Т-34 85
ну, вот. Кто разобрался - тот академик
"кто разобрался в расте - тот академик"
AZ
Значит ты сделал что-то нелогичное
системы типов делают чтобы они 99% кейсов ловили, потому что для 100% будет слишком иноплаетно все выглядеть
Т8
тогда ты переписываешь чтобы он понял что всё ок или юзаешь ансейф
угадай, как будут действовать массы?
AZ
Т-34 85
угадай, как будут действовать массы?
смотрю на раст, и вижу, что большинство ансейф запрещают на уровне проекта
Т8
смотрю на раст, и вижу, что большинство ансейф запрещают на уровне проекта
а шо будет, когда подтянутся хуяк-хуяк конторки?