Мне вспоминается работник RT, который зачем-то полез в щиток переобжимать оптику, хотя я сразу сказал, что проблема в их кривом GPON роутере. В итоге его ударило током, после чего он резко погрустнел, согласился, что проблема в роутере и отчалил.
мог бы поделиться довольно интересной коллекцией случаев
... писать каждый раз проверки внутри функции, что входная переменная является числом вместо того, чтобы сразу типизировать аргумент безусловно быстрее и полезнее для разработчика. Это так весело в чистом JS писать instanceof и typeof.
Вот я и привел пример, который показывает, что использование TS не отменяет необходимости проверки входных переменных. И TS может никак не предупредить об опасности такого кода, оставляя разработчика в иллюзии, что в его коде нет проблем.
Это не дурь, это легаси )). unknown появилось только в 3й версии TS, и базовые типы как JSON.parse уже было не исправить так, чтобы не поломать половину всей TS экосистемы. И это базовые типы, а как быть с огромным количеством JS либ, на которые типы натянуты кое-как? Тот же экспресс, не к ночи будь помянут, на котором много чего написано и до сих пор пишется...
А если ее параметром будет сложный объект? Мне на TS потребуется ровно минута, а вам ?
Это так не работает. Вот простой пример:
const arg = JSON.parse('{"a":"123", "b":123}')
function sum(arg: { a: number, b: number }): number {
const { a, b } = arg
return a + b;
}
console.log(sum(arg)) //"123123"
На чистом js вполне можно писать выразительный и лаконичный код, в том числе большие проекты со сложной структурой, тут сравнение с байт-кодом неуместно.
Тут согласен, TS хорошо бьет по рукам и сразу в лажу носом тыкает, так обучение идет быстрее. Но когда уже понимаешь, что делаешь, в ряде случаев он начинает мешать.
Как раз для вкатышей он лучше подходит, потому что следит, чтобы несмышленыш себе ногу не отстрелил. Если разработчик понимает, что делает, это только мешает. По поводу C# аргумент так себе, но вы это похоже и сами понимаете ))
Проблема TS в том, что он убивает производительность разработчика. Далеко не всегда для корректного кода на JS тип выводится автоматом. Приходится вместо разработки функционала еще тратить кучу нервов чтобы уговорить TS, что тут все нормально с типами.
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.
Провайдера поменял.
Мне вспоминается работник RT, который зачем-то полез в щиток переобжимать оптику, хотя я сразу сказал, что проблема в их кривом GPON роутере. В итоге его ударило током, после чего он резко погрустнел, согласился, что проблема в роутере и отчалил.
Поделитесь, такие истории интересно читать.
Спасибо хоть написали как выйти из vim
Если не ясно какой тип будет, человек может написать тест, запустить отладчик, почитать доку...
Песочница
Вы писали:
Вот я и привел пример, который показывает, что использование TS не отменяет необходимости проверки входных переменных. И TS может никак не предупредить об опасности такого кода, оставляя разработчика в иллюзии, что в его коде нет проблем.
Это не дурь, это легаси )). unknown появилось только в 3й версии TS, и базовые типы как JSON.parse уже было не исправить так, чтобы не поломать половину всей TS экосистемы. И это базовые типы, а как быть с огромным количеством JS либ, на которые типы натянуты кое-как? Тот же экспресс, не к ночи будь помянут, на котором много чего написано и до сих пор пишется...
Я как раз и показываю, что использование TS не исключает необходимости контроля типов в рантайм.
Так все таки в TS тоже нужна валидация! Ну надо же...Вы же писали, что TS сам проверяет сигнатуры.
Зато, если птичьи какули не оттираются, шкуркой прошелся и как новая 😎. Не то, что это ваше ЛКП.
Это так не работает. Вот простой пример:
Ссылка на песочницу
Вроде функция типизирована, но работает не так, как ожидает разработчик. Интересно - почему?))
Можно еще d.ts писать для внешних интерфейсов модулей, этого достаточно, чтобы не запутаться. Плюс тесты.
На чистом js вполне можно писать выразительный и лаконичный код, в том числе большие проекты со сложной структурой, тут сравнение с байт-кодом неуместно.
Так и есть. Хочешь покодить - f12 и вперед, на любой машине где есть браузер.
Можно, но это бывает порицаемо ))
Тут согласен, TS хорошо бьет по рукам и сразу в лажу носом тыкает, так обучение идет быстрее. Но когда уже понимаешь, что делаешь, в ряде случаев он начинает мешать.
Как раз для вкатышей он лучше подходит, потому что следит, чтобы несмышленыш себе ногу не отстрелил. Если разработчик понимает, что делает, это только мешает.
По поводу C# аргумент так себе, но вы это похоже и сами понимаете ))
Проблема TS в том, что он убивает производительность разработчика. Далеко не всегда для корректного кода на JS тип выводится автоматом. Приходится вместо разработки функционала еще тратить кучу нервов чтобы уговорить TS, что тут все нормально с типами.
Вы мне напомнили одного персонажа, который для изучения JavaScript рекомендует изучать исключительно спецификацию ECMAScript
Меня с собой возьмите ))
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.