Комментарии 50
Это нельзя отнести к достоинствам языка, но строить всю аргументацию на такой малозначительной коллизии — смешно.
Я осуждаю даже тех, кто работая с типизированным языком, отключает опцию IDE, требующую явных объявлений и типизации.
Преобразование типов, замену разделителей дробной части, локальной денежной единицы, просто должно врасти в организм на уровне инстинктов. И выбирать мертвый язык вместо развивающегося, именно из-за своей проблемы, а не проблемы языка — это моветон.
золотые слова
Согласен, тоже смутило:
Эта ошибка какое-то время оставалась незамеченной, а позже довела нас до неприятностей.
Во первых, незнание основ. Во вторых, как без элементарной проверки и простого теста — прямо в работу? И в третьих — сразу переходим на другое и тоже без освоения основ и анализа? А если в TypeScript тоже вылезет специфичная проблема — то снова всё поменяем?
Лучше если проект в самом начале, то потратить немного больше времени на выбор фундамента проекта и когда обоснованный выбор сделан, еще немного на освоение основ этого фундамента, чтобы учесть его специфику, тогда в середине и на финише не будет разных сюпризов "вот этот ЯП нам всё поломал".
AsyncStorage позволяет хранить лишь строковые данные.
Так, а причём тут проблема JS, если изначально хранилище только для строк?
Тут проблема невнимательности разработчика.
Каким образом ЯП должен угадать намерение хранить числа в строковом типе?
Обратно из JSON будет прочитано any, которое надо еще как-то провалидировать перед кастованием типа. А этого уже Typescript из коробки не даёт.
Если что, это не критика в сторону TS (обожаю его). Просто по статье так прямо он все проблемы решает и можно расслабиться…
Так это проблема js, почему он позволяет передавать строку в функцию которая ожидает только nunber?
Он-то позволяет передать что угодно, потому что функция не ожидает чего-то конкретного, у неё указания типов, как даже в PHP. Проверка через typeof и ожидаемый тип — это дополнительные условия, которые не добавили, и тут претензия не к языку, а к тому разработчику, кто знал про тип данных, основываясь на начальном значении, но не стал его сохранять и проверять.
А язык такой, какой есть, странно винить его за это.
Эм. По вашей логике язык C не виноват в том что в коде на С встречаются ошибки выхода за пределы массива? Тут претензия к разработчикам которые знают что у массива есть размер и за его пределы писать нельзя, нужно делать проверку через strlen или хранить размер массива в отдельной переменной.
"А язык такой, какой есть, странно винить его за это."
Все верно?
Каким образом ЯП должен угадать намерение хранить числа в строковом типе?
Type checker может дать по рукам, если вы будете обращаться со строкой как с числом. IDE может подсказать тип переменной, что также снизить вероятность ошибки.
я могу спать немного спокойнее, зная о том, что переменные в моём проекте не могут совершенно неожиданно менять свои типы.
Я вот не могу спать спокойно, потому что теперь у меня куча забот чтобы правильно все это хозяйство типизировать.
Когда сидишь и разбираешься, почему tsc выдает ошибку там, где все правильно и на js код в этом месте работает без проблем, иногда очень жалко времени.
Кроме того, вы сами преобразовывали число в строку перед помещением в хранилище. Что побудило вас не делать обратное преобразование?
Типизация — это форма авансового платежа. Вы платите заранее, не будучи уверенным пригодится вам или нет.
Тестирование — тоже плата вперед. Только все мы видели большие системы без типов, и никто не видел больших систем без тестов.
Так ведь фокус в том, что преобразование в строку частенько делает какая-нибудь библиотека, если не рантайм.
Скажите а как сейчас дела с типами? Нету рассинхрона между последними версиями библиотек и их типами?
Если тайпинги поставляются вместе с библиотекой — то откуда рассинхрону взяться? А вот если они внешние — то да, от рассинхронов не избавиться.
Рассинхрон редко прям очень, но бывает что не сильно заморачиваются с дженериками и просто ставят any, скажем, как возможный ключ. Но тоже редко и обычно хорошо локализируется. Рассинхрон типов с бэкэндом более частая проблема, и для неё пока особо нет стандартного решения, хотя можно накрутить поверх свагера.
# sarcasm
export const storage = ((s) => ({
set: (key, value) => s.setItem(key, JSON.stringify(value)),
get: (key) => JSON.parse(s.getItem(key)),
key: (n) => s.key(n),
remove: (key) => s.removeItem(key),
clear: () => s.clear()
}))(window.localStorage)
Хотел упомянуть, что есть программисты разной квалификации и не всегда есть поставленный процесс отбора тех кто «привык не совершать ошибки». Даже обычный спеллчекер в ide уже отсекает определенное количество грамматических ошибок (которые имеют место быть). Если расценивать тс как спеллчекер для грамматики языка, то грех не пользоваться, даже если ты умеешь не совершать ошибки в js без надстроек.
Интересно, что в комментариях все-равно защищают типизацию is словами о том, что автор плохо знает язык и делает из мухи слона. Может автор и плохо знает, может и передергивает, но типизация то все-равно отвратительная, особенно все, что касается неявного приведения типов. И нет, это не проблема автора, это откровенно плохой изначальный дизайн языка, который сделали за неделю.
Рассказ о том, почему в 2021 году лучше выбирать TypeScript, а не JavaScript
Так себе аргументация "за". Типа, в 2019 таких проблем не стояло?
Если человек не знает язык и пишет о его недостатках, то это плохая аргументация. Это как: не буду использовать английский, т. к. в нём нет падежей.
TS похож на C# что делает его более менее сносным на клиенте, но проблема в том что добавляется дополнительный шаг сборки, и теперь вместо нажатия зелёной кнопочки play в visual studio нужно запускать какие-то сборки и ждать дополнительного шага компиляции... гемор который не всегда стоит свеч
Стартанули проект на тайпскрипте, до этого пять лет поддерживал проект на чистом js. Конечно тайпскрипт не решает проблему дизайна приложения, но значительно снижает человеческий фактор. Код минимум стал потдатлив к элементарному рефакторингу. В прошлом проекте браться рефакторить старую часть было почти что табу, потому как ничто не гарантировало минимальной работоспособности. Если можно снизить влияние человеческого фактора, то почему бы и нет?
Для вычислений использую Big.js. Это конечно еще одна библиотека, но она дает понять при чтении кода «здесь что-то вычисляется» и строже в арифметических действиях, что лишний раз защищает от нелепых багов.
Рассказ о том, почему в 2021 году лучше выбирать TypeScript, а не JavaScript