Eu gostaria de entender os negativos que esta postagem recebeu, se a pessoa puder comentar ajudaria muito o autor, a mim e muitos outros.
A impressão que me deu, mas posso estar errado, é que o negativo foi só um "não era o que eu queria ouvir" e mesmo sem entender do assunto a pessoa classificou como ruim. Veremos. Esse fenômeno vem acontecendo cada vez mais, mostra uma baixa de qualidade da audiência. Eu recebi negativos em https://www.tabnews.com.br/maniero/38b96bc0-975d-4b02-b042-615a922a96f2 quando eu não quis pagar de psicólogo e fui realista, enquanto que respostas que "agradavam" foram bem, mesmo que não resolva o problema da pessoa.
Alguém pode ter achado que foi feito pelo ChatGPT. Me pareceu que não, apesar de que pode ter sido auxiliado ou pelo menos usado um prompt muito bem definido. Mas ainda fala de algo pouco explorado, que foge do senso comum, da modinha, então seria menos provável. De qualquer forma não tenho nada contra usar uma ferramenta que ajude desde que o resultado seja bom, e foi.
Não que eu concorde com tudo o que está escrito aí. Mas de fato OOP é sobrevalorizado. E é mais por quem sabe menos sobre ele e a computação. É fato que linguagens modernas estão abandonando a ideia. Nem acho que é 100% bom, porque OOP é útil e em alguns casos pode ajudar o código ficar mais interessante, e da mesma forma que eu acho que toda linguagem deveria ter goto mesmo que ele fique anos sem ser usado, talvez os outros mecanismos deveriam existir também, quando ele é útil. Mas eu entendo os criadores, porque complica bastante a linguagem, o compilador, deixando-o mais lento, e acaba incentivando as pessoas a usarem onde não deve, já que quase todo mundo aprendeu usar e ouvem o tempo todo que se você não usar OOP está fazendo errado, o que é uma enorme falácia, desmentida por vários projetos enormes e de muito sucesso.
A primeira seção depois da introdução fala uma verdade que é dolorosa para alguns, o que cria um negacionismo.
A seção seguinte não é primorosa, mas toca em um ponto relevante.
Quando começa falar das limitações poderia ir mais a fundo, há muito mais code smells em OOP do que o citado, mas compreendo que isto não é uma tese, nem mesmo uma monografia. Muitos code smells existem porque algumas pessoas ensinam como "boas práticas", por isso meu primeiro vídeo no meu canal se chamará "A péssima prática de seguir boas práticas".
De fato, as linguagens irem um pouco mais para o lado funcional é algo bom, mas eu, apesar de ter um carinho por essas linguagens, não acho que linguagens realmente funcionais sejam um caminho bom para a maioria dos problemas. Nem tão pouco acho que a maioria dos problemas precisam tanto assim da concorrência. E existem várias maneiras de obter a concorrência de forma mais simples do que se ensina por aí. Linguagens funcionam tendem a ter uma certa ineficiência e não é qualquer padrão que ela tem um ganho claro, e onde tem esse ganho fácil técnicas simples podem ser usadas sem medo. Mas o ponto colocado ali é válido, OOP realmente incentiva algo ruim que poucos falam. Mudança de estado é uma das coisas que mais causam bugs em aplicações, as pessoas falam de outras coisas bem menos importantes, por isso a base do meu canal será desmistificar muitos dessas coisas, além de falar de coisas que ninguém fala, sobre a s história da computação, curiosidades, mercado, back to the basics, formar a pessoa como um todo para ser dev de primeira linha, saber um pouco do baixo nível, sobre negócios e sua automação, além de falar de C#, claro.
Apear de gostar das linguagens não acho que Rust seja tudo o que alguns acham, ela tem enormes benefícios, mas traz alguns problemas novos e ela não concorre com Java ou C#, mas sim com C e C++ (menos), e Zig pode ser uma opção melhor (não OOP). Go é bacana, gosto de muitas coisas dela, principalmente da implementação, mas não vejo ela como uma solução definitiva. Eu acho que as pessoas usam por falta de algo melhor, que pode ser feito.
Um problema das linguagens que já são "maior de idade" é que elas foram construídas no meio do hype de OOP, do "máquina vai sempre melhorar", precisa rodar em todo lugar, precisa de uma plataforma melhor que o COM para interagir com outras linguagens, a biblioteca precisa ser estilo enterprise, e tudo isso tem seus méritos, mas também deméritos. Eu queria algo moderno, poderoso, performático, mais simples. Go chega perto, mas ainda não é a solução. Eu queria um C## (o experimento M# está indo na direção certa, pena que não viu a luz do dia). Eu diria que estão fazendo um trabalho extraordinário para melhorar C#, mas só onde não quebra compatibilidade, o que limita bastante. C## (nome bobo) teria uma pegada de C#, mas iria mais para o que é F# (que também é OOP, mas é desincentivado e as pessoas suprem), mais perto de C++ do que já é, sem os erros cometidos (quase todos copiados de Java).
Acho Exlir e Erlang sensacionais e queria ver algumas ideias copiadas em outras linguagens, inclusive ter uma opção de rodar em algo melhorado em cima do BEAM, mas não acho que elas em si deveriam ser mainstream.
Na parte que a IA ajudando a programar em linguagens complexas e melhorar o legado, tem um fundo de verdade, mas também acho que tem um pouco de "viagem" nisso também, a maioria não tá nem aí, não sabe usar certo, e ela tem muitas limitações para ajudar de forma importante, ela até pode servir para dar produtividade na mão de alguém bom, mas pouco ajuda o cara ruim, pelo menos não ajuda muito no objetivo que o texto cita, e pode atrapalhar no processo, que é minha experiência e de várias pessoas que conheço (programadores experientes). Pode mudar um dia.
Não sou muito fã de certos benchmarks que muitas vezes tentam direcionar para determinados caminhos. Não tenho dúvidas que em alguns cenários Go trará algum benefício (mas ali em cima mostra que nem é tanto assim) em relação à Java, e pode ser que uma refatoração em Java resolveria o problema. A mesma comparação com C# provavelmente não daria esse resultado, em benchmark considerado livre de vieses C# costuma estar no meio do topo, à frente até mesmo de muita implementação em C++, Rust, e principalmente Go. E eu acho que tem espaço para C# melhorar, ainda que em alguns casos para obter isso teria que usar algumas coisas diferentes e incompatíveis. Não tem algo fundamental em Go que permita ele ser mais rápido que não possa ser reproduzido, mas sei que não é fácil fazer isso em algo com muito legado. Dá para fazer algo muito melhor que Go. V tentou e deve conseguir algo melhor, mas não tanto quanto se prometia. V não pode ser levada a sério só porque seu criador é um mentiroso, nunca admite erros, mesmo depois de consertá-los, e por isso a evolução não seria confiável. Alguém com capacidade que pegasse a ideia, quem sabe começasse de um fork dele, e conseguisse formar uma comunidade que inacreditavelmente ele conseguiu, poderia fazer uma linguagem maravilhosa. O GC de Go não é essa maravilha que "vendem" por aí, se fosse, os outros começariam mudar para ser igual, já que isso não quebra compatibilidade, ele é bom sob certas circunstâncias, outras coisas na linguagem auxiliam mais.
A adoção de Rust por segurança é algo bom, mas a maioria está adotando por modinha, mesmo que alcance o resultado. Não vale a pena jogar tudo fora em C++ quando tem ferramentas que ajudam dar a mesma segurança que Rust dá de forma mais simples para programar (apesar de complicar um pouco o processo todo). A maioria dos programadores de C++ não estão indo para Rust, quem vai é obrigado politicamente ou são pessoas que agora estão entrando no baixo nível. Não sou contra esse movimento, só contra o exagero. Existem várias anedotas, verdadeiras, mas não um estudo comparando bananas com bananas mostra que Rust é o único caminho.
Não gosto de chamar OOP de legado. E é fato que várias linguagens estão adotando o estilo funcional, como Java e C#. Mas ao mesmo tempo algumas linguagens estão adotando sem a necessidade. Em Javascript mesmo vejo demais o abuso do estilo sem ganho algum, e até com pioras. É mais um caso de "boa prática" péssima.
Discordo totalmente que linguagens ligeiramente mais pesadas que as linguagens de um pouco mais baixo nível vão tomar o lugar das linguagens mais enterprise, até porque elas estão se mexendo, e esses sistemas nunca precisaram disso tudo. E se for para pensar tanto assim na performance, que eu adoro que pense, parariam de fazer sistemas web que gera uma ineficiência absurdamente maior que essas linguagens de nível um pouco mais alto, ou passaria adotar o SQLite como banco de dados em muitos lugares onde ele cabe (por sorte estão vendo cada vez mais casos de grandes implementações gigantescas e high profile o usando e mostrando que eu não era louco quando falava disso há mais de 10 anos atrás), e o ganho que pode ter com ele ou outras opções eficientes podem ser bem maiores que trocar Java por Rust.
Toda linguagem tem um pouco de adoção e depois começa uma queda, algumas mais que outras, eu acho que Java será mais por causa de Kotlin, mas acontecerá com C#, como acontece com tudo, desde C. Acontece com JS e tantas outras, e acontecerá com Python.
Algumas linguagens estão surgindo e terão um papel fundamental em certos nichos, nada mais que isso. Espero que outras surjam para desafiar as linguagens mais populares e entregiem algo claramente melhor para a maioria dos cenários.
OO nem é paradigma principal, depende de outro mais importante, segundo vários autores, só tem essa divulgação por marketing, ofuscando onde realmente as pessoas deveriam. Boa parte dos assuntos em artigos de primeira mão e alguns de segunda, em palestras, se fala de coisas que apenas 0.1% das pessoas precisam, mas 10% acabam adotando porque "puviram falar que era boa prática", piorando o que está fazendo e gerando emprego pra muita gente para cuidar do trambolho que criaram.
Eu tenho esperança que seguiremos um caminho melhor, mas pragmaticamente não espero muito, o normal é o mercado adotar a coisa errada. Aprende errado, treina o erro, e passa para frente para mais pessoas errarem.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).