Тут не нужен дебаггер. Тут нужен семплирующий профайлер.

да, накатим на прод, начнется постепенная деградация, начнет вся система уходить в тормоза, найдем один из 10ка профайлеров на горячую систему... Второй путь, до прода все обвесим тестами, а потом на прод. с попыткой тесты подчистить. Или все же привести культуру писать код, проводить его итерацию автором, ревью, дебаг, рефакторинг, тестер проверяет и только потом на ПРОД. И вот если тогда что то пошло не так, подключаем профайлеры.

*Я не против ТДД, тестов от разработчика. Я против 100% покрытия, упоротости в "функциональное" где оно не нужно.

Вообще умение отличить нужное, от ненужного - это имба скилл))
Кстати для архитектора ИМХО мастхэв)

как умиляет "простота" функционального программирования в семплах. А когда горячую задачу даешь, сначала на ооп (это в лучшем случае) пишут класс, в два раза больше, а потом в "мейне" вызовут его в стиле функционального — прям сказка код! а как работать потом со спрятанным под капотом не пойми чем. Притом что реально норм, если это тула какая ни будь (для них кстати уже все описано под компилятор обычно, даже городить не нужно), а если кусок бизнес части приложения?

Не надо искать профайлер - он должен быть штатно в языке ;) и код на проде всегда под профайлером, так что hot paths известны. В отдельных случаях perf record/report/stat + dwarf

Но это именно сценарии, когда что-то непонятное.

А так, достаточно разных всяких тестов.

Как у них там, с сайд эффектами. Чтобы в базу данных данные заинсёртить монады нужны

Мы сами себя захотели обмануть и придумали монады

Функциональщина удобна для решения расчётных задач, особенно если их нужно масштабировать

Код на проде под вечным профайлером это шутка надеюсь?

Я тоже надеюсь, но как говорится, какие паттерны, такие и инструменты наверное. Хотя обычно всем просто плевать. Да и мало тех профпйлеров, что "на горячую" работают. Так что утопия. Выкатят код на прод, не падает часто и на том хорошо, а юзеры на то и юзер что бы страдать.

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

Гы. Холивар детектед.))))))

Нет, не шутка. Вот у Гугла есть

https://cloud.google.com/profiler/

А до этого они публиковали https://research.google/pubs/pub36575/

Семплирующий профайлер - это импакт не больше нескольких % cpu

На процесс. Плюс расходы на старт-стоп. В принципе можно, но это рост стоимости ресурсов.
А так при условии, что мы готовы за это заплатить.

Я уже говорил, что цена вопроса +несколько %cpu

а это мало?

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

А те кто в пятерке, опять же +-, явно не рекомендованы на "горячей" держать. Все равно прерывания вызывают они все. А так же начнется что либо накапливаться (назовем это коллизии, в том числе и от профайлера), и если вовремя не заметить — деградация производительности обеспечена. А вовремя обычно никогда не замечают.

ТДД - это больше о дизайне, а не о тестировании. Есть у Kent Beck слова, где он говорит о том, что TDD - это не о тестировании. Тесты просто позволяют фокусироваться на одной обязанности, осуществлять поиск решения путем обобщения и триангуляции. Это снижает нагрузку на мозг и позволяет быстрей найти удачное решение.

В сериале "Is TDD Dead?" Kent Beck говорит о том, что 100%-е покрытие и не требуется. Покрытие должно быть достаточным для обретения уверенности. Более того, тесты должны облегчать рефакторинг, а не сковывать его, поэтому тесты не должны покрывать реализацию, иначе они превратятся в оковы.

По поводу парадигм - разные парадигмы имеют разные превосходства в разных контекстах. Есть у B.Meyer замечательная статья, в которой он пишет, что используя принцип CQS мы обретаем возможность пользоваться превосходствами обоих парадигм ситуативно, в зависимости от контекста, т.е. OOP отлично сочетается с FP.

Кстати, рассвет TDD пришелся на этап становления OOP, причем, в динамических языках. Возросший уровень косвенности и отсутствие современных статических анализаторов затрудняли навигацию в коде и разработку без TDD. Я застал времена, когда нужно было в консоли емакса объявлять переменную, чтобы её тип подхватился в буфере редактирования файла с Python-кодом. И я был одним из тех, кто добавлял в emacs типизацию (вернее, Type Hinting) для Python, в то время еще через docstrings. Это уже позже в Python появилась типизация через аннотации.

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

По личному опыту могу сказать, что при использовании TDD я отладчиком практически не пользовался. Да и вообще, если есть юнит-тесты, а не только ТДД, то потребность в отладчике сильно сокращается, и это хорошо, потому что время на написание тестов можно прогнозировать, в отличии от отладки. Кстати, в большинстве случаев время на написание тестов полностью перекрывается повышением темпов разработки, т.е. разработка с тестами получается даже быстрей. Пальцы работают больше, а голова меньше. Происходит просто перераспределение составляющих разработки.

Спасибо за развернутый комментарий)

Может, найдется ссылка на статью B. Meyer?
По ключевым словами находятся короткие статьи с упоминанием его книги на тысячу страниц “Object Oriented Software Construction”. В этих статьях упомянуто, что методы изменяющие состояние не должны возвращать результат, а функции, возвращающие результат, не должны изменять состояние. Полновесного рассказа о том, как это отражается на ФП vs OOP не видно (хотя направление, мне кажется, понятно).