Зачем нужна динамическая типизация?

#любой_язык #динамическая_типизация

Есть класс языков, где типизация динамическая, например JavaScript, VB и т д.

Мне как приверженцу строгой типизации не понятен сакральный смысл этого.

Ну да, вроде, прикольно на ходу строить класс в JavaScript. Однако, какой в этом
смысл? Ведь я могу здесь и сейчас все объявить и построить необходимые модели, ведь
я заранее должен знать с чем мне придется работать.

В T-SQL динамические запросы обоснованы, но опять же все сводится к конечному множеству
каких-нибудь фильтров фильтров.

По моему одни минусы:


IDE, как правило, не может во время запуска тут же выдать ошибки
Криво работает автоподстановка вариантов, так как переменная динамическая
Да и в голове нужно помнить, что вот эта переменная имеет такой-то тип, а тут она
поменяла тип на другой...

    

Ответы

Ответ 1

Дело в том, что отсутствие типов убивает сразу много зайцев. Главные - это читаемость
кода, и повышение простоты программирования в целом. Первое - это очень важно стратегически,
чтобы при большом объёме кода, долгой разработке проект по прежнему был читаем и расширяем,
второе - тактически - чтобы быстро решать задачи. Но приверженец строгой типизации
может не почувствовать этих плюсов на первых порах, например я сам перешёл когда-то
с C++ на JS и PHP - и наверное ещё год негодовал. Постараюсь объяснить..

Ресурсы мозга. Присутствие типов в коде создаёт дополнительную неслабую смысловую
нагрузку, и требует серьёзных мозговых затрат на запоминание иерархии, на чтение кода,
на то чтобы эти самые типы прописывать при каждом "чихе" в коде. В компилируемом коде
типы раньше несли за собой главный их смысл - максимальную скорость работы программы,
минимальный расход ОП. Для скриптовых языков такой цели как правило не стоит (да и
современные компиляторы уже не слишком много отъедают при отсутствии типов), и поэтому
решающие факторы типизации языка - именно восприятие типов мозгами программистов в
контексте задач скриптового языка.

Структурная сложность.  В скриптах делается упор на возможную сложность скрипта,
при высокой читаемости. И тут JS приуспел - читая любой JS-код можно увидеть, как уводится
внимание от объектно-типовой составляеющей, и фокусируется внимание на структурной
составляющей: вложенные замыкания, функциональное программирование, асинхронное программирование.
И были бы в JS типы - такого эффекта восприятия кода конечно бы не было. 

Читаемость. Если грамотно именовать, переменные в коде JS - то код будет читаться
как книга, несмотря на структурную сложность. Но когда к переменным добавляются типы
- читаемость сильно теряет: читающий программист получает много лишней информации.
Вот в быту мы говорим Убери яблоко в холодильник а не Убери красное круглое яблоко
в большой серебристый холодильник, так как первое проще воспринимается. Например, чтение
JS кода любой широко-распостраннённой библиотеки я бы сравнил с чтением стихов Пушкина,
тогда как чтение типизированного C++ кода с чтением Иллиады Гомера (теперь уже).

Про простоту программирования без типов. Выходит так, что без типов, и с развитыми
функциональными инструментами: половина паттернов не нужна, вторая половина паттернов
записывается в три строчки вместо 15-ти. Классическая реализация старых паттернов GoF
в типизированных языках сегодня больше похожа на костыли, которые просто есть, чтобы
компенсировать недостаток гибкости при наличии строгой типизации - соответственно они
нечитаемы, с ними надо серьёзнее разбираться, забивать себе голову вопросами "зачем
это?" "это фасад или адаптер?", и.т.п. В JS же появляются плюс к старым совсем другие
подходы, основанные на замыканиях, инкапсуляции, и ФП. При реализации одной-и-той же
задачи в стиле ООП-классики на TS, и в стиле ФП на JS, что выходит в итоге:  


Код на JS получается компактнее раза в 3, и читаемее, чем код со строгой типизацией
на том-же TS.  
Программист реализует задачу быстрее, пропорционально объёму кода.  


Плюс JS работает в основном с древовидной базой данных под названием DOM - и его
задача, это в основном управление этим DOM в динамике. То есть никаких серьёзных ООП
структур не требуется, встроенного хватает с лихвой: обработки DOM событий, асинхронных
возможностей JS. Это вкупе с отсутсвием типизации делает JS-код "квинтэссенцией управляющей
логики". "Простота программирования" - это не значит, что у программистов JS будет
халява, это значит что хороший программист успеет сделать в 3 раза больше.

Что теряет JS без типов?
Первое, что теряет JS - автоматическую валидацию входящих параметров функции - это
почти главная роль которую исполняют типы в современных скриптовых языках. Параметры
можно валидировать вручную в JS, но это делают крайне редко, разве что часто бывают
проверки на пустоту вида if (!param1) return false;. Почему не делают? Да потому что
JS проносит в себе стиль кода, в котором тип - это не главная характиристика переменной
- и программисты быстро это понимают.
Второе что теряет JS - отсутствие возможности строить классическую ООП архитектуру.
Нет, костылями и велосипедами конечно можно делать сильное подобие ООП - когда-то (далеко
до ES6) этим вопросом задались создатели mootools, и сегодня 90% программистов JS,
сталкивающихся с mootools считают его худшим фреймворком всех времён и народов) Почему?
Да потому что в JS богатейший функционал, в том числе касаемо инкапсуляции(так необходимой
для крупных проектов), множество способов делать "безопасные" для программы точки расширения,
множество "своих паттернов", ООП ему не не нужен, чтобы сделать качественную расширяемую
программу любого масштаба. Типизация, тем более строгая - есть локомотив "дедовского
ООП" - и соответственно угнетатель гибких способов построения программ.
Последнее - это при работе в IDE автокомплит и "переход к классу" работают плохо.
Это бывает, но если вы всё-таки решили писать ООП-подобный код в js, то воспользуйтесь
JSDoc , чтобы помочь IDE. В то-же время плохая навигация, это проблема самого IDE,
например PhpStorm( WebStorm ) - работает с навигацией в JS хорошо и без JSDoc, и обещает,
что скоро станет отлично.

Описал своими словами, как мог, но сложно объяснить множество плюсов отсутствия типов
программисту на строго-типизированных языках: это почти что донести буддисту, что христианство
это круто :) 

UPD но дабы не превращать ответ в злостный холивар, надо заметить - что типы тоже
полезны для той-же читаемости кода, например в аргументах функций. Но когда типы используются
иногда, а не в 100% кода. Но если разрешить в JS пусть только типы в аргументах (например
как в TS), программисты тут-же начнут злоупотреблять ООП, и убьют сформировавшуюся
стилистику языка, и вместе с этим все плюсы JS - думаю это причина идеологии типизации
EcmaScript. Бесполезна и даже вредна именно строгая типизация, но только если речь
не идёт о максимальной производительности: тогда нет вопросов, строгая типизация выйграет.


Ответ 2

Компактность кода, в основном. Допустим, у нас есть несколько классов, занимающих
совершенно разное место в иерархии наследования, но объединенных наличием общего метода
SaveToFile, принимающего один строковый аргумент (путь к файлу). Затем мы хотим написать
функцию, которая будет сохранять в файл все элементы из массива произвольных объектов.

На языке со статической типизацией нам нужно будет объявить интерфейс, пометить все
классы с методом SaveToFile как реализующие его, и использовать приведение типов:

interface ISaveable{
  void SaveToFile(string path);
}

void SaveAll(object[] array, string path){
    for(int i=0; i
Ответ 3

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


Цитата отсюда. Языки с динамической типизации нужны именно для того же: чтобы быстрей
получить работающий результат. 

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