Это не дурь, это легаси )). 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, что тут все нормально с типами.
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.
Поводом для ревизии данного вопроса стало то, что я по сей день слышу от специалистов (в том числе позиционирующих себя как senior), что современный JavaScript является однопоточным.
Эти понятия - "однопоточный"/"многопоточный" вообще неприменимы к языкам программирования. Так что, из-за чего вообще весь сыр-бор? Что кто-то интуитивно, и неправильно, пользуется терминами?
Услышите в следующий раз что кто-то так говорит, попросите привести пример многопоточного ЯП. Будет интересно )))
Это не дурь, это легаси )). unknown появилось только в 3й версии TS, и базовые типы как JSON.parse уже было не исправить так, чтобы не поломать половину всей TS экосистемы. И это базовые типы, а как быть с огромным количеством JS либ, на которые типы натянуты кое-как? Тот же экспресс, не к ночи будь помянут, на котором много чего написано и до сих пор пишется...
Я как раз и показываю, что использование TS не исключает необходимости контроля типов в рантайм.
Так все таки в TS тоже нужна валидация! Ну надо же...Вы же писали, что TS сам проверяет сигнатуры.
Зато, если птичьи какули не оттираются, шкуркой прошелся и как новая ?. Не то, что это ваше ЛКП.
Это так не работает. Вот простой пример:
Ссылка на песочницу
Вроде функция типизирована, но работает не так, как ожидает разработчик. Интересно - почему?))
Можно еще d.ts писать для внешних интерфейсов модулей, этого достаточно, чтобы не запутаться. Плюс тесты.
На чистом js вполне можно писать выразительный и лаконичный код, в том числе большие проекты со сложной структурой, тут сравнение с байт-кодом неуместно.
Так и есть. Хочешь покодить - f12 и вперед, на любой машине где есть браузер.
Можно, но это бывает порицаемо ))
Тут согласен, TS хорошо бьет по рукам и сразу в лажу носом тыкает, так обучение идет быстрее. Но когда уже понимаешь, что делаешь, в ряде случаев он начинает мешать.
Как раз для вкатышей он лучше подходит, потому что следит, чтобы несмышленыш себе ногу не отстрелил. Если разработчик понимает, что делает, это только мешает.
По поводу C# аргумент так себе, но вы это похоже и сами понимаете ))
Проблема TS в том, что он убивает производительность разработчика. Далеко не всегда для корректного кода на JS тип выводится автоматом. Приходится вместо разработки функционала еще тратить кучу нервов чтобы уговорить TS, что тут все нормально с типами.
Вы мне напомнили одного персонажа, который для изучения JavaScript рекомендует изучать исключительно спецификацию ECMAScript
Меня с собой возьмите ))
У меня был такой случай, давно правда - водитель уехал в другом направлении, а потом телепортировался к месту подачи и стал на меня наезжать, что я не там стою, чтобы отменял заказ. Отменять не стал - жалоба в СП решила вопрос.
Эти понятия - "однопоточный"/"многопоточный" вообще неприменимы к языкам программирования. Так что, из-за чего вообще весь сыр-бор? Что кто-то интуитивно, и неправильно, пользуется терминами?
Услышите в следующий раз что кто-то так говорит, попросите привести пример многопоточного ЯП. Будет интересно )))
Посоветуйте, что можно почитать/посмотреть для прокачки скилов по bash?
Да, но нужно учитывать, что он в первую очередь Т, а потом уже Э
Хотелось бы конечно, чтобы сеть сама рисовала руки правильно, а не костылями.
А есть надежда, что когда-нибудь руки сразу будут генерироваться как надо?