Comments 24
Эмм, а указать, что это перевод и дать ссылку на оригинал?
Давайте будем честными — все что написано дальше (по крайней мере этот же абзац) — это вовсе не про интерпретацию. Не стоило ее тут мешать с системой типов в одну кучу.
Почему же? У меня похожий опыт, особенно на больших проектах. Статически типизированный язык очень помогает, другое дело на интерпретированном языке писать быстрей.
Любой, кто видел большую программу на интерпретируемом языке в production, знает, что вносить изменения можно только небольшими частями, в противном случае вы сильно рискуете.
Это связано с тем, что она собирается только при запуске? Так может стоит ее собрать? Или вы рискуете чем?
Все проблемы, которые я видел были от того, что, внезапно, надо таки проверять код на запускаемость. В компилируемых языках такая проверка просто происходит во время компляции. А в чем еще разница?
Это о времени когда происходит проверка на соответствие типов. В динамических языках это происходит вотвремя исполнения, из-за этого легко получить ошибки в раньайме. Языки со статической типизацией выигрывают в этом.
Никто с этим не спорит. Статическая типизация не спасёт от логических ошибок. Но рефакторинг делать намного проще со статический типизацией
Как же? Пишу на расте, хотя и не хочется но клепаю много логических ошибок :)
Для примера можно почитатьType Driven Development with F#
Например, при рефакторинге наткнулся на очень запутанный класс RequestInfo. Он являлся одновременно и сущностью ORM, и DTO для HttpClient и DTO между слоями.
Разделил этот класс на 4 (!!!) разных класса, каждый из которых занимался чем то конкретным. И тут… код прекратил компилироваться, поскольку оказалось что в оригинале, межслойный Dto шел в HttpClient минуя БД. Я пошел к оригинальным авторам и они сказали «О, так и в правду не должно было быть». Мне понравилось ;)
Я не совсем понимаю, почему остальные проблемы рантайма игнорируются. У нас вроде только раст пока про тот подход, что если программа собралась, то хоть без ошибок использований языка.
Просто есть ошибки которые присутствуют и там и там, но часть проблем в языках со статической типизацией отсутвует как класс, тем самым сокращая объем элементов которые надо держать в голове во время разработки…
Поэтому когда кто-то говорит об ошибках в динамических языках, их высказаывания надо читать примерно не как «в статических языках нет проблем, а в динамических есть problem», а как «помимо общих проблем, в динамических языках есть еще и problem».
А еще вы можете передать null
Забавно, но вы как раз пытаетесь проиллюстрировать проблемы статической типизации наиболее встречающимся динамическим элементом, от которого не защитились.
К слову, у Java одна из наиболее убогих систем типизации по сравнению со многими другими языками.
Я не совсем понимаю, почему остальные проблемы рантайма игнорируютсяРазные языки решают разные проблемы по-разному. Кроме того, существует огромный пласт языков немейнстримных или вообще игрушечных, в которых многие проблемы пытаются решить.
А какая из проблем вам больше всего доставляет?
Прогулка по быстрому, безопасному и почти законченному веб-сервису на Rust