Ссылку то можно, что за источник?

В комментарии, на который сослался ваш оппонент, прямая цитата из RTFM'а, с которой вы как раз и спорите.

ну то, что вы с ним курите какие то альтернативные источники это понятно.
Простые смертные за источник считают вот это
Динамическая типизация

если не нравится википедия, то могу направить в школу
цитата — JavaScript has dynamic types.
не «нетипизованный» язык, а динамически типизованный.
Там же можно почитать какие типы бывают в языке. Что то я там типа «any» не нашел, а вот строковый, числовой и булевый типы, внезапно, есть.

Динамическая типизация — это оксюморон

отнюдь. разница динамической типизации и статической лишь в том, что переменная может в рантайме менять тип в первом случае и не может во втором. Типы по прежнему есть и там и там, более того, те же самые типы. можно конечно поспорить с RTFM-ом ради бога, я ж не против.

Если вы не видите суслика, это не значит, что его нет.

опять же, отнюдь. Типизация призвана ловить ошибки несоответствия типов. логическую ошибку типизация ловить не призвана. Пример именно на логическую ошибку. И тесты тут кстати тоже не помогут. Потому что ту же логическую ошибку автор такого кода совершит и в тесте тоже. Опять же было бы проще «перепутать» 401 и 403, их путают постоянно, сколько раз уже встречал. Люди также не знают в чем разница между авторизацией и аутентификацией, как вот тут между строгостью и статичностью…

Забавный факт: изначально фраза «strongly hyped» была про C++, который не является строго типизированным языком, в отличие от Java и С# например.
И речь в статье все таки про статическую типизацию против динамической, а не про строгую против слабой.

Далее — первый пример из статьи не имеет отношения к типизации вообще.
А вот второй пример как раз таки именно тот который типизацией можно решить.
Есть такой антипаттерн — primitive obsession. У него две формы, первая — когда вместо того, чтобы создать полноценную модель делают что то вот такое List<Dictionary<string, Dictionary<string, List<…
А вторая форма, когда для идентификаторов используют примитивы. Бороться с этим просто — завернуть идентификатор в объект или структуру.
например вот так

export interface CompanyId {
  companyId: number;
}

export async function getCompany(id: CompanyId): Promise<Company> {
}

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

типизация не серебряная пуля, и тестирование собой не заменит. Это, как и тесты, еще один фильтр на пути грязи в код. Многоуровневая система фильтрации работает лучше чем одноуровневая.
И еще одно — на Javascript люди привыкли писать лютую дичь. Приходят в проект на typescript и пишут тоже самое, подставляя «any». Я же прошу написать полноценную типизацию той клоаки которую они родили. Как результат — люди начинают писать более удобоваримый код, качество их кода растет, просто от введения типизации.

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

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

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

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

У меня был такой инцидент, я считаю на ровном месте. Но тогда я действительно часть времени разработки над модулем потратил на работе. Как минимум время на тестирование и устранение ошибок, отладку на «боевом» проекте т.с. Своя разработка, которую в проект внедрил «правдами и неправдами», причем работало оно на MSSql и на Oracle, два NuGet пакета опубликовал, в рабочем проекте был использован код с Oracle. Т.е. было логично предположить, что MSSql часть в рабочее время, по заданию от руководителя я не делал, и она была сделана раньше, чем Oracle часть. Но публиковался я сильно позже, попросили для компании «что нибудь опубликовать», в т.ч. статью на хабре. А вот со стороны заказчика усердные работники, увидев этот опубликованный материал, попросили Oracle часть снять с публикации и вообще суетились как то непропорционально сильно.

С тех пор я сначала публикую пакет, а только потом использую в проекте как зависимость. Т.е. сам исходник моей разработки в рабочий проект больше не попадает. Правда не знаю, спасёт ли это меня, если вдруг что.

Вопрос такой, на счет роспатента. Если я создаю библиотечку, код на гитлабе, опубликована в NPM, по лицензии MIT, и я в рабочий проект эту библиотечку поставил как зависимость, это может послужить основанием работодателю считать, что теперь этот пакет вместе с исходником его собственность? только патент его остановит?

ждём react.net :)

Ходят слухи, что 48 ядер в топе будет. st.overclockers.ru/legacy/blog/355118/126574_O.jpg
А по другим источникам так вообще 64.

Где продаются?

Интересно, про автора Homebrew, может он не прошел собеседование, и это его мотивировало изучить тему и впоследствии применить знания? Вроде как пакетные менеджеры нуждаются в имплементации дерева в своей работе.

невнимательно прочитал, оказывается речь шла не про assertion, а про подавление warning optType.maybe!.data

Находка: Восклицательный знак в роли Non-null assertion operator

Это вредный совет, рано или поздно вы по невнимательности наткнетесь на проверку number или string таким образом и получите баг. Лучше запретить использование небулевого выражения в булевом контексте с помощью tslint.

Фразу «ты то, что ты ешь» придумал какой то овощ.

Во первых это накладывает дополнительный гемор для работы. При этом ничего не мешает сломать еще и старый код…

Это, кстати первое, что бросилось в глаза, когда я начал работать в проекте со свитчами. Нельзя просто так выпилить старую более никому не нужную логику, и по завершению фичи должен работать и новый код и старый. Нельзя выпилить старую колонку в базе. Это добавляет кучу лишней работы. И новый код приходится писать так, чтобы он не конфликтовал со старым, т.е. кроме того, что старый код надо продолжать поддерживать, в новом коде появляются технические решения, которые не объяснить требованиями. И в будущем, когда приходится еще раз потрогать этот код, идешь к разработчику, который последний раз его трогал и спрашиваешь, почему так, а он отвечает фразой — «исторически так сложилось».

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

Я бы вот так делать не стал.
…
Такие ветвления вносят неразбериху.

Непустая ветка else еще не самое худшее, что може произойти. У нас на портале визард. В JSON лежит конфигурация, степы в порядке следования, дочерние степы и т.п. Разработчик добавляет новый степ. Пока не придумали ничего лучше, чем по if грузить один JSON или другой. Теперь представляем как два разработчика в параллель добавляют два разных степа. Что случится если включить сразу обе фичи? появятся все нужные степы в визарде? очевидно нет. json содержащий все нужные степы просто не существует.