Pull to refresh

Comments 43

UFO just landed and posted this here

В вашей цитате описано отличие (которое и ежу понятно в чем заключается), но таки не написано зачем оно в JavaScript.
Я не то, чтобы похливарить собрался, просто в статье с названием "Зачем использовать статические типы в JavaScript?" хотелось бы увидеть это "зачем".

UFO just landed and posted this here

Это был просто комментарий о несоответствии заголовка и самой статьи, если еще не поняли. Ну и насчет "проще программировать" — существуют и иные точки зрения, причем также вполне обоснованные.

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

Иметь эту информацию можно и не прибегая к использованию Flow или TS. И еще раз хочу уточнить: я тут не защищаю какую-то конкретную позицию относительно подхода к типизации или инструментов для работы с типами (позиция у меня есть, но, повторюсь, не хочу холиварить). Почему это не понятно после уже двух уточняющих комментов — для меня загадка.

Каким образом? Мне тоже было бы интересно убрать стадию транспиляции из джаваскрипта.


Я знаю единственный вариант — это использование JSDoc комментариев, однако их функционал — это 1% от функционала Тайпскрипта (насчет Флоу не знаю). Плюс JSDoc не дружит с ES6+.

UFO just landed and posted this here

На самом деле это удобно.
Я очень долго скептически относился к белкам-истеричкам из лагеря Java и ей подобных (потому что там это действительно ужасно), но по факту с современными инструментами очень удобно писать (и читать чужой) явно типизированный JS.

Вангую второе рождение венгерской нотации.

Как раз венгерская нотация — самая вредная и бесполезная хрень в этом деле. Кое-где можно встретить JS с ней, это ужасно.

Венгерская нотация сильно затрудняет читаемость кода, однако, если "ужасные" классические односимвольные префиксы заменить на постфиксы-сокращения (типа Arr, Str, Num), и использовать их только там, где необходимо сделать акцент на типе — вполне рабочая штука.

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

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

Я назвал их же. Мне ещё в ту эпоху попадалась статья самого Шимоньи о том, что мелкомягкие извратили саму суть и теперь трудно донести до рядовых программистов, что задумывалось оно не для того.

если вся эта метадата существует в виде суффиксов и постфиксов — так оно как-то логичнее и ближе к естественному человеческому языку.

Венгерский — не человеческий? :)

А по сути — я с Вами скорее согласен, чем нет. В конце концов это частный случай lowerCamelCase.

Не совсем правильно называть это "статическими типами", это скорее аннотации типов. Статическая типизация гарантирует (ну или пытается) отсутствие ошибок типов в рантайме. Ни флоу, ни тайпскрипт этого не гарантируют.

UFO just landed and posted this here
Увы это все просто красивая обертка… Пишу на TS сейчас очень много, проверял затранспайленый код в JS, и я Вам скажу что ничего не поменяется. А если еще и под капот заглянуть то максимум который вы увидите это преобразование ваших переменных в типизированные, скажем `toUint32` и так далее. Но гарантии никакой.

В статье и говорится, что это compile-time проверка, а не run-time.

ну так и не надо тогда подносить это как «Новую эру в Javascript» и «Строготипизированный Javascript». Претензия не к автору статьи конкретно, но и к майкрософту тоже, которые позиционируют этот TypeScript как строгую типизацию в js, которой никогда нет и не было. Строгая типизация там бы была если бы после каждого присваивания там проверялось какому типу данных принадлежит значение. Вся ваша типизация ломается ровно тогда когда вы начинаете колбэки использовать. А колбэки это очень большая часть кода. А решается эта типизация простым человеческим наименованием переменных. Накипело уже с этой типизацией.
Вся ваша типизация ломается ровно тогда когда вы начинаете колбэки использовать

Видно, что вы даже не пробовали.


А решается эта типизация простым человеческим наименованием переменных.

Почитайте что Спольски пишет про венгерскую нотацию.

>Видно, что вы даже не пробовали.
ну так поправьте меня. Да, я даже не стал смотреть на документацию после того как я посмотрел в песочнице во что он преобразует код.
document.addEventListener('DOMContentLoaded', this.contentLoadedHandler);

Разве TypeScript сможет на этапе компиляции проверить что придет в аргументах функции «contentLoadedHandler»? Я ведь туда ничего явно не передаю.

Для этого существуют .d.ts файлы, которые описывают сигнатуры библиотечных классов/методов.


Допустим, вот описание для document.addEventListener.
Здесь утверждается, что сигнатура коллбэка будет EventListenerOrEventListenerObject, который в свою очередь ссылается на EventListener:


interface EventListener {
    (evt: Event): void;
}

Отсюда видно, что придет в аргументах функции: это объект типа Event

Вы не подходящий пример привели, у вас IDE как раз проверит типы и выдаст ошибку если нужно.
Вот скрин http://take.ms/pIYE4.
UFO just landed and posted this here

Идея внедрить Web Assembly кажется более удачной

Возможно) Мой комментарий относился конкретно к статической типизации и всему такому.

Ну так с web assembly можно (теоретически) использовать любой язык компилируемый для llvm, со строгой типизацией или без.

AS3, Haxe и TypeScript основаны на EcmaScript-262 4 edition.
JS сообщество его отклонила, как «очень сложное» и ушло в какую-то неведомую даль)
Вопрос, а почему именно на JS понадобилась типизация?

Ruby, Python — нет статической типизации. Все пишут и вроде никто не топит за нее.
И IDE для этих языков есть и работают они хорошо.

PS пробовал и кофескрипт и тайпскрипт — не пошло.
привет вам из мира питона — http://mypy-lang.org/
возможность compile-time проверки типов с помощью аннотаций, поддерживаемых языком — один из больших плюсов третьей версии.
О mypy в курсе. Только вот основные фреймворки написаны таки на питоне. И никто не прибегал в них к типизации. Откройте код Торнадо, Джанго или Фласка. И использование этих фреймворков не заставляет типизировать код.

PS если я где ошибся, приведите линк. Так как больше полутора лет уже не пишу на питоне.
основные используемые сейчас фреймворки написаны сильно раньше принятия PEP-484 (он вышел лишь с питоном 3.5), так что отсутствие в них type hinting вполне понятно.

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

Естественно это лишь мой личный опыт, но даже он показывает что своя аудитория у этой фичи есть, как и TypeScript в js (к слову на последнем месте работы большой фронтендовый проект как раз на TypeScript переводили и в целом остались довольны).
s/ читаемость кода/ улучшает читаемость кода/

Также, не совсем понимаю пассаж про «основные фреймворки написаны таки на питоне» — mypy это лишь статический анализатор, который работает с тайп хинтами python 3.5, это не отдельный интерпретатор. Вы можете встроить его в свой CI пайплайн, как тот же flake8 и он будет
UFO just landed and posted this here
Пишу на Java (middle). Пишу на JS (senior). Проблем в JS с нехваткой типов не испытываю. Не могу принять это как аргумент.
UFO just landed and posted this here

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


WebAssembly — не панацея, поскольку неспособен работать с DOM, так что писать обвязку на JavaScript всё равно придётся.

Ссылки ведут на одну и туже статью — «Зачем использовать статические типы в JavaScript? (Преимущества и недостатки)»:
Части 2 и 3. Преимущества и недостатки статических типов (с детальным примерами).
Часть 4. Нужно ли использовать статические типы в JavaScript или нет?

Объедините их, чтобы не сбивать с толку, что что-то пропущено. Я долго искала часть 4, пока не прочла всё)
Или разбейте статью, как в оригинале.
Sign up to leave a comment.

Articles