Статическая типизация позволяет исключить некоторые трудновылавливаемые ошибки, которые возможны при работе с динамической типизацией.
Если программу пишет новичёк и использует язык с динамической типизацей, то код очень часто превращается в говно.

>>1946
>Статическая типизация позволяет исключить некоторые трудновылавливаемые ошибки, которые возможны при работе с динамической типизацией.
Что мешает их вылавливать функциями типа mustbe? mustbe(myVar,string) // если myVar есть строчка - все ок, иначе TypeError

>>1947
>Что мешает их вылавливать функциями типа mustbe?
Это что ещё за костыли? Зачем их вылавливать, когда можно просто объявить им тип?

>>1948
>Это что ещё за костыли? Зачем их вылавливать, когда можно просто объявить им тип?
В итоге ты так больше костылей наплодишь. Ибо напоминаю, в большинстве случаев в массивах находятся разнородная информация, а функции могут(и должны) возращать значения разных типов.
Ни один статически типизированный язык не умеет так:
function HelloWorld(arg)
{
switch(arg)
{
case "Hello": return "World"
case "Bye": return "bye-bye"
default: return false
}
}

>>1949
>в большинстве случаев в массивах находятся разнородная информация
Значит беда с архитектурой приложения. В массивах надо стараться хранить значения одинаковых типов, как и функция должна возвращать значение определённого типа.
Твой пример выше, когда в случае по умолчанию возвращается false, исключение - это иногда бывает удобно. Я говорю про случаи, когда функция возвращает в одном случае строку, в другом - массив или чило, вот это зло и антипаттерн, так делать не надо.

>>1950
> В массивах надо стараться хранить значения одинаковых типов
А если этот массив - дерево?

>>1945 (OP)
> нахуя нужна эта статическая типизация?
Чтобы при каждой операции со значениями не дрочить хитровыебанную логику выяснения способа реализации этой операции в зависимости от типа значения, а сразу её делать не глядя.
Чтобы каждую переменную хранить не как значение + описание, а просто как значение.

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

>>1952
> Чтобы вкурить программирование не поверхностно, рано или поздно нужно обязательно пройти на нижний уровень и разобраться с тем, как всё это делает процессор, научиться основам языка ассемблера.
Это собственно и делаю. Изучаю nim, тк он самый приятный из байтоебских императивных языков. Но система типов это ужас какой-то. А ведь в nim они даже не выводятся(как в хаскелле). Я так привык, что везде основа - объект / функция, что с этими типами я век не сдружусь.

>>1945 (OP)
У ЯП без и со статической типизацией есть свои преимущества и недостатки. Аноны выше (в т. ч. и ты) уже их описали.
От себя добавлю, что при статической типизации может быть удобно работать с большими массивами однотипных данных типа картинок, видео, потому что быстро.

Ну нахуй этот nim. Я заебался. Даже
MyComponent = {id:0}
не работает, что это за язык такой?

>>1956
>удобно работать с большими массивами
Смотря, что понимать под удобством.

>>1972
>что это за язык такой?
Типичный представитель хипсторских языков. Один из таких обсуждается в соседнем треде.

>>1974
Если ты про лайси, то там скорее всего можно было бы сделать что-то типа hashtable(valuetype,keytype) dict := [a : b,c : d];
Это статическая типизация и придётся выбрать тип для значения и ключа. Вместо hashtable мог бы быть также какое-нибудь дерево или другой ассоциативный массив.

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

>>1976
>методы по умолчанию не виртуальные
В смысле мультиметоды / динамическая диспетчеризация, которые не привязаны к какому-либо объекту?

>>1949
Я кроме как в LUA нигде с таким не сталкивался, и мне на первый взгляд - 1 медленно в рантайме, 2 приходится смотреть тело функции чтобы понять, что ожидать от функции и что же она хочет вообще. А если в сложной программе я вижу что получаю непонятный результат непонятного типа, то мне немного плохеет.
Вопрос тебе - IDE может показать что возвращает эта функция, или рельно самому смотреть надо?

Алсо, ты возвращаешь СТРОКУ или НЕТ из ДА/НЕТ. А хотел СТРОКУ или НИЧЕГО из СТРОКА/НИЧЕГО.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=296685faaa453f02915ecc5b50fe33aa

>>2060
> Как предлагается обрабатывать результат такой функции?
if('Hello') {
console.log('Condition is executed')
}

>>1945 (OP)
>Статическая типизация - нахуя?
Что-бы писать меньше тестов. А написание тестов, так-то, занимает времени поболее, чем написание функционала.

Подумайте сами, какой из вариантов объявления функции будет лучше, и что будет, если случайно при написании вызова такой функции, поменять аргументы местами?
foo(a, b, с, d)

foo(bool a, bool b, bool с, bool d)

foo(UseToToSeTo a, INadoEtoDelat b, EscheChtoTo с, INeZabytEto d)

>>1947
>Что мешает их вылавливать функциями типа mustbe?

foo(myVa) {
mustbe(myVar, string)
. . .
}

Так короче будет:

foo(string myVar) {
. . .
}

>>1949
>Ни один статически типизированный язык не умеет так . . .

// Java
Object helloWorld(String arg) {
switch(arg) {
case "Hello": return "World";
case "Bye": return "bye-bye";
default: return false;
}
}

>>2104
>А написание тестов, так-то, занимает времени поболее, чем написание функционала.
Разве. Раз-два в REPL потестил, и заебись

>>2106
>>Ни один статически типизированный язык не умеет так . . .
Да, поторопился. Это походу только Nim такой инвалид.

>>1949
>Ни один статически типизированный язык не умеет так:
Лол.

string HelloWorld(string arg, out bool Status)
{
Status = true; // def
switch (arg)
{
case "Hello": return "World";
case "Bye": return "bye-bye";
default:
Status = false;
return String.Empty;
}
}

>>2222
>раз-два в REPL потестил, и заебись
Подходит только для маленьких кусков кода. В крупных пректах надо еще монструозное окружение поднимать и приводить его в нужное состояние.