А есть примеры кода с ООП, где норм поддерживать и развивать кодовую базу можно?

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

Окей, я услышал, просто пока не дошел до этого мнения, поэтому не согласен

Хотелось бы послушать в чём же будет основной наброс на typescript. Я видел мнение, якобы он увеличивает время разработки. Возможно. Но разве он не уменьшает время на дальнейшую поддержку такого проекта? Ок, допустим тут мнения тоже разделятся. А почему собственно увеличивается время разработки? Это можно отнести и к другим языкам на которых сложнее писать, но которые дают большую гарантию падать в compile time, а не в runtime?

Typescript - any + fp-ts + io-ts  мне сильно больше заходит, чем js. Особенно когда дело касается обработки ошибок. чтобы не использовать исключения в бизнес логике.

Да, у меня ток приватные репы. А если конкретизировать притензии к ооп, то какие вы выделяете?

Никаких, просто в подавляющем большинстве моем случаев оно бесполезно. Для сценариев анемичных моделей, модель по сути вырождается в ТИП а операции над этим типом - в отдельный сервис. Концепция сокрытого внутреннего состояния часто приводит к сложностям поддержки, когда сущность класса ведет себя по разному и становится сложно разобрать почему так происходит. Ну то есть если взять абстрактную кодовую базу среднестатистического проекта - то у нас DTO/анемичные модели + сервисы которые не имеют состояния  в подавляющем большинстве своев. В итоге абстрактный "полиморфизм" ООП вырождается просто в иерархию типов (утрирую, есть исключения), соблюдение L из SOLID либо приводит к куче большого сложного ненужного кода, либо просто на это забивают

Мне просто кажеться что затраты на этот лишний код оправдывают себя при поддержке и развитии кодовой базы.

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

Сейчас я вижу спасение в максимально мощном механизме оперировании типами (собственно почему для проекта была взята система типов OCaml а не TypeScript) - грубо говоря когда invalid state is unrepresentable

Фронт енд я понимаю зачем писать без ооп. Тут вопросов нет. Окей, услышал, подумаю

К сожалению тайпскрипт всё больше идёт в сторону "псевдорантайм" типов (хорошо видно по направлению к 4), вместо усиления мощности системы типов

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

А что вместо? Проблема же в либах, пробывали флоу,  отказались из за того, что нигде нет их типов

это проблема курицы и яйца :) Нет внешних библиотек = нет проблем в типах :)

Як тс може замінити виключення бізнес-логіки?
Якісь тут дивні аргументи в підтримку тс ідуть. То без тестів, то без виключень)

Возможно, но затраты времени важная вещь при комерческой разработке

Согласен, и тут в дело вступает другой важный элемент :)

Когда мы пишем (а мы пишем) типы самостоятельно - мы описываем подмножество библиотеки

и в соответствии с заветами ООП - получаем на самом деле зависимость не от библиотеки, а от интерфейса который описали

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