ну мы сейчас явно о разных слоях абстракции говорим.
далеко не факт, что в документации к проекту, описан интерфейс каждой функции в проекте.
если он описан, то документация и есть код

Преимущества и недостатки тс - это точно по теме канала? :)

Львиная доля ошибок действительно это либо недопонимание как работает стандартная библиотека / язык (к ним относят и ошибки памяти у non-GC япов) и собственно ошибка спецификации / логики. И вот в первом случае типизация (точнее семантический типизированный анализ) более не менее справляется. Во втором случае нужно вводить уже зависимые типы и формальную верификацию

Еще одна важная вещь в TS особенно для больших проектов с большой командой - это самодокументированность. И Климов об этом не упомянул в докладе или упомянул? В общем, TS дает совершенно другой уровень DX с автокомплитом и подсветкой типов по требованию. Конечно можно было бы его заменить на jsdocs. Но jsdocs как по мне еще более вербозен и при этом еще и не делает семантической проверки, поэтому логично что его вытеснил TS

>недопонимание как работает стандартная библиотека

если бы там были бы другие типы, то, думаю, ошибок было бы меньше

JSDoc не сильно более вербозен, и, например, VS Code его автоматически подхватывает и проверяет (тем же tsc 😊).

В любой приличной документации описывают не только интерфейс каждой (хотя бы публичной) функции, но и её смысл, условия применимости и даже примеры использования.

А почему небыло 4й группы, которая бы использовала unit тесты, design review и TS? =) Собственно на этом можно и заканчивать

https://youtu.be/H9-F8uhKMRk?t=1998

А теперь убирает VSCode =)

ну как бэ потому что смысл - если  unit тесты, design review покрывают и так независимо от ts, потому он и говорит он тут лишний

Подозреваю, что IDE от JetBrains тоже подхватывают без лишних вопросов. И я не думаю, что сильно много JS-программистов пишут в Emacs/Vim. 🤷‍♀️

Типизация не отменяет тестирования и code review=) В этом основная и главная ошибка, которая ввобит всех в заблуждение

Климов делает предположение (ранее) что код ревью и тесты полностью заменяют типизацию, но доказательству этому не приводит.

так вот введля 4ю контрольную группу он мог бы это доказать или опровергнуть

Но при наличии design review + code review + tests (unit and integration) от (слабой) системы типов пользы уже почти никакой. Что более-менее подтверждается эмпирическими исследоваиями.

он потом сказал что 8 месяцев спустя третья команда обратно добавила тс в список этих штук, и они замедлились

Ага, ок, я значит не лосмотрел еще до этого

Обычно разработка со временем замедляется вне зависимости от добавления/удаления типизации (но, в теории, может замедляться в разной степени). 😊

вот в этом я точно не согласен, хорошие типы позволяют проще делать ревью, проще писать тесты, исключать очевидные ошибки дизайна системы

в хорошо стипизированной системе вы можете не беспокоиться что сложите килограммы с фунтами, потому что у них разные типы и писать юниттест на такой случай не надо, что упрощает разработку