ООП: худшее, что случалось с программированием

Когда увидел название статьи и понял, что в комментариях творится сущий ад)
Очень хороший ответ дал выше @markelov69, но у меня есть желание дополнить.

В ФП это довольно редкое явление, так как данные отделены от логики, и в большинстве случаев создание сущности какого-либо типа это просто создание стандартных структур данных, таких как строка, массив, ассоциативный массив

Непонятно, причем тут конструктор и отделенная логика. Конструктор создан для того, чтобы сохранять объект в валидном состоянии, в основном он просто инициализирует поля. А бойлерплейт код - проблема самого языка, а не ООП. Например, в PHP последней версий траблов с написанием плоских моделей нету (слава хукам и объявлениям свойств в конструкторе)

Более того, следующий пункт про то, что оказывается и использование конструкторов в ООП является антипаттерном.

Да вы что) Видно, что автор даже не понимает, про что пишет. Никто конструктор антипаттерном не считает. Да, писать в нем логику плохо, но это вообще не то, про что вы пишете дальше.

Более того, а должен ли класс вообще знать что он — синглтон?

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

Для идеальной гибкости конечно же нет. Вдруг кому то когда то понадобиться сделать синглтон не синглтоном? Такого еще в истории не было ни разу, но почему бы не написать еще больше кода, еще сильнее усложнив его.

Берешь и создаешь класс напрямую или через фарбрику. А про усложнение вообще бред: контейнер идет из коробки любого фреймворка, autowire сам подгружает нужные зависимости (Кроме случаев, когда у нас несколько реализаций интерфейса, например, тут будь добр выбирай), тебе даже делать особо ничего не надо

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

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

class User {
  update() {
    service.updateUser(this.id, …)
  }
}

// Правильно ли обновлять массив user таким образом?
// Что тут должен придумать неокрепший ум начинающего ООП-шника?
for (let user of users) {
  user.update()
}

Тут вообще смешной пример. Вызывать такие сервисы изнутри сущности - бред. Если говорить про массовый апдейт, то это делается через UOW.

В ФП тоже можно использовать собственную модель, но во многих случаях трансформировать данные либо не нужно совсем, либо минимально, так как они и там и там "тупые" и сериализуемые.

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

Я ни в коем случае не считаю фп плохим. Я сам очень много писал на реакте и рад, что застал эру именно функциональных компонентов.

Оскорбления - отдельная тема, статью будто Стас ай как просто писал, уровень дискуссии в Восточной Европе как всегда высок.