nis> В Хаскеле для обобщения требуется наоборот сократить спецификации и упростить код. Я написал "иногда". В общем случае, нужны более серьёзные телодвижения. Хотя к спецификации типов они имеют весьма опосредованное отношение. nis> В "скриптовых" языках все не только умудряются жить "без типов", но и даже находят в этом определенные преимущества. Здесь следует различать. Есть языки со слабой типизацией - например, Perl. Там вполне можно написать 2+"three" и получить более-менее осмысленный результат. ИМХО, такой подход имеет право на существование, если мы пишем очень маленькие скрипты для выполнения небольших задач. Пожалуй, единственное значимое исключение здесь (из известных мне) - Tcl, пригодный для относительно крупных вещей, благодаря некоей объединяющей идее ("всё есть строка"). На самом деле, там с типами тоже не всё так просто, и перловской мешанины там нет. А есть языки с сильной, но динамической типизацией. Где рассогласование типов вызывает ошибку времени ИСПОЛНЕНИЯ. И вот здесь появляются наиболее мощные вещи - Lisp, SmallTalk, JavaScript (ох... вынужден я сейчас писать на некоем диалекте жабаскрипта - тех, кто его (диалект) придумывал, убить мало; надо ж так кастрировать замечательный язык). Вот они, как раз, пригодны для очень серьёзных проектов. Я бы сказал так. Языки со статической сильной типизацией (тот же Haskell, например; C++ к ним не относится, там типизация слабая) хороши тогда, когда мы совершенно чётко представляем себе, что мы пишем. Если же проект предполагает некое исследование возможностей, если могут случиться очень серьёзные изменения дизайна - нужен язык с динамической сильной типизацией. Языки же со слабой типизацией нужны для маленьких вещей, где можно обойтись без дизайна вообще и сделать нужную программу на интуиции. nis> Вы имеете ввиду такой пример? Скажем в стеке вызовов функций все функции принимают произвольный тип, но несуществующий интерфейс требует скажем только самая нижняя (самая внутренняя) функция. В этом случае компилятор выдаст ошибку во внутренней функции и стек вызовов придется отслеживать самому. А в случае явной спецификации компилятор укажет на ошибку сразу на самом верху? Да, например, вполне возможный сценарий. Именно поэтому в Лиспе, например, предусмотрено объявление типов переменных (хотя и является необязательным).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Re: Type inference как преимущество языка
17/10/06 05:02 (UTC)Я написал "иногда". В общем случае, нужны более серьёзные телодвижения. Хотя к спецификации типов они имеют весьма опосредованное отношение.
nis> В "скриптовых" языках все не только умудряются жить "без типов", но и даже находят в этом определенные преимущества.
Здесь следует различать. Есть языки со слабой типизацией - например, Perl. Там вполне можно написать 2+"three" и получить более-менее осмысленный результат. ИМХО, такой подход имеет право на существование, если мы пишем очень маленькие скрипты для выполнения небольших задач. Пожалуй, единственное значимое исключение здесь (из известных мне) - Tcl, пригодный для относительно крупных вещей, благодаря некоей объединяющей идее ("всё есть строка"). На самом деле, там с типами тоже не всё так просто, и перловской мешанины там нет.
А есть языки с сильной, но динамической типизацией. Где рассогласование типов вызывает ошибку времени ИСПОЛНЕНИЯ. И вот здесь появляются наиболее мощные вещи - Lisp, SmallTalk, JavaScript (ох... вынужден я сейчас писать на некоем диалекте жабаскрипта - тех, кто его (диалект) придумывал, убить мало; надо ж так кастрировать замечательный язык). Вот они, как раз, пригодны для очень серьёзных проектов.
Я бы сказал так. Языки со статической сильной типизацией (тот же Haskell, например; C++ к ним не относится, там типизация слабая) хороши тогда, когда мы совершенно чётко представляем себе, что мы пишем. Если же проект предполагает некое исследование возможностей, если могут случиться очень серьёзные изменения дизайна - нужен язык с динамической сильной типизацией. Языки же со слабой типизацией нужны для маленьких вещей, где можно обойтись без дизайна вообще и сделать нужную программу на интуиции.
nis> Вы имеете ввиду такой пример? Скажем в стеке вызовов функций все функции принимают произвольный тип, но несуществующий интерфейс требует скажем только самая нижняя (самая внутренняя) функция. В этом случае компилятор выдаст ошибку во внутренней функции и стек вызовов придется отслеживать самому. А в случае явной спецификации компилятор укажет на ошибку сразу на самом верху?
Да, например, вполне возможный сценарий. Именно поэтому в Лиспе, например, предусмотрено объявление типов переменных (хотя и является необязательным).