Эмм, а указать, что это перевод и дать ссылку на оригинал?

>В течение многих лет у меня было стойкое недоверие к интерпретируемым языкам.

Давайте будем честными — все что написано дальше (по крайней мере этот же абзац) — это вовсе не про интерпретацию. Не стоило ее тут мешать с системой типов в одну кучу.

Почему же? У меня похожий опыт, особенно на больших проектах. Статически типизированный язык очень помогает, другое дело на интерпретированном языке писать быстрей.

Вы также как автор путаете интерпретацию и типизацию.

Хорошо, вы правы.


Я предполагаю что автор описывал популярные языки, и обращался к тем кто их использует повседневно.

Возьмите Dart: интерпретируемый язык со строгой статической типизацией. Так, что одно не исключает другого.

однако есть интерпритируемые с типами.

Это о статической типизации

так и со статической есть
В контексте оригинальной фразы: «It’s still a conceptually sound concurrent model with real parallelism…», слово sound следует переводить как корректный, надежный. К звуку оно не имеет никакого отношения.
Любой, кто видел большую программу на интерпретируемом языке в production, знает, что вносить изменения можно только небольшими частями, в противном случае вы сильно рискуете.

Это связано с тем, что она собирается только при запуске? Так может стоит ее собрать? Или вы рискуете чем?


Все проблемы, которые я видел были от того, что, внезапно, надо таки проверять код на запускаемость. В компилируемых языках такая проверка просто происходит во время компляции. А в чем еще разница?

Это о времени когда происходит проверка на соответствие типов. В динамических языках это происходит вотвремя исполнения, из-за этого легко получить ошибки в раньайме. Языки со статической типизацией выигрывают в этом.

В языках со статической типизацией ошибки в рантайме можно получить другими веселыми способами.

Никто с этим не спорит. Статическая типизация не спасёт от логических ошибок. Но рефакторинг делать намного проще со статический типизацией

Спасает, и еще как!

Как же? Пишу на расте, хотя и не хочется но клепаю много логических ошибок :)

Насколько я понимаю в Rust есть union-тайпы и pattern matching, которые открывают возможности для type driven development. Я не могу пока что сказать что-то конкретное по поводу жизнеспособности этого подхода, но по первым ощущениям — он приносит выгоду.

Для примера можно почитатьType Driven Development with F#
К сожалению не владею Rust, но в C#-Java-Kotlin следование принципам Solid, а особенно (S)ingleResponsobility отсекает много ошибок на уровне синтаксиса.

Например, при рефакторинге наткнулся на очень запутанный класс RequestInfo. Он являлся одновременно и сущностью ORM, и DTO для HttpClient и DTO между слоями.

Разделил этот класс на 4 (!!!) разных класса, каждый из которых занимался чем то конкретным. И тут… код прекратил компилироваться, поскольку оказалось что в оригинале, межслойный Dto шел в HttpClient минуя БД. Я пошел к оригинальным авторам и они сказали «О, так и в правду не должно было быть». Мне понравилось ;)
В одной из тысяч измененных строчек при определенном условии вы случайно передадите переменную не того типа и все, привет. А тестами все покрыть невозможно.
Ну… да. А еще вы можете передать null, например, в Java и тоже все поломается в рантайме.

Я не совсем понимаю, почему остальные проблемы рантайма игнорируются. У нас вроде только раст пока про тот подход, что если программа собралась, то хоть без ошибок использований языка.
Да никто не игнорирует эти проблемы.
Просто есть ошибки которые присутствуют и там и там, но часть проблем в языках со статической типизацией отсутвует как класс, тем самым сокращая объем элементов которые надо держать в голове во время разработки…
Поэтому когда кто-то говорит об ошибках в динамических языках, их высказаывания надо читать примерно не как «в статических языках нет проблем, а в динамических есть problem», а как «помимо общих проблем, в динамических языках есть еще и problem».
А еще вы можете передать null

Забавно, но вы как раз пытаетесь проиллюстрировать проблемы статической типизации наиболее встречающимся динамическим элементом, от которого не защитились.

К слову, у Java одна из наиболее убогих систем типизации по сравнению со многими другими языками.

Я не совсем понимаю, почему остальные проблемы рантайма игнорируются
Разные языки решают разные проблемы по-разному. Кроме того, существует огромный пласт языков немейнстримных или вообще игрушечных, в которых многие проблемы пытаются решить.

А какая из проблем вам больше всего доставляет?
Null по сути это и есть динамическая типизация, потому что по сути это пара `T | NULL`, которая маскируется под тип `T`. Так что да, этот пример как раз доказывает то, что динамическая типизация при рефакторинге оказывается тем еще товарищем…
Эх, если бы типизация была главной проблемой написания веб-сервисов, а скорость отдачи тупого плейнтекста — решающим показателем
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.