Комментарии 72
PS При использовании лок файлов зависимостей сборка того же самого кода должна проходить успешно тк typescript компилятор остается тот же.
Имелось в виду, что если начать покрывать работающий код типами, то можно погрязнуть в куче разных несовпадений типов, которые пользователям никак не мешали, но компиляцию typescript ломают.
P.S. а что вы имели в виду под "скрипт кидди"? Я знаю только вот это определение и оно тут не при чем.
Имелось в виду, что если начать покрывать работающий код типами, то можно погрязнуть в куче разных несовпадений типов, которые пользователям никак не мешали, но компиляцию typescript ломают.Можно на этап перевода кода разрешить работать с JS файлами (опция allowJs) и так постепенно по файлу переводить на TS. Или что-то такое испольовать github.com/evolution-gaming/tsc-silent
P.S. а что вы имели в виду под «скрипт кидди»? Я знаю только вот это определение и оно тут не при чем.Могу перефразировать — код манки.
Теперь мы видимо задаем именно два int значения. Не два float или два string
number в javascript и typescript — именно, что float (если быть совсем точным, то double, если использовать сишные типы). В них нет int типа.
Возможно если писать так с нуля, то все будет шоколадно, но внедрять типизацию в большой и готовый проект — бе.
Это полный переписон проекта..
По крайней мере так было около года назад, после этого я TS не трогал.
Сейчас так же?
Однако он уязвим для многочисленных ошибок во время исполнения (рантайм)…Если в рантайме пришли неверные данные, типизация их не починит. У нее есть свой ограниченный диапазон полезности.
После получения списка данных вы обнаруживаете, что определенное поле не существует в одной из записей. Это приводит к сбою в работе приложения, если этот случай не отлавливается
Ваша IDE не знает, какие методы и свойства доступны для модулей и библиотекIDE плохо работает?
--------------------------------------------------------------------------------
Language Files Lines Blank Comment Code
--------------------------------------------------------------------------------
JSON 1 615299 0 0 615299
TypeScript 3587 662204 21297 150768 490139
HTML 16 1868 222 7 1639
JavaScript 7 1583 401 186 996
C 1 703 95 28 580
Plain Text 24 740 228 0 512
CSS 8 332 8 22 302
C/C++ Header 1 39 9 3 27
Bourne Shell 1 7 1 1 5
--------------------------------------------------------------------------------
Total 3646 1282775 22261 151015 1109499
--------------------------------------------------------------------------------Единственный Json кстати это набор данных для теста одной хреновины, так что да, объём кода завышен в мегабайтах.
А почему дизайн системы отсутствует при использовании голого JS?
Неужели использование TS автоматически привносит в проект хороший дизайн?
А куда девалась типизация в JS? Почему вы считаете что в JS нет интерфейсов?
В сыром JS дизайн если он изначально в каком-то виде существовал, то очень быстро обесценивается тк он не подкреплен компилятором.
То есть вы считаете что в интерпретируемых языках с динамической и утиной типизацией дизайн как понятие в принципе отсутствует?
Ну то есть к примеру возьмем мы и напишем программу на языке C, запустим компилятор и он ее откомпилирует успешно. Означает ли это автоматически наличие хорошего дизайна в компилируемой программе?
Что вы вообще подразумеваете под понятием дизайн, если предполагаете что компилятор способен обеспечить его наличие?
Почему вы считаете что в JS нет интерфейсов?Уже появились?
Ну то есть к примеру возьмем мы и напишем программу на языке C, запустим компилятор и он ее откомпилирует успешно. Означает ли это автоматически наличие хорошего дизайна в компилируемой программе?Это означает что сигнатуры и типы не поломаны.
Уже появились?
Никуда и не девались.
function FirstStringFactory() {
this.make = function() {
return "First";
};
}
function SecondStringFactory() {
this.make = function() {
return "Second";
};
}
function StringFactoryConsumer(stringFactory){
this.name = stringFactory.make();
}Это означает что сигнатуры и типы не поломаны.
Вы считаете что это основа дизайна?
Вы считаете что это основа дизайна?Неотемлемая часть.
Никуда и не девались.Это не интерфейсы но их реализация в виде абстрактных классов. TS позволяет описать StringFactoryConsumer и stringFactory без их реализации.
Вы считаете что это основа дизайна?
Неотемлемая часть.
Странный ответ. А что еще в процессе разработки имеет отношение к дизайну, ну кроме компилятора?
Это не интерфейсы но их реализация в виде абстрактных классов. TS позволяет описать StringFactoryConsumer и stringFactory без их реализации.
Почему абстрактных?
Flow для меня ассоциируется с болью. Работал на нем какое-то время, но элементарные вещи эта штука не понимает. Или я тупой. Вообще не люблю продукты фейсбука, много хайпа, мало пользы.
Как можно так тупить?
https://flow.org/try/#0MYewdgzgLgBAHjAvDAFGAXDMBXAtgIwFMAnGAHxmmIEswBzASkxwJKQD4YBvAKAEhQkWNQgA5PEVLIoATwAOhEADMsSRMgDkLSRv7UVKEeNbEG3fn2KEo2YmFUAqGAEYADPwC+-KzbswATO5ePDxwKM4MQA
Или вот так?
https://flow.org/try/#0NoRgNAdgrgNjYGYC6A6AZgSxgFwKYCcAKCAAgF4A+E7ATwAdcB7NE0s9kgcmgFsAjApwCUKHgEM6xclVIAqEiAAMQoA
не люблю продукты фейсбука, много хайпа, мало пользыПричины такого положения дел обсуждались на различных англоязчных сообществах. Основная как я понял состоит в политике повышений в должности и соответственно зарплате. Фейсбук поощряет запуск новых штуковин, это один из показателей проактивности влияющий на повышение. Но обнаружился лайфхак, можно просто запустить, развивать эти поделки и фиксить там баги не обязательно для получения повышения.
Если вам это как-то поможет, то второй пример нормально работает в typesctipt. Ссылка на демо.
Первый ломается и там, и там, но его можно пофиксить, перенеся проверку typeof напрямую в if. Ссылка на демо.
Спасибо, да, как раз хочу попробовать пересесть на TS и забыть про flow раз и навсегда. Насчет переноса условия прямо внутрь if я в курсе, но в этом и суть — бывают условия громоздкие или не совсем очевидные, в таком случае надо их выносить в отдельную переменную с ясным названием, которая позволит просто читать и понимать такой код.
Я так понимаю с условием все просто: если заставить компилятор разматывать переменные и смотреть на их суть, то это сильно замедлит скорость компиляции.
Еще посмотрите на type guards. Можно вынести код проверки типа в отдельную функцию, и typescript поймет, что там проверяются типы.
Если Reason вас заинтересует, вы можете найти здесь его документацию.
Не найти там ничего — 404
There isn't a GitHub Pages site here.
Должна быть ссылка: https://reasonml.github.io
Как система типов улучшает ваш код (обещание ответить на вопрос).Не нашел ответ на вопрос в заголовке. Плохо искал, наверное.
Ванильный не типизирован (совсем?), что упрощает разработку, но добавляет уязвимости.
Варианты проблем: поле отсутствует в записи (объекте?), метода нет в экземпляре класса (объекте?), IDE не всё может автодополнять (никто не сможет).
Можно попробовать Flow или TypeScript, но они громоздкие, сложные, загружающие и не дают 100% гарантии безопасности (никто не даст).
Рассмотрим два с половиной примера, в которых внезапно появляется Reason, который позволяет сложить строку с числом.
Упомянут опыт разработчика-фаната, который не будет сравнивать VSCode и vim и надеется на появление документации.
Про Reason можно узнать там-то. И про GraphQL. И про день открытых дверей.
Как система типов улучшает ваш код на JavaScript