JavaScript и динамическая типизация #тред
Если предпосылки слабой типизации в JavaScript были туманны, то решение сделать JavaScript динамическим языком было изначально. Это решение вдохновлено Self, Scheme и испытало на себе влияние Java, C.
Подробнее об этом:
JavaScript: The First 20 Years. dl.acm.org/doi/pdf/10.114…
Тяжело дать однозначное трактование динамической типизации, но можно через сравнение со статической. Переменные связываются с типов в момент объявления переменной - статическая типизация, при присваивании значения - динамическая типизация.
Говоря другими словами при динамической типизации у переменной нет типа, тип есть у значения этой переменной. Изменив значение переменной мы изменим ее тип.
Может наивно показаться, (я как-то попался на этом), что компилируемые языки это как правило статически типизированные, но это не так, пример тому язык Julia, julialang.org
У NodeJS (libuv + v8 - JS движок) есть возможность экспортировать созданный байт код при запуске скрипта. Не знаю можно ли встроенными средствами его снова запустить, но +1 один камень преткновения, чтобы поставить = м/у компилируемые и статическими ЯП
medium.com/dailyjs/unders…
Динамическая типизация не заставляет думать разработчика о типах? И да и нет
Думают:
Опытные разработчики использующие динамически типизированные ЯП, документируют типы в сигнатурах функций. Явно имеют желание "статических типов".
В JavaScript - JSDoc jsdoc.app
JSDoc даже думали ввести на одних JavaScript курсах, чтобы подготовить морально/интеллектуально учащегося к статической типизации.
Минус динамической типизация, который также заставляет думать в сторону статической, это постоянная необходимость обладание контекстом о проекте, помнить что делает код. Приходится больше тратить времени, чтобы вкатиться в проект. Особенно с незнакомой доменной областью.
В своей книге "Типы в языках программирования" Бенджамин Пирс на первых страницах приводит доводы зачем нужны типы:
- Выявление ошибок
- Абстракция
- Документация
- Безопасность языков
- Эффективность
В JavaScript
- Выявление ошибок происходит в runtime
- ES6+ классы как какой-то способ описания абстракций в ЯП
- для документирования нужны как минимум сигнатуры функций, хотя бы на уровне JSDoc, а это сторонний инструмент
- эффективность - вопрос JS-движков, их обработки кода
Немного сравню JavaScript с TypeScript
Во втором после описания кода и запуска компилятор, тот начинает выводить типы (ru.wikipedia.org/wiki/Вывод_тип…), вывод типов гарантирует корректность программы.
Корректность во многом нас уберегла бы от ошибок типа undefined is not a function
Отсюда есть два разных по своей природе способа проверять корректность своих программ.
- покрывать код тестами:
для избежания runtime ошибок
- "покрывать код типами":
вывод типов сделает свою работу
На практике, конечно, лучше совмещать эти два подхода, не иначе
Про типы думают не только разработчики, которым без нее больно, но JavaScript-движки, например v8, который думает о типах постоянно.
В v8 есть такое понятие как hidden classes и inline cache. mathiasbynens.be/notes/shapes-i…
Грубо говоря объекты с одной структурой, являются один классом
Тоесть с точки зрения v8: чем больше будет объектов с одинаковой структурой, тем производительней будет код.
Если в гонке за производительность, оперироваться исключительно на этот факт и ни на какой больше, то напрашивается использование статической типизации как решения
Те, кто глядя на JavaScript не думают о типах внутри этого ЯП, это те люди, кто серьезно занимаются Computer Science: динамически типизированные ЯП, особенно JavaScript, наименее интересны.
Для меня это было показательно при изучении вопроса полиморфизма medium.com/devschacht/pol…
Есть ли у кого-нибудь банковский фронтенд без типов? pic.twitter.com/XuLLINssWM
Так ли плоха динамическая типизация?
eax.me/dynamic-typing/