Меня огорчает, когда люди критикуют языки, которые они не используют, и заявляют о преимуществах методологий, далеких от доказательной базы. Итак, представьте мое разочарование, когда я столкнулся с JS Johnny и попыткой сделать статическую строгую типизацию привлекательной.
Конечно, я не говорю, что статическая строгая типизация — это плохо — это всего лишь простая проверка во время компиляции, чтобы попытаться убедиться, что объект имеет те свойства, которые, по вашему мнению, у него есть. Похоже, что большинство сторонников такой типизации не понимают, что компилятор в основном способен решать эти проблемы во время компиляции без сложностей набора текста и вообще не улавливает проблемы времени выполнения. Да, действительно, мы все обнаружили, что используем неправильный тип при вызове функции. Я даже видел, как новичок искал правильный объект для передачи, пробуя альтернативы, пока проверщик типов не перестал жаловаться! Это довольно ясно показывает, что часто строгая типизация является временным препятствием для того, чтобы не писать документацию и не читать ее.
Я знаю, что это очень непопулярная идея, потому что строгая типизация уже давно стала образцом (вещью?) Для лучшего программирования. Что не очень хорошо понимается, так это то, что существует очень мало доказательств этой точки зрения. Те немногие исследования, которые есть, показывают, что если строгая типизация дает какой-либо эффект, то он невелик, и они не учитывают никаких недостатков. Ясно одно: если вы будете следовать этому конкретному подходу немного дальше, то в конечном итоге столкнетесь с множеством «интересных» проблем. Потратив так много времени на обеспечение строгой типизации, вы должны найти способы ослабить ее, чтобы вы могли писать алгоритмы без типов. Обычное решение — изобрести дженерики, с чем Go все еще борется, так сложно. После дженериков вам придется заняться дисперсией и рядом других интересных проблем, не говоря уже о наследовании, интерфейсах и так далее. От всех этих сложных и изощренных концепций можно отказаться, если вы просто осознаете, что, как и наследование на основе классов, строгая типизация легко заменяется другими механизмами.
Как я уже сказал, это непопулярная точка зрения, и я не ожидаю, что многие программисты, читающие это, согласятся со мной, но даже если вы этого не сделаете, в данном случае следует привести доводы.
Это видео атакует JavaScript из-за отсутствия строгой типизации, но приведенный в нем пример неверен. Фактически, понимание JavaScript и того, как он работает, должно вызывать у зрителя трепет, а не предполагаемое отвращение. Посмотрите видео, а затем прочтите мое объяснение того, что происходит.
Аргумент в том, что если JS Johnny напишет функцию:
функция parseText (текст) {предупреждение (текст);}
тогда у бедного sap нет способа гарантировать, что функция вызывается с текстовым объектом. Приведенный пример:
parseText (окно);
О нет, JS Johnny, ты прошел все ОКНО !!
Нет особого ужаса, и если вы попробуете это, вы обнаружите, что программа работает и, как знает любой компетентный программист JS, отображает некоторый текст, сгенерированный методом toString объекта. JavaScript преобразует объекты в значения в зависимости от требований — строковое или числовое значение. В этом случае передача любого объекта функции parseText вызывает метод toString, как только требуется текст — и вот как это работает, если объект является объектом String. Нет смысла в том, чтобы объект String отличался от любого другого объекта, а ограничение параметра как «текст» — это что-то из другого языка.
Что касается передачи окна функции — ну, JS Johnny должен прочитать руководство и подумать, что делает parseText. Если действительно необходимо убедиться, что переданный объект является строковым, проверьте его как первую строку функции. Это защищает от ошибки во время выполнения, что гораздо важнее, чем проверка строгой типизации во время компиляции.
Да, с JavaScript что-то не так, но это не одна из них. Если вы собираетесь жаловаться на язык, узнайте, как он работает, прежде чем предположить, что это неудавшийся язык на основе классов, которому было лень вводить строгую типизацию. Это просто вводит в заблуждение новичков.
Ян Эллиот — автор книги «Просто JavaScript: идиоматический подход», в которой он радикально рассматривает JavaScript с учетом того, как он основан на объектах.