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