🔗 Ссылки: TS Reset: github.com/total-typescript/ts-reset ⚡Курс по TypeScript: purpleschool.ru/course/typescript - 18 часов видео - 29 тестовых заданий и упражнений - Неограниченный доступ и гарантия возврата средств - ⭐ 4.8 на независимых платформах 👨💻Клуб разработчиков: purpleschool.ru/club Мои курсы по разработке: purpleschool.ru 💬 Telegram канал с полезными советами: t.me/purple_code_channel
Странно, что не упомянута главная проблема ts, а именно false positive и все вытекающее из этого, при этом вещи которые вас защищают от плохого кода, считается проблемой. В случае as const на массиве, вам уже не нужен include, тк вы создали тюпл из этих значений, и компилятор видит, что они там есть, а других быть не может. При этом, вы этот тюпл можете передать в функции которые принимают массив, тч проблем с этим быть не может.
Массивы такие, какие есть, и с этим ничего не поделать. Там может быть что угодно, и с этим надо разбираться в ручную, потому что никакой анализатор не сможет восстановить желаемый тип, так как нет связи между передаваемыми значениями и операциями, которые производятся с этими значениями в колбеке для фильтрации. Для подобной фильтрации, лучше всего, подойдет reduce(), там гарантировано можно контролировать результат. Что касается ts-reset, то проблемы тайпскрипта он не решает, а маскирует субъективно неудобную типизацию, переопределяя типы для встроенных в js вещей.
Я думаю что разработчики ts сознательно пожертвовали безопасностью оставив тип any в таких операциях как JSON.parse, isArray и тд, поскольку приходилось бы писать очень много кода с проверками чтобы удовлетворить ts компилятор. А сами проверки только увеличат финальный билд проекта, что для джаваскрипта не очень хорошо, поскольку язык некомпилируемый. Конечно проверять значения по схемам - хорошая практика. Но я считаю правильным решением оставить это опционлальным.
Так потому, в ts было бы не плохо добавил рефлексию и расширить возможности дженериков. А то получается, что вы обманываетесь чувством безопасности, когда на самом деле компилятор может легко принять не валидный код. Могли бы хотя бы unsafe внести и лишь в ней разрешать творить магию не безопасных типов
Как относитесь к использованию JsDoc как полноценную проверку типов для typescript? Обнаружил, что ts поддерживает проверку типов по jsDoc. С первого взгляда кажется есть все подсказки и проверка типов. Знаю проект который написан создателями стандарта EcmaScript и promises таким подходом. Хочу попробовать, но хотел бы услышать ваше мнение. Так же проверил, что таким способом прекрасно подключается и работает `import "@total-typescript/ts-reset";`, ide показывает что результат JSON.parse, тип unknown
Привет, спасибо за видео! Но конечно фильтрация на undefined с помощью Boolean далеко не самая лучшая идея. По факту вместо undefined мы фильтруем все falsy значения)
Классное видео)) кстати как в неовим делать рефактор? Никак не могу перейти полностью на вим потому что очень много приходится переносить файлы, папки, переназывать файлы и надо чтоб импорты тоже рефакторились. Есть ли какое-то решение данной проблемы? Пока что знаю только как рефакторить при ренейме файла. А вот с переносом папок проблемы 😅
библиотека тоже так себе, в примере с фильтром она не правильно определяет тип если написать (e => e !== undefined). так же она не решает проблемы в примере с if(value in obj). было бы правильно если бы для value определялся тип keyof typeof obj, но увы...
@@PurpleSchool странный подход для строгой типизации, пускай падает с исключением если там чушь лежит в JSON, всё равно чушь никак не обработать. В общем случае что any что undefined дают почти ничего. А парсить json из кода зачем? можно сразу объект в коде написать
А зачем делать отдельный глобальный .d.ts файл когда ts-reset можно подключить через опцию types в tsconfig? Конечно кто-то мне возразит, что через .d.ts можно применить все к отдельным папкам, но как по мне такое должно вводиться сразу на весь проект.
@@PurpleSchool хорошая попытка))))) но у меня Typescript+Next+React есть еще , сначала его, потом доку и если вопросы - то тайпскрипт. в целом линейка оч крутая получается
@@PurpleSchool договорится о стандартизации, совместно разработать решение для проблем языка и поэтапно внедрить их, как это делают в питоне. Внедрили строгую типизацию, которая не совсем строгая и при этом чтоб она работала как задумано, нужно написать еще пакет надстройщик. Звучит как шизофрения. Если бы не обстоятельства я бы от этой кухни держался подальше
чоооо ?? Реакт кто создал забыл чтоле или тот же nginx - по видоуроку от улбитв сделали сервер для финального приложения в школе, да пришлось попотетть и пописать своё но на несте с нуля люди сели и за два дня накидали сервак это как пример, ну или тот же курс по ангуляру 15 от Минина - сел и набалакал и дальше сам уже запилил магазин отталкиваясь от того что сделал по уроку - сходите посморите немца какогототаммайреа который на английском пилит обучалки - сравните его курс по реакту и тот же альманах от улби )) Автор сорян за имена других блогеров, ты тоже классный и конечно же и тебя смотрим и любим !
Что с тобой не так что бы приковыряться к человеку который выразил благодарность автору.Хзы как ты код пишешь, но слова в предложения у тебя так себе получается
Главная проблема тайпскрипта это отсутствие надежной системы типов, более того такой цели у разработчиков языка никогда и не было, при этом куча народа на серьезных щщах сравнивает "строгую" типизацию тайпскрипта с джавой, шарпом и подобными языками. Как бы да, в простых случаях компилятор ругнется и не даст провернут классический фокус "1"+"1" == 11, но в более сложных случаях эта самая система типов прекрасно допускает рантайм ошибки, которых бы не было в языках с реально надежной системой типов, особенно это хорошо стреляет на крупных проектах, где в коде обязательно рано или поздно ввернут any, чтобы все стало веселее
@@vasiliykrush2150 Потому что бывает, что в других командах к any относятся нормально и на код ревью такое не смотрят, бывает что ПМы давят по срокам и разрабы срезают углы, воткнув any, бывает что проект уже достался с any, которые там оставили другие люди и просто так это уже не выпилишь. Тут вопрос в том, что система типов в тайпскрипта не защищает от ошибок, связанных с типами.
@@vasiliykrush2150 В целом чем больше проверок удастся переложить на надежные автоматические средства, тем лучше. И в этом ключе ожидаешь что типизация будет одним из них, но увы
@@okke00 так есть плагины проверяющие/запрещающие наличие any. Это уже если команды разнятся в своих убеждениях, то человеческий фактор а не проблемы инструмента =) он просто вот такой, другого мы не получим)) можно организовать кучу валидации в рантайме с помощью либ, но это не производительно. Тут где то человечек в соседнем комментарии уже писал про это
@@vasiliykrush2150 Плагины(я так понимаю речь про линтеры идет) не всегда помогают в ситуациях, когда большая часть команд придерживается других взглядов на any или когда проект достался в наследство и там прежде, чем включать надо порефакторить еще дофига. И да, тут есть проблема в человеческом факторе, согласен, к тайпскрипту претензия в том, что в нем можно было бы сделать систему типов, которая бы не допускал таких вещей(как например в ReasonML). Заигнорить компилятор как правило сильно сложнее чем линтер.
@@СергейКурганов-о2э с includes все хорошо, объявив tuple, все, будь добр соответствовать. Если же работаешь с неизвестными данными, то tuple тут не место.
Потому что это breaking changes. Разумеется, разрабы тса знают про эти проблемы, но не хотят выпускать мажорный релиз, который будет ломать существующий код.
В мире джаваскрипта не может быть слишком много зависимостей) Но если серьезно, то контрибьютнуть что-то в проект уровня тайпскрипта сильно сложнее чем просто залить свою либу в нпм, мб просто не захотели заморачиваться
@@PurpleSchool они работают криво, когда я сам пытался их использовать словил разочарование. вернее там вроде проблема не столько с типизацией сколько с подсказками. при параметров ts предлагает не правильные подсказки, хотя если их выбрать то будет ругаться что это не соответствует перегрузки...
Уже столько человек сказали про слишком громкую заставку (про старую),но вот вышла новая - наступаем на всё те же грабли. Либо тебе плевать на мнение аудитории, либо лень исправлять такой маленький косяк. Даже не знаю, какой из вариантов хуже🙃
@@PurpleSchool если json создается клиентом то в чем проблема его типизировать через интерфейс? А если он приходит с бэка и известна схема, то как статическая типизация защитит от ошибки в типе данных во время рантайма? Часто храните undefined и цифры в одном массиве? Ошибки проектирования пытаетесь исправить типизацией 🤭
@@PurpleSchool это все равно что рис пинцетом собирать, для внешних данных есть схема-валидаторы вроде joi, а внутренние данные не должны требовать рантайм проверок.
не согласен с перечисленными преимуществами... расширяемость на много легче у слабо типизированных, как и многое другое. поэтому и появились слабо типизированные яп. у строго типизированных преимущество одно - "они быстрее!". это единственный реальный плюс строго типизированных яп. остальное скорее мифы чем реальность. это уже много раз писали программисты с мировым именем. предугадывание типа, очень долгий и сложный процесс, поэтому слабо типизированные яп на порядок медленнее но при этом как расширяемость так и скорость разработки, написание архитектуры, гибкость на них в разы быстрее и комфортнее. тем кто сильно завязан за строгую типизацию, очень сложно дается понимание слабой типизации. надо перестроить мышление и это очень сложно.. а с слабой типизации на строгую в разы проще перейти. ибо ты и так всегда думаешь про типы, просо держишь их в голове а не в коде.😁поэтому у них переход более мягкий и безболезненный в отличии от тех кто со строгих пытается писать на не строгих. это постоянно так было и остается.. поэтому прекрасно понимаю почему любите строгие, ибо видать начинали именно с них или перешли в ранней стадии на строгие не поняв слабые.)))
Если ты "всегда держишь в голове типы", то для тебя не должно быть проблем их писать в коде. Если тебе это как-то мешает, значит ты в голове типы не держишь и не привык писать надежный код. У слабой типизации нет каких-то преимуществ кроме того, что она пытается вместо тебя подумать о типах, в то время как ты это делать не хочешь.
🔗 Ссылки:
TS Reset: github.com/total-typescript/ts-reset
⚡Курс по TypeScript: purpleschool.ru/course/typescript
- 18 часов видео
- 29 тестовых заданий и упражнений
- Неограниченный доступ и гарантия возврата средств
- ⭐ 4.8 на независимых платформах
👨💻Клуб разработчиков: purpleschool.ru/club
Мои курсы по разработке: purpleschool.ru
💬 Telegram канал с полезными советами: t.me/purple_code_channel
очень громкая заставка относительно голоса
Ок, подправим в следующих видео)
hi, nice video!
Just need to be careful with `Boolean`:
const arr = [0,1,2,3]
console.log(arr.filter(Boolean)) // [1, 2, 3]
Yes! You are right.
Странно, что не упомянута главная проблема ts, а именно false positive и все вытекающее из этого, при этом вещи которые вас защищают от плохого кода, считается проблемой. В случае as const на массиве, вам уже не нужен include, тк вы создали тюпл из этих значений, и компилятор видит, что они там есть, а других быть не может. При этом, вы этот тюпл можете передать в функции которые принимают массив, тч проблем с этим быть не может.
Массивы такие, какие есть, и с этим ничего не поделать. Там может быть что угодно, и с этим надо разбираться в ручную, потому что никакой анализатор не сможет восстановить желаемый тип, так как нет связи между передаваемыми значениями и операциями, которые производятся с этими значениями в колбеке для фильтрации. Для подобной фильтрации, лучше всего, подойдет reduce(), там гарантировано можно контролировать результат.
Что касается ts-reset, то проблемы тайпскрипта он не решает, а маскирует субъективно неудобную типизацию, переопределяя типы для встроенных в js вещей.
да с тайпскрипта такое болото сделали, уже жду когда в JS добавят типи и забуду о TS
Никогда не добавят, если только на какой нибудь статически типизированный яп переведут по типу шарпа или раста, но для этого есть web assembly
Я думаю что разработчики ts сознательно пожертвовали безопасностью оставив тип any в таких операциях как JSON.parse, isArray и тд, поскольку приходилось бы писать очень много кода с проверками чтобы удовлетворить ts компилятор. А сами проверки только увеличат финальный билд проекта, что для джаваскрипта не очень хорошо, поскольку язык некомпилируемый. Конечно проверять значения по схемам - хорошая практика. Но я считаю правильным решением оставить это опционлальным.
В целом согласен, но простая проверка по схеме действительно сразу решит все проблемы, просто надо это сделать правильной практикой
Так потому, в ts было бы не плохо добавил рефлексию и расширить возможности дженериков. А то получается, что вы обманываетесь чувством безопасности, когда на самом деле компилятор может легко принять не валидный код. Могли бы хотя бы unsafe внести и лишь в ней разрешать творить магию не безопасных типов
Желаю развития каналу!
Спасибо!
Любопытная инфа. Спасибо.
Пожалуйста!
TypeScript 4.9.5 - не наблюдаю проблему с undefined в массиве, тип переменной - number[].
Очень понравилось видео!
Спасибо!
Мне понарвилось, все понятно! Спасибо вам большое! : )
Спасибо!
Топ ролик!
Спасибо!
очень крутая библа, спасибо)
Спасибо!
скажите, планируется создание продвинутых курсов, где более подробно уделяется внимание архитектурным решениям?
Да, очень много архитектуры разбирается в курсе по микросервисам и паттерны проектирования в TypeScript.
Икона для защиты Wi-Fi от взлома или чтобы сигнал сильнее был?
Нет, иконка не рабочего модуля WiFi)
Интересно и полезно) Можно узнать как тема в vsc называется?
Спасибо! Bearded Theme Vivid Purple
Как относитесь к использованию JsDoc как полноценную проверку типов для typescript? Обнаружил, что ts поддерживает проверку типов по jsDoc. С первого взгляда кажется есть все подсказки и проверка типов. Знаю проект который написан создателями стандарта EcmaScript и promises таким подходом. Хочу попробовать, но хотел бы услышать ваше мнение.
Так же проверил, что таким способом прекрасно подключается и работает `import "@total-typescript/ts-reset";`, ide показывает что результат JSON.parse, тип unknown
Не использовал его плотно
Использовал, он действительно совместим с ts, но уступает ему в возможностях и удобстве
Привет, спасибо за видео! Но конечно фильтрация на undefined с помощью Boolean далеко не самая лучшая идея. По факту вместо undefined мы фильтруем все falsy значения)
Верно, тут как пример
Да и к тому же число ноль (0) теряется, если бы он в массиве был (преобразуется в False).
Matt весёлый мужик)
Да, очень рекомендую его канал.
Антон, доброго времени суток! А будут ли еще ролики с собеседованиями? Например из вашего курса, где есть опция "1 на 1 с наставником"
Привет! Думаю что будет. Собеседования 1 на 1 мы публично не выкладываем, но у нас в клубе 1 раз в месяц проводятся публичные собеседования.
Классное видео)) кстати как в неовим делать рефактор? Никак не могу перейти полностью на вим потому что очень много приходится переносить файлы, папки, переназывать файлы и надо чтоб импорты тоже рефакторились. Есть ли какое-то решение данной проблемы? Пока что знаю только как рефакторить при ренейме файла. А вот с переносом папок проблемы 😅
библиотека тоже так себе, в примере с фильтром она не правильно определяет тип если написать (e => e !== undefined). так же она не решает проблемы в примере с if(value in obj). было бы правильно если бы для value определялся тип keyof typeof obj, но увы...
Да, есть ещё возможность для улучшения
Странно, почемубы сразу не указывать тип в который десерииализуешь JSON.
Можно, то не будет runtime проверок
@@PurpleSchool странный подход для строгой типизации, пускай падает с исключением если там чушь лежит в JSON, всё равно чушь никак не обработать. В общем случае что any что undefined дают почти ничего. А парсить json из кода зачем? можно сразу объект в коде написать
А зачем делать отдельный глобальный .d.ts файл когда ts-reset можно подключить через опцию types в tsconfig?
Конечно кто-то мне возразит, что через .d.ts можно применить все к отдельным папкам, но как по мне такое должно вводиться сразу на весь проект.
Можно и так
Балдеж
Спасибо!)
Ой там много косяков есть, Object.entries , работа с деструктуризацией в методе reduce, то что вспомнил! Спасибо за утилитку!
Пожалуйста 👍
filter(Boolean) удалит 0 из массива, а также оставит true и т д
const data = JSON.parse("{a : 1}") as unknown
В js кстати вообще нет разделения на дабл и инт, что тоже в свою очередь минус, хотя так ли это важно в вебе
Да, как нет float
По JS крутой курс. Адвандсед который. Почти все темы зачет
Спасибо! По TS мне даже больше понравился как получился)
@@PurpleSchool хорошая попытка))))) но у меня Typescript+Next+React есть еще , сначала его, потом доку и если вопросы - то тайпскрипт. в целом линейка оч крутая получается
Спасибо!)
Прежде чем создавать костыль для костыля, стоит попробовать вылечить ногу.
Как ты это представляешь?)
@@PurpleSchool договорится о стандартизации, совместно разработать решение для проблем языка и поэтапно внедрить их, как это делают в питоне. Внедрили строгую типизацию, которая не совсем строгая и при этом чтоб она работала как задумано, нужно написать еще пакет надстройщик. Звучит как шизофрения. Если бы не обстоятельства я бы от этой кухни держался подальше
Редко лайкаю русскоязычные "туториал" видосы (зачастую из-за низкого качества материала), но тут все шикарно. Лайкосик поставил. Спасибо за контент.
Спасибо большое!
чоооо ?? Реакт кто создал забыл чтоле или тот же nginx - по видоуроку от улбитв сделали сервер для финального приложения в школе, да пришлось попотетть и пописать своё но на несте с нуля люди сели и за два дня накидали сервак это как пример, ну или тот же курс по ангуляру 15 от Минина - сел и набалакал и дальше сам уже запилил магазин отталкиваясь от того что сделал по уроку - сходите посморите немца какогототаммайреа который на английском пилит обучалки - сравните его курс по реакту и тот же альманах от улби )) Автор сорян за имена других блогеров, ты тоже классный и конечно же и тебя смотрим и любим !
Что с тобой не так что бы приковыряться к человеку который выразил благодарность автору.Хзы как ты код пишешь, но слова в предложения у тебя так себе получается
Главная проблема тайпскрипта это отсутствие надежной системы типов, более того такой цели у разработчиков языка никогда и не было, при этом куча народа на серьезных щщах сравнивает "строгую" типизацию тайпскрипта с джавой, шарпом и подобными языками. Как бы да, в простых случаях компилятор ругнется и не даст провернут классический фокус "1"+"1" == 11, но в более сложных случаях эта самая система типов прекрасно допускает рантайм ошибки, которых бы не было в языках с реально надежной системой типов, особенно это хорошо стреляет на крупных проектах, где в коде обязательно рано или поздно ввернут any, чтобы все стало веселее
аха, код ревью/договоренности вам зачем в этих крупных проектах если кто-то вворачивает any?
@@vasiliykrush2150 Потому что бывает, что в других командах к any относятся нормально и на код ревью такое не смотрят, бывает что ПМы давят по срокам и разрабы срезают углы, воткнув any, бывает что проект уже достался с any, которые там оставили другие люди и просто так это уже не выпилишь. Тут вопрос в том, что система типов в тайпскрипта не защищает от ошибок, связанных с типами.
@@vasiliykrush2150 В целом чем больше проверок удастся переложить на надежные автоматические средства, тем лучше. И в этом ключе ожидаешь что типизация будет одним из них, но увы
@@okke00 так есть плагины проверяющие/запрещающие наличие any. Это уже если команды разнятся в своих убеждениях, то человеческий фактор а не проблемы инструмента =) он просто вот такой, другого мы не получим)) можно организовать кучу валидации в рантайме с помощью либ, но это не производительно. Тут где то человечек в соседнем комментарии уже писал про это
@@vasiliykrush2150 Плагины(я так понимаю речь про линтеры идет) не всегда помогают в ситуациях, когда большая часть команд придерживается других взглядов на any или когда проект достался в наследство и там прежде, чем включать надо порефакторить еще дофига. И да, тут есть проблема в человеческом факторе, согласен, к тайпскрипту претензия в том, что в нем можно было бы сделать систему типов, которая бы не допускал таких вещей(как например в ReasonML). Заигнорить компилятор как правило сильно сложнее чем линтер.
Старая заставка больше нравилась
Хм, ну попробуем совместить с новым лого)
У TypeScript нет проблем. Это проблемы у людей с пониманием
Ну объясните тогда повеление с includes, в других языках такой проблемы нет. Явный баг.
Тут явно есть недоработки TS, которые должны решаться, тут нет непонимания, есть понимание, что можно лучше
@@СергейКурганов-о2э с includes все хорошо, объявив tuple, все, будь добр соответствовать. Если же работаешь с неизвестными данными, то tuple тут не место.
значит ты плохо знаешь ts если так думаешь
Говорят, что главное слабое место typescript то, что Майкрософт в одно лицо делает с ним что хочет, даже если это не совместимо с js
Да, но практика показывает, что они быстро поддерживаю новые фичи и стараются быть максимально совместимыми.
Правильно делает, потом тайпскрипт заменит собой js и будет все круто, с проверками типов в рантайме.
@@profesor08 что за бред ты несешь
По какой причине автор данной библиотеки не законтребьютил эти изменения в репозиторий ts? Зачем порождать еще одну зависимость ?
Потому что это breaking changes. Разумеется, разрабы тса знают про эти проблемы, но не хотят выпускать мажорный релиз, который будет ломать существующий код.
В мире джаваскрипта не может быть слишком много зависимостей) Но если серьезно, то контрибьютнуть что-то в проект уровня тайпскрипта сильно сложнее чем просто залить свою либу в нпм, мб просто не захотели заморачиваться
Тут верно, что такие breaking changes не просто принимать разработчикам TS., как пример - тип unknown в error. Потому как временное решение подойдет.
В свое время отсутствие перегрузок меня огорчил
Вроде они на месте и можно пользоваться. Не совсем конечно, как в C#, но тоже норм.
@@PurpleSchool они работают криво, когда я сам пытался их использовать словил разочарование. вернее там вроде проблема не столько с типизацией сколько с подсказками. при параметров ts предлагает не правильные подсказки, хотя если их выбрать то будет ругаться что это не соответствует перегрузки...
Уже столько человек сказали про слишком громкую заставку (про старую),но вот вышла новая - наступаем на всё те же грабли. Либо тебе плевать на мнение аудитории, либо лень исправлять такой маленький косяк. Даже не знаю, какой из вариантов хуже🙃
Косяк монтажера, исправим
все проблемы высосаны из пальца, пишите код а не боритесь с ошибками типизации
Не согласен, плохая типизация как раз ведёт к ошибкам.
@@PurpleSchool если json создается клиентом то в чем проблема его типизировать через интерфейс? А если он приходит с бэка и известна схема, то как статическая типизация защитит от ошибки в типе данных во время рантайма? Часто храните undefined и цифры в одном массиве? Ошибки проектирования пытаетесь исправить типизацией 🤭
Так тип unknown как раз и заставляет делать runtime проверки, что не делает any
@@PurpleSchool это все равно что рис пинцетом собирать, для внешних данных есть схема-валидаторы вроде joi, а внутренние данные не должны требовать рантайм проверок.
@@PurpleSchool Это вопрос настройки тайпскрипта и линтера
Антон, обратите пожалуйста внимание на пользователей мобильных устройств. Увеличивайте масштаб максимально. Место на экране позволяет же. Успехов!
Спасибо, ещё увеличу)
Самописная заплатка на язык?
Да, JS с TS не перестаёт удивлять... по крайней мере тех, кто начинал изучение с С/C++
Да, что поделать, в плюсах тоже много устаревшего и что вызывает вопросы
@@PurpleSchool Возможно, конечно...
@@victormogзато это не удивит тех, кто начинал с lisp))
хватит путать строгую и статическую типизации
Слабые места тайпскрипт, топ 100:
1-99) типизация
100) сам тайпскрипт
эм, видео высосано из пальца и из либы того человечка..
Не понравилось
не согласен с перечисленными преимуществами... расширяемость на много легче у слабо типизированных, как и многое другое. поэтому и появились слабо типизированные яп. у строго типизированных преимущество одно - "они быстрее!". это единственный реальный плюс строго типизированных яп. остальное скорее мифы чем реальность. это уже много раз писали программисты с мировым именем. предугадывание типа, очень долгий и сложный процесс, поэтому слабо типизированные яп на порядок медленнее но при этом как расширяемость так и скорость разработки, написание архитектуры, гибкость на них в разы быстрее и комфортнее. тем кто сильно завязан за строгую типизацию, очень сложно дается понимание слабой типизации. надо перестроить мышление и это очень сложно.. а с слабой типизации на строгую в разы проще перейти. ибо ты и так всегда думаешь про типы, просо держишь их в голове а не в коде.😁поэтому у них переход более мягкий и безболезненный в отличии от тех кто со строгих пытается писать на не строгих. это постоянно так было и остается.. поэтому прекрасно понимаю почему любите строгие, ибо видать начинали именно с них или перешли в ранней стадии на строгие не поняв слабые.)))
Если ты "всегда держишь в голове типы", то для тебя не должно быть проблем их писать в коде. Если тебе это как-то мешает, значит ты в голове типы не держишь и не привык писать надежный код.
У слабой типизации нет каких-то преимуществ кроме того, что она пытается вместо тебя подумать о типах, в то время как ты это делать не хочешь.