Что такое динамическая типизация? Типизация языков программирования Динамичная типизация.

Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp - бестиповым языком, а C - языком со строгой типизацией.

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

Рекомендую прочитать сначала краткую версию статьи, а затем при наличии желания и полную.

Краткая версия

Языки программирования по типизации принято делить на два больших лагеря - типизированные и нетипизированные (бестиповые). К первому например относятся C, Python, Scala, PHP и Lua, а ко второму - язык ассемблера, Forth и Brainfuck.

Так как "бестиповая типизация" по своей сути - проста как пробка, дальше она ни на какие другие виды не делится. А вот типизированные языки разделяются еще на несколько пересекающихся категорий:

• Статическая / динамическая типизация. Статическая определяется тем, что конечные типы переменных и функций устанавливаются на этапе компиляции. Т.е. уже компилятор на 100% уверен, какой тип где находится. В динамической типизации все типы выясняются уже во время выполнения программы.

  Примеры:
  Статическая: C, Java, C#;
  Динамическая: Python, JavaScript, Ruby.

• Сильная / слабая типизация (также иногда говорят строгая / нестрогая). Сильная типизация выделяется тем, что язык не позволяет смешивать в выражениях различные типы и не выполняет автоматические неявные преобразования, например нельзя вычесть из строки множество. Языки со слабой типизацией выполняют множество неявных преобразований автоматически, даже если может произойти потеря точности или преобразование неоднозначно.

  Примеры:
  Сильная: Java, Python, Haskell, Lisp;
  Слабая: C, JavaScript, Visual Basic, PHP.

• Явная / неявная типизация. Явно-типизированные языки отличаются тем, что тип новых переменных / функций / их аргументов нужно задавать явно. Соответственно языки с неявной типизацией перекладывают эту задачу на компилятор / интерпретатор.

  Примеры:
  Явная: C++, D, C#
  Неявная: PHP, Lua, JavaScript

Также нужно заметить, что все эти категории пересекаются, например язык C имеет статическую слабую явную типизацию, а язык Python - динамическую сильную неявную.

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

Подробная версия

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

Бестиповая типизация

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

Бестиповая типизация обычно присуща низкоуровневым (язык ассемблера, Forth) и эзотерическим (Brainfuck, HQ9, Piet) языкам. Однако и у нее, наряду с недостатками, есть некоторые преимущества.

Преимущества

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

Недостатки

• Сложность. Часто возникает необходимость в представлении комплексных значений, таких как списки, строки или структуры. С этим могут возникнуть неудобства.
• Отсутствие проверок. Любые бессмысленные действия, например вычитание указателя на массив из символа будут считаться совершенно нормальными, что чревато трудноуловимыми ошибками.
• Низкий уровень абстракции. Работа с любым сложным типом данных ничем не отличается от работы с числами, что конечно будет создавать много трудностей.

Сильная безтиповая типизация?

Да, такое существует. Например в языке ассемблера (для архитектуры х86/х86-64, других не знаю) нельзя ассемблировать программу, если вы попытаетесь загрузить в регистр cx (16 бит) данные из регистра rax (64 бита).

mov cx, eax ; ошибка времени ассемблирования

Так получается, что в ассемлере все-таки есть типизация? Я считаю, что этих проверок недостаточно. А Ваше мнение, конечно, зависит только от Вас.

Статическая и динамическая типизации

Главное, что отличает статическую (static) типизацию от динамической (dynamic) то, что все проверки типов выполняются на этапе компиляции, а не этапе выполнения.

Некоторым людям может показаться, что статическая типизация слишком ограничена (на самом деле так и есть, но от этого давно избавились с помощью некоторых методик). Некоторым же, что динамически типизированные языки - это игра с огнем, но какие же черты их выделяют? Неужели оба вида имеют шансы на существование? Если нет, то почему много как статически, так и динамически типизированных языков?

Давайте разберемся.

Преимущества статической типизации

• Проверки типов происходят только один раз - на этапе компиляции. А это значит, что нам не нужно будет постоянно выяснять, не пытаемся ли мы поделить число на строку (и либо выдать ошибку, либо осуществить преобразование).
• Скорость выполнения. Из предыдущего пункта ясно, что статически типизированные языки практически всегда быстрее динамически типизированных.
• При некоторых дополнительных условиях, позволяет обнаруживать потенциальные ошибки уже на этапе компиляции.

Преимущества динамической типизации

• Простота создания универсальных коллекций - куч всего и вся (редко возникает такая необходимость, но когда возникает динамическая типизация выручит).
• Удобство описания обобщенных алгоритмов (например сортировка массива, которая будет работать не только на списке целых чисел, но и на списке вещественных и даже на списке строк).
• Легкость в освоении - языки с динамической типизацией обычно очень хороши для того, чтобы начать программировать.

Обобщенное программирование

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

Как же мы будем ее решать? Решим ее на 3-ех разных языках: одном с динамической типизацией и двух со статической.

Алгоритм поиска я возьму один из простейших - перебор. Функция будет получать искомый элемент, сам массив (или список) и возвращать индекс элемента, или, если элемент не найден - (-1).

Динамическое решение (Python):

Def find(required_element, list): for (index, element) in enumerate(list): if element == required_element: return index return (-1)

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

Статическое решение (Си):

Unsigned int find_int(int required_element, int array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_float(float required_element, float array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); } unsigned int find_char(char required_element, char array, unsigned int size) { for (unsigned int i = 0; i < size; ++i) if (required_element == array[i]) return i; return (-1); }

Ну, каждая функция в отдельности похожа на версию из Python, но почему их три? Неужели статическое программирование проиграло?

И да, и нет. Есть несколько методик программирования, одну из которых мы сейчас рассмотрим. Она называется обобщенное программирование и язык C++ ее неплохо поддерживает. Давайте посмотрим на новую версию:

Статическое решение (обобщенное программирование, C++):

Template unsigned int find(T required_element, std::vector array) { for (unsigned int i = 0; i < array.size(); ++i) if (required_element == array[i]) return i; return (-1); }

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

Эта версия похоже именно то, что нужно - мы получаем одновременно плюсы статической типизации и некоторые плюсы динамической.

Здорово, что это вообще возможно, но может быть еще лучше. Во-первых обобщенное программирование может быть удобнее и красивее (например в языке Haskell). Во-вторых помимо обобщенного программирования также можно применить полиморфизм (результат будет хуже), перегрузку функций (аналогично) или макросы.

Статика в динамике

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

• C# поддерживает псевдо-тип dynamic.
• F# поддерживает синтаксический сахар в виде оператора?, на базе чего может быть реализована имитация динамической типизации.
• Haskell - динамическая типизация обеспечивается модулем Data.Dynamic.
• Delphi - посредством специального типа Variant.

Также, некоторые динамически типизированные языки позволяют воспользоваться преимуществами статической типизации:

• Common Lisp - декларации типов.
• Perl - с версии 5.6, довольно ограниченно.

Сильная и слабая типизации

Языки с сильной типизацией не позволяют смешивать сущности разных типов в выражениях и не выполняют никаких автоматических преобразований. Также их называют "языки с строгой типизацией". Английский термин для этого - strong typing.

Слабо типизированные языки, наоборот всячески способствуют, чтобы программист смешивал разные типы в одном выражении, причем компилятор сам приведет все к единому типу. Также их называют "языки с нестрогой типизацией". Английский термин для этого - weak typing.

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

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

Язык при этом должен иметь еще и сильную типизацию. И правда, если компилятор вместо сообщения об ошибке будет просто прибавлять строку к числу, или что еще хуже, вычтет из одного массива другой, какой нам толк, что все "проверки" типов будут на этапе компиляции? Правильно - слабая статическая типизация еще хуже, чем сильная динамическая! (Ну, это мое мнение)

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

Хотите узнать какие?

Преимущества сильной типизации

• Надежность - Вы получите исключение или ошибку компиляции, взамен неправильного поведения.
• Скорость - вместо скрытых преобразований, которые могут быть довольно затратными, с сильной типизацией необходимо писать их явно, что заставляет программиста как минимум знать, что этот участок кода может быть медленным.
• Понимание работы программы - опять-же, вместо неявного приведения типов, программист пишет все сам, а значит примерно понимает, что сравнение строки и числа происходит не само-собой и не по-волшебству.
• Определенность - когда вы пишете преобразования вручную вы точно знаете, что вы преобразуете и во что. Также вы всегда будете понимать, что такие преобразования могут привести к потере точности и к неверным результатам.

Преимущества слабой типизации

• Удобство использования смешанных выражений (например из целых и вещественных чисел).
• Абстрагирование от типизации и сосредоточение на задаче.
• Краткость записи.

Ладно, мы разобрались, оказывается у слабой типизации тоже есть преимущества! А есть ли способы перенести плюсы слабой типизации в сильную?

Оказывается есть и даже два.

Неявное приведение типов, в однозначных ситуациях и без потерь данных

Ух… Довольно длинный пункт. Давайте я буду дальше сокращать его до "ограниченное неявное преобразование" Так что же значит однозначная ситуация и потери данных?

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

Потеря данных это еще проще. Если мы преобразуем вещественное число 3.5 в целое - мы потеряем часть данных (на самом деле эта операция еще и неоднозначная - как будет производиться округление? В большую сторону? В меньшую? Отбрасывание дробной части?).

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

Если вы мне не верите, изучите язык PL/I или даже просто поищите его спецификацию. В нем есть правила преобразования между ВСЕМИ типами данных! Это просто ад!

Ладно, давайте вспомним про ограниченное неявное преобразование. Есть ли такие языки? Да, например в Pascal Вы можете преобразовать целое число в вещественное, но не наоборот. Также похожие механизмы есть в C#, Groovy и Common Lisp.

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

Я поясню его на примере замечательного языка Haskell.

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

Например в выражении pi + 1 , не хочется писать pi + 1.0 или pi + float(1) . Хочется написать просто pi + 1 !

И это сделано в Haskell, благодаря тому, что у литерала 1 нет конкретного типа. Это ни целое, ни вещественное, ни комплексное. Это же просто число!

В итоге при написании простой функции sum x y , перемножающей все числа от x до y (с инкрементом в 1), мы получаем сразу несколько версий - sum для целых, sum для вещественных, sum для рациональных, sum для комплексных чисел и даже sum для всех тех числовых типов что Вы сами определили.

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

Таким образом можно сказать, что лучшим выходом будет балансирование на грани, между сильной и слабой типизацией. Но пока идеальный баланс не держит ни один язык, поэтому я больше склоняюсь к сильно типизированным языкам (таким как Haskell, Java, C#, Python), а не к слабо типизированным (таким как C, JavaScript, Lua, PHP).

Явная и неявная типизации

Язык с явной типизацией предполагает, что программист должен указывать типы всех переменных и функций, которые объявляет. Английский термин для этого - explicit typing.

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

По-началу можно решить, что неявная типизация равносильна динамической, а явная - статической, но дальше мы увидим, что это не так.

Есть ли плюсы у каждого вида, и опять же, есть ли их комбинации и есть ли языки с поддержкой обоих методов?

Преимущества явной типизации

• Наличие у каждой функции сигнатуры (например int add(int, int)) позволяет без проблем определить, что функция делает.
• Программист сразу записывает, какого типа значения могут храниться в конкретной переменной, что снимает необходимость запоминать это.

Преимущества неявной типизации

• Сокращение записи - def add(x, y) явно короче, чем int add(int x, int y) .
• Устойчивость к изменениям. Например если в функции временная переменная была того-же типа, что и входной аргумент, то в явно типизированном языке при изменении типа входного аргумента нужно будет изменить еще и тип временной переменной.

Хорошо, видно, что оба подхода имеют как плюсы так и минусы (а кто ожидал чего-го еще?), так давайте поищем способы комбинирования этих двух подходов!

Явная типизация по-выбору

Есть языки, с неявной типизацией по-умолчанию и возможностью указать тип значений при необходимости. Настоящий тип выражения транслятор выведет автоматически. Один из таких языков - Haskell, давайте я приведу простой пример, для наглядности:

Без явного указания типа add (x, y) = x + y -- Явное указание типа add:: (Integer, Integer) -> Integer add (x, y) = x + y

Примечание: я намерено использовал некаррированную функцию, а также намерено записал частную сигнатуру вместо более общей add:: (Num a) -> a -> a -> a , т.к. хотел показать идею, без объяснения синтаксиса Haskell"а.

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

Однако автоматический вывод типов довольно сложная вещь, и даже в таком крутом языке как Haskell, он иногда не справляется. (как пример можно привести ограничение мономорфизма)

Есть ли языки с явной типизацией по-умолчанию и неявной по-необходимости? Кон
ечно.

Неявная типизация по-выбору

В новом стандарте языка C++, названном C++11 (ранее назывался C++0x), было введено ключевое слово auto, благодаря которому можно заставить компилятор вывести тип, исходя из контекста:

Давайте сравним: // Ручное указание типа unsigned int a = 5; unsigned int b = a + 3; // Автоматический вывод типа unsigned int a = 5; auto b = a + 3;

Неплохо. Но запись сократилась не сильно. Давайте посмотрим пример с итераторами (если не понимаете, не бойтесь, главное заметьте, что запись благодаря автоматическому выводу очень сильно сокращается):

// Ручное указание типа std::vector vec = randomVector(30); for (std::vector::const_iterator it = vec.cbegin(); ...) { ... } // Автоматический вывод типа auto vec = randomVector(30); for (auto it = vec.cbegin(); ...) { ... }

Ух ты! Вот это сокращение. Ладно, но можно ли сделать что-нибудь в духе Haskell, где тип возвращаемого значения будет зависеть от типов аргументов?

И опять ответ да, благодаря ключевому слову decltype в комбинации с auto:

// Ручное указание типа int divide(int x, int y) { ... } // Автоматический вывод типа auto divide(int x, int y) -> decltype(x / y) { ... }

Может показаться, что эта форма записи не сильно хороша, но в комбинации с обобщенным программированием (templates / generics) неявная типизация или автоматический вывод типов творят чудеса.

Некоторые языки программирования по данной классификации

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

JavaScript - Динамическая / Слабая / Неявная Ruby - Динамическая / Сильная / Неявная Python - Динамическая / Сильная / Неявная Java - Статическая / Сильная / Явная PHP - Динамическая / Слабая / Неявная C - Статическая / Слабая / Явная C++ - Статическая / Полусильная / Явная Perl - Динамическая / Слабая / Неявная Objective-C - Статическая / Слабая / Явная C# - Статическая / Сильная / Явная Haskell - Статическая / Сильная / Неявная Common Lisp - Динамическая / Сильная / Неявная

Возможно я где-то ошибся, особенно с CL, PHP и Obj-C, если по какому-то языку у Вас другое мнение - напишите в комментариях.

Заключение

Окей. Уже скоро будет светло и я чувствую, что про типизацию больше нечего сказать. Ой как? Тема бездонная? Очень много осталось недосказано? Прошу в комментарии, поделитесь полезной информацией.

Когда вы изучаете языки программирования, то в разговорах часто слышите фразы наподобие “статически типизированный” или “динамически типизированный”. Эти понятия описывают процесс проверки соответствия типов, и как статическая проверка типов, так и динамическая, относятся к разным системам типов. Система типов - это набор правил, которые присваивают свойство, называющееся “тип”, различным сущностям в программе: переменным, выражениям, функциям или модулями - с конечной целью уменьшения количества ошибок путём подтверждения того, что данные отображаются корректно.

Не волнуйтесь, я знаю, что это всё звучит запутанно, поэтому мы начнём с основ. Что такое “проверка соответствия типов” и что такое вообще тип?

Тип

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

Типичные заблуждения

Миф 1: статическая / динамическая типизация == сильная / слабая типизация

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

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

X = 1 + "2"

Мы часто ассоциируем статически типизированные языки, такие как Java и C#, с сильно типизированным (они такими и являются), поскольку тип данных задаётся явно при инициализации переменной - как в этом примере на Java:

String foo = new String("hello world");

Тем не менее, Ruby, Python и JavaScript (все они обладaют динамической типизацией) также являются сильно типизированными, хотя разработчику и не нужно указывать тип переменной при объявлении. Рассмотрим такой же пример, но написанный на Ruby:

Foo = "hello world"

Оба языка являются сильно типизированными, но используют разные методы проверки типов. Такие языки, как Ruby, Python и JavaScript не требуют явного определения типов из-за вывода типов - способности программно выводить нужный тип переменной в зависимости от её значения. Вывод типов - это отдельное свойство языка, и не относится к системам типов.

Слабо типизированный язык - это язык, в котором переменные не привязаны к конкретному типу данных; у них всё ещё есть тип, но ограничения типобезопасности гораздо слабее. Рассмотрим следующий пример кода на PHP:

$foo = "x"; $foo = $foo + 2; // not an error echo $foo; // 2

Поскольку PHP обладает слабой типизацией, ошибки в этом коде нет. Аналогично предыдущему предположению, не все слабо типизированные языки являются динамически типизированными: PHP - это динамически типизированный язык, но вот C - тоже язык со слабой типизацией - воистину статически типизирован.

Миф разрушен.

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

Миф 2: статическая / динамическая типизация == компилируемые / интерпретируемые языки

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

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

Если это всё ещё непонятно, советую прочесть этого цикла.

Заключение

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

Нет однозначного ответа на вопрос “какая типизация лучше?” - у каждой есть свои преимущества и недостатки. Некоторые языки - такие как Perl и C# - даже позволяют вам самостоятельно выбирать между статической и динамической системами проверки типов. Понимание этих систем позволит вам лучше понять природу возникающих ошибок, а также упростит борьбу с ними.

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

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

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

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

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

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

Плюс 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. Бесполезна и даже вредна именно строгая типизация, но только если речь не идёт о максимальной производительности: тогда нет вопросов, строгая типизация выйграет.

• Динами́ческая типиза́ция - приём, широко используемый в языках программирования и языках спецификации, при котором переменная связывается с типом в момент присваивания значения, а не в момент объявления переменной. Таким образом, в различных участках программы одна и та же переменная может принимать значения разных типов. Примеры языков с динамической типизацией - Smalltalk, Python, Objective-C, Ruby, PHP, Perl, JavaScript, Lisp, xBase, Erlang, Visual Basic.

  Противоположный приём - статическая типизация.

  В некоторых языках со слабой динамической типизацией стоит проблема сравнения величин, так, например, PHP имеет операции сравнения «==», «!=» и «===», «!==», где вторая пара операций сравнивает и значения, и типы переменных. Операция «===» даёт true только при полном совпадении, в отличие от «==», который считает верным такое выражение: (1=="1"). Стоит отметить, что это проблема не динамической типизации в целом, а конкретных языков программирования.

Связанные понятия

Язык программи́рования - формальный язык, предназначенный для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, определяющих внешний вид программы и действия, которые выполнит исполнитель (обычно - ЭВМ) под её управлением.

Синтаксический сахар (англ. syntactic sugar) в языке программирования - это синтаксические возможности, применение которых не влияет на поведение программы, но делает использование языка более удобным для человека.

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

Расширенная форма Бэкуса - Наура (расширенная Бэкус - Наурова форма (РБНФ)) (англ. Extended Backus–Naur Form (EBNF)) - формальная система определения синтаксиса, в которой одни синтаксические категории последовательно определяются через другие. Используется для описания контекстно-свободных формальных грамматик. Предложена Никлаусом Виртом. Является расширенной переработкой форм Бэкуса - Наура, отличается от БНФ более «ёмкими» конструкциями, позволяющими при той же выразительной способности упростить...

Аппликативное программирование - один из видов декларативного программирования, в котором написание программы состоит в систематическом осуществлении применения одного объекта к другому. Результатом такого применения вновь является объект, который может участвовать в применениях как в роли функции, так и в роли аргумента и так далее. Это делает запись программы математически ясной. Тот факт, что функция обозначается выражением, свидетельствует о возможности использования значений-функций - функциональных...

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

Переме́нная - атрибут физической или абстрактной системы, который может изменять своё, как правило численное, значение. Понятие переменной широко используется в таких областях как математика, естественные науки, техника и программирование. Примерами переменных могут служить: температура воздуха, параметр функции и многое другое.

Синтакси́ческий ана́лиз (или разбор, жарг. па́рсинг ← англ. parsing) в лингвистике и информатике - процесс сопоставления линейной последовательности лексем (слов, токенов) естественного или формального языка с его формальной грамматикой. Результатом обычно является дерево разбора (синтаксическое дерево). Обычно применяется совместно с лексическим анализом.

Обобщённый алгебраический тип да́нных (англ. generalized algebraic data type, GADT) - один из видов алгебраических типов данных, который характеризуется тем, что его конструкторы могут возвращать значения не своего типа, связанного с ним. Сконструированы под влиянием работ об индуктивных семействах в среде исследователей зависимых типов.

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

Объе́ктно-ориенти́рованное программи́рование (ООП) - методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.

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

Типизация - назначения типа информационным сущностям.

Наиболее распространённые примитивные типы данных:

• Числовой
• Символьный
• Логический

Основные функции системы типов данных:

• Обеспечение безопасности
  Проверяется каждая операция на получение аргументов именно тех типов, для которых она имеет предназначена;
• Оптимизация
  На основе типа выбирается способ эффективного хранения и алгоритмов его обработки;
• Документация
  Подчеркивается намерения программиста;
• Абстракция
  Использование типов данных высокого уровня позволяет программисту думать о значениях как о высокоуровневых сущностях, а не как о наборе битов.

Классификация

Есть множество классификаций типизаций языков программирования, но основные только 3:

Статическая / динамическая типизация

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

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

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

Динамическая типизация

Var luckyNumber = 777; var siteName = "Tyapk"; // подразумеваем число, записываем строку var wrongNumber = "999";

Статическая типизация

Let luckyNumber: number = 777; let siteName: string = "Tyapk"; // вызовет ошибку let wrongNumber: number = "999";

• Статическая: Java, C#, TypeScript.
• Динамическая: Python, Ruby, JavaScript.

Явная / неявная типизация.

Явно-типизированные языки отличаются тем, что тип новых переменных / функций / их аргументов нужно задавать явно. Соответственно языки с неявной типизацией перекладывают эту задачу на компилятор / интерпретатор. Явная типизация является противоположностью неявной типизации.

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

Неявная типизация

Let stringVar = "777" + 99; // получим "77799"

Явная типизация (вымышленный язык похожий на JS)

Let wrongStringVar = "777" + 99; // вызовет ошибку let stringVar = "777" + String(99); // получим "77799"

Строгая / нестрогая типизация

Также называется сильная / слабая типизация. При строгой типизации типы назначаются «раз и навсегда», при нестрогой могут изменяться в процессе выполнения программы.

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

Строгая типизация (вымышленный язык похожий на JS)

Let wrongNumber = 777; wrongNumber = wrongNumber + "99"; // получим ошибку, что к числовой переменной wrongNumber прибавляется строка let trueNumber = 777 + Number("99"); // получим 876

Нестрогая типизация (как есть в js)

Let wrongNumber = 777; wrongNumber = wrongNumber + "99"; // получили строку "77799"

• Строгая: Java, Python, Haskell, Lisp.
• Нестрогая: C, JavaScript, Visual Basic, PHP.