K
я думаю бытовая психология плохо подходит для оценки качества программ
Size: a a a
2021 February 24
A
По поводу промоушена и связанных ошибок. Как то разбирался в плюсовом коде любителя реализовывать операторы привидения типов (которые вообще не очень рекомендуют использовать). Вот это был ад 🙂
A
Типа для удобства реализованнй промоушн иногда к таким забавным штукам приводит
АО
У Роберта Шекли помнится был роман "Обмен разумов". Там можно было поменяться разумом с марсианином (чтобы не лететь на Марс), но в контракте был пункт о возмездии. Смысл его был в том, что если перенесённый в теле марсинаниа сломает ногу, то по возвращению в своё тело, ему тоже сломают ногу - максимально аккуратно. В ответ на вопрос "но ведь это же может быть просто случайностью, разве можно так?" человеку ответили, что " вы знаете, после введения этого пункта, количество случайностей резко сократилось".
Если у разработчика будут проблемы из-за того, что компилятор не будет проверять типы, то ему придётся писать более аккуратный код.
Если у разработчика будут проблемы из-за того, что компилятор не будет проверять типы, то ему придётся писать более аккуратный код.
K
вы сейчас повторили свой тезис, просто снабдив его ссылкой на "авторитетный" источник 😁
АО
вы сейчас повторили свой тезис, просто снабдив его ссылкой на "авторитетный" источник 😁
Хм, ок, понятно, сворачиваем дискуссию. Спасибо, было очень интересно пообщаться.
AP
соглашусь что лучше иметь статическую проверку типов, которая автоматом поймает хотя бы часть ошибок, чем не иметь никакой
однако пока нигде не решён вопрос о том, как такую проверку сделать не теряя удобства и краткости написания, и общности получаемого кода
однако пока нигде не решён вопрос о том, как такую проверку сделать не теряя удобства и краткости написания, и общности получаемого кода
2021 February 25
ЕП
соглашусь что лучше иметь статическую проверку типов, которая автоматом поймает хотя бы часть ошибок, чем не иметь никакой
однако пока нигде не решён вопрос о том, как такую проверку сделать не теряя удобства и краткости написания, и общности получаемого кода
однако пока нигде не решён вопрос о том, как такую проверку сделать не теряя удобства и краткости написания, и общности получаемого кода
Нигде - в смысле ни в каком языке пронраммирования? В хаскелле решен мне кажется.
ЕП
Полщита это хуже чем отсутствие щита.
Прочитал как полшита ) half shit, подумал новый термин
АО
Это всё от изучения английского.
ЕП
Это всё от изучения английского.
Это конечно корень зла )
DG
Мне нужно было сделать условно что-то вроде такого:
for (i, x) in enumerate(v)
s += i + x
end
ЕП
В соседнем чате по data engineering была сегодня дискуссия, смысл которой на русском книг по базам данных лучше не читать ;)
ЕП
| x | это лямбда так красиво записывается в расте?
DG
| x | это лямбда так красиво записывается в расте?
да, обычная лямбда функция
АО
Это не совсем честно. Насколько я понимаю,
v = vec[1, 2, 3, 4] позволяет компилятору подобрать тип. Если явно указать, что тип v это i32 (не помню как это записывается) или написать v = vec[-1, 2, 3, 4], то уже будет ошибка.АО
По крайней мере мне такое пишет
АО
Compiling playground v0.0.1 (/playground)
error[E0277]: the trait bound `usize: Neg` is not satisfied
--> src/main.rs:2:18
|
2 | let v = vec![-1, 2, 3, 4];
| ^^ the trait `Neg` is not implemented for `usize`