O Início do Declínio das Linguagens Orientadas a Objetos: Uma Análise da Transição para Paradigmas de Alto Desempenho

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).

Antes que digam que sou contra Go, eu programo em Go, mas lendo friamente o texto, concluo que falta muito pra ser considerando um texto imparcial e completo.

Está faltando falar, ou falta profundidade sobre:

1. Escrever código acoplado e hierárquico não é inerente ao paradgma, e sim uma escolha de quem escreve o código, é possível tomar a mesma decisão em outras linguagens;
2. As pessoas incluiem comumente dependências que nunca vão usar, deixando a aplicação final mais lenta do que o necessário, comumento esse programador costuma não entender como funciona os detalhes da linguagem, novamente é uma decisão e não algo inerente ao paradmga;
3. Código compilado nativo, mesmo escrito em linguagem OO costumam ter performance e consumo de memória reduzidos;
4. Paradgmas não bloqueantes (Netty.io, Akka que roda sobre a JVM Java), que pode ser utilizado tanto em linguagem OO ou não OO
5. No benchmark que compara a performance de algumas das aplicações mais importantes, não vemos dominância de uma linguagem ou paradigma;
6. O Modelo de Atores, estude sobre Scala, muito bem implmentado performático com baixo uso de memória existem em JAva;
7. Modelo de Multi Event Loop (Vert.X) disponível em vários paradigmas inclusive no OO (Java), escolha que junto com o paradgma reativo e não bloqueante melhora muito a performance, já que muito da lentidão está no código que bloqueia a thread;
8. Imutabilidade, outro recurso independente de paradgma, escolha que melhora muito a performance, mas que comumento é ignorado por quem escreve o código;
9. Reflection, ou introspecção recurso que as pessoas utilizam sem saber, mas existe opções de não fazer uso dele, infelizmente, em busca de entregas mais rápidas as pessoas são levadas a fazer uso por comodidade muitas vezes sem saber o que é os impactos, novamente essa é uma escolha e não é inerente ao paradgma OO já que existe em outras linguagens não OO;
10. Paralelismo, utilizar ou não é uma escolha indpendente de OO, mas é comum escolherem escrever código que é executado sequencialmente mesmo que possa ser em paralelo;

Também senti falta de falar dos trade-offs, ou colaterais inesperado ao trocar o paradgma ou linguagem.

Colocar o Bend como link depois de toda essa argumentação me soou incoerente, digo isso porque o Bend pega um nicho muito específico e melhora performance apenas para aquele nicho, outros tipos de algoritimos não consegue obter benefícios ao adotar ele. Detalhe, o próprio autor já declarou publicamente que escolheu pra linguagem uma sintaxe como a do Python, mas admite que deveria ter escolhido uma sintaxe diferente que seja mais expressiva pros novos conceitos que o Bend trás.

"...princípios como SOLID, padrões de projeto e técnicas avançadas de refatoração", não é excluvido do paradgma OO, esse é um conhecimento necessário em qualquer paradgma.

Bem, vou parar por aqui, mas gostaria de sugerir a leitura do livro: Um livro ilustrado de maus argumentos

Saudações! Que mais pessoas tenham coragem de enfrentar o status quo. As décadas de fartura de processamento chegaram a um platô. Já é evidente a busca por desempenho. Quando ouvi falar sobre WebAssembly tive certeza disso. Muitos crucificam qualquer novato que não use ou queira OOP. Isso engessa o progresso. Muitos humilharam quem valoriza linguagens de baixo nível, e vejam só, elas estão aparecendo no front :) Enfim. Nada é do dia pra noite. Mas a transição é um fato.

Assunto muito pertinente, visto a brigas pelo Rust no kernel, tem dividido os programadores antigos dos novos.

Poderia ter apenas usado a IA pra corrigir erros ortograficos, mas manter a essencia do que escreveu e pensou. A organizacao das palavras e blocos de texto sao bem visiveis feito por chatGPT o que desistimula a leitura, por não ser um ponto original do autor e sim estatisticas de uma IA.

Muito bom seu artigo, parabéns.

Sou CTO de uma empresa de IA e tendo sempre a preferir solucões tecnologicas que nos faça economizar recursos e grana.

Recentemente matei o Java da minha operação com ganho de performance na casa dos 80%, sem contar que a velocidade com que o time se adaptou ao Go foi surpreendentemente positiva.

Anos atrás, participei do inicio da adoção do Go no Mercado Livre e na ocasião escrevi esse artigo no iMasters

Espero que meus relatos praticos possam contribuir para a discução.

A impressão que eu tenho, é que ja faz 10+ anos que escuto/leio o mesmo discurso sobre OOP, vindo de evagelistas do funcional, SEMPRE os mesmos argumentos, SEMPRE um extremismo fanático desnecessario.

POO incentiva a criação de hierarquias complexas de classes, muitas vezes levando a estruturas sobre-engineered

Depende de como você usa, composição > herança. No mundo atual, de microsserviços, é bem questionavel o uso herança em um modelo, e seria BEM questionável um modelo tão complexo assim. Você pode até olhar para o passado e apontar isso, mas HOJE, não é algo defendido/suportado pela comunidade.

Estudos apontam que sistemas OO maduros tendem a acumular code smells como God Classes e Long Methods, que dificultam a manutenção e aumentam o risco de regressões

Que estudos? Estão levando em consideração repo dos anos 2000?

Além disso, a conciliação entre encapsulamento e desempenho é problemática. O acesso indireto a atributos via métodos getters/setters

Problemática? Por que sempre tão extremistas as argumentações? Java não é stack para system programming, java é stack para aplicação enterprise, mesmo que você faça um benchmark e consiga provar que esses métodos vão degradar o tempo de resposta da sua API, isso vai ser insignificante para o negócio, < 1ms.

A Crise de Concorrência e Paralelismo

Para de forçar! É totalmente possivel se trabalhar de forma 100% imutável no Java, o ecossistema é vasto, maduro, não existe crise para se trabalhar com concorrência/paralelismo, frameworks como Spring e Quarkus oferecem boas ferramentas para isso. Virtual Threads oferecem soluções MUITO mais eficientes hoje em dia.

Redução da Barreira de Entrada em Linguagens Complexas

Não entendi o exemplo de Go e o uso de IA. Golang ganhou mercado em 2017~2020 quando não existia IA. Go é uma linguagem super pragmatica, tem menos keyword que java, tem como pilar uma única forma de fazer as coisas, não enxergo Go como "linguagem complexa".

Mas falando sobre o tema em si, é verdade que temos essa redução, mas não é por isso que Rust está ganhando mercado para desenvolvimenro web, por exemplo, e sim pelos 9 anos seguidos sendo escolhida como stack "mais amada" em survey do stack overflow. E ninguem está adotando C++ para subir um novo microsserviço por causa da "redução da barreira", de onde você tirou esse dado?

Programação Funcional em Ascensão

Essa do Elixir eu to ouvindo FAZ ANOS heim. Evangelista Elixir deveria ser juntar com evangelista Scala, o discurso é exatamente o mesmo, o funcional SEMPRE está ganhando a cena... mas o engraçado é que nunca aparece.

Golang é um exemplo de stack totalmente SIMPLES, que NÃO é funcional, tem algumas CARACTERISTICAS funcionais, Go é MUITO mais verboso que Elixir, e pegou uma parcela enorme do mercado, onde o Elixir nunca chegou.

Você pode até verbalizar que Go está em ascensão, mas funcional? kkkk Parece eterno essa subida.

Desempenho em Microserviços

Se você procurar por benchmarks do vertx comparando com Go/Rust, vai ver que existem casos onde ele chega até a superar. Mas de boa, o quanto isso é relevante para a maioria das aplicações enterprise?

Segurança em Sistemas Embarcados

Não entendi a relação com OOP aqui.

Esse declinio já está sendo previsto há muito tempo, e mesmo com algumas gratas surpresas como Go e Rust, Java é top3 no TIOBE Index e top 2 no PYPL.

trabalho com java a 20 anos ... 20 anos a contra gosto usa do OO eheeheheh sempre gostei mais de proecedural e funcional, mas não pagava boletos... enfim

Obrigado pela contribuição, @lgcovizzi! Gostaria de tecer alguns comentários. Seu feedback é muito bem-vindo! :)

Vamos lá...

Você diz que um código utilizando OOP tende a ser complexo, tendo em vista que você precisa ter conhecimento em diversas boas práticas e padrões de projeto, enquanto um código mais procedural não sofre desses problemas. Sinceramente? Essa complexidade me parece estar muito mais relacionado ao escopo do projeto do que ao paradigma utilizado. Se você está desenvolvendo um projeto grande e complexo, não importa o paradigma que você prefere, você PRECISA saber boas práticas em ambos os casos para 1) não fazer bagunça; 2) criar componentes reutilizáveis e; 3) criar um código seguro e testável. Portanto não importa o paradigma, para chegar num nível de excelência, a pessoa precisa estudar e lidar com diferentes projetos durante anos. Mas e se projeto for simples? Ué, dá pra fazer um código simples com OOP também! O problema é que as pessoas quando aprendem as boas práticas começam a querer encaixar em tudo, mas tá errado.

Um outro ponto é sobre a ascenção de linguagens que não adotaram o paradigma de OOP. Cara, primeiro que as linguagens que você citou nem tem o objetivo de concorrer com .NET ou Java, tendo em vista que são tecnologias que atuam em mercados muito diferentes. A única semelhança que eu consigo enxergar é na criação de serviços para servidores, na qual o ASP.NET não fica muito atrás não. Não é porque Go consome menos recurso (uma vez que não tem um GC) que isso irá necessariamente se traduzir em performance bruta. Justamente pelo fato do C# compilar para o .NET Runtime, é possível realizar otimizações que um programa 100% compilado para machine code não conseguiria, já que ele não consegue "observar" como a sua aplicação está rodando durante a execução. Não atoa a cada release do .NET sempre tem uma seção dedicada as otimizações. E mesmo que você queira muito que o seu programa seja compilado para assembly nativo da CPU, desde do ASP.NET 8 é possível compilar os serviços usando um AOT compiler. Será mesmo que a hegemonia dessas linguagens está ameaça? Olha, eu acho que não. Isso porque eu não entrei na questão do ecossistema e do tooling dessas linguagens, que são pontos que não devem ser ignorados.

Eu acho excelente ter ferramentas especializadas, porque com isso obtemos a capacidade de criar projetos melhores. Mas falar em fim da hegemonia? Acho um pouco sensacionalista haha.