concordo com a parte de que existem problemas, não existe bala de prata na programação, mas tem muito coisa equivocada no seu post, o maior problema no seu argumento é colocar o paradigma, implementação e padrão de mercado com se fosse a mesma coisa, vamos por parte:
- "A primeira razão para ignorar OOP é que isso leva a um desempenho ruim", desenpenho depende de implementação.
- DoD de fato é uma tecnica eficiente pra lidar com dados, tem seus proprios pontos fracos e fortes, nenhum dos links critica OO em si, apenas apresenta soluçoes mais adequadas para um problema especifico, o que é algo normal, OO n é bala de prata, obviamente n serve pra tudo
- DoD não subistitue OO, na verdade eles são otimos juntos
"outra razão é que vários livros tentam corrigir POO"
onde isso? ele não corrigem OO, eles apresentam sugestões para resolver problemas modernos, coisas atualizam, problemas de 1994 não são os mesmos de hoje.
"não adotam explicitamente a POO"
não existe explicitamente OO, imagino que voce esteja falando de Java/C#/C++ aqui, Zig, Go e Rust não tem esse estilo porque C++ ja deixou mais do que claro que implementar essas features pode acabar limitando linguagens de sistema, aqui estamos falando de regras de inicilização, vtables,lifetime,...etc, detalhes de implementação de cada lang, não de OO.
(e Erlang usa a definição de Alan Kay, é bem mais fechada que a definição do GoF)
"Alguns defensores da POO afirmam que a POO é mais adequada para softwares grandes e complexos. Esta afirmação é um absurdo completo"
SIM, EXATAMENTE ISSO, DECLARAÇÃO PERFEITA.
"Existem muitos projetos não-OO grandes, complexos e bem-sucedidos: Git, Linux, Redis, Nginx, Postgres e SQLite."
.....
"Você pode escrever software grande, complexo e bem-sucedido em qualquer paradigma, até mesmo assembly!"
SIM, EXATAMENTE ISSO, DECLARAÇÃO PERFEITA
essa linha do meio não da, se fosse só o inicio e o final ficaria simplismente perfeito, sabe porque? pq isso aqui é vdd "desenvolvedor
fez mais complicado do que precisa e não é culpa da POO."
Não é o OO que deixa complexo, pq não é o OO que resolve o problema, quem resolve é voce, desevolvedor, é sua função como Dev de levantar requisitos, é sua função como Dev colocar os tradeoffde cada implementação na balança, é sua função como Dev ser um Dev.
os codigos "Não-OO" que vc citou, são otimos exemplos do bom uso de OO, eles usam conceitos desse paradigma, pq tem utilidade e é simples se usado de forma correta, que nem qualquer coisa
(https://lwn.net/Articles/444910/)
em Padrões de Projeto eu não vou nem comentar, cai no mesmo que eu disse acima sobre a obrigração como Dev, voce que tem que avaliar e modificar da melhor forma para sua aplicação, esses livros de Padrões de Projeto são sugestoes, não regras.
(e o codigo que refatorou é um codigo feito para aprendizado desses conceitos, não é o escopo do projeto o uso de outras tecnica)
"POO tornou-se amplamente utilizado devido à popularidade de C++ e Java, não porque seja inerentemente bom."
isso aqui é só meteção de loko, porque que Java e C++ é popular ent? meter esse papo em TI não cola, C++ com quase 4 decadas de historia, Java vire e mexe quebra a retrocompatibilidade com alguma coisa, é a desculpa perfeita pra troca de lang
se não tivesse vantagem Java taria morto ja.
"POO não oferece nenhum benefício que as pessoas dizem. O código procedural é tão flexível, modular e reutilizável quanto OO."
os "não-OO" ai de cima que diga né