Executando verificação de segurança...
29
lgcovizzi
5 min de leitura ·

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

A programação orientada a objetos (POO) dominou o desenvolvimento de software por décadas, oferecendo uma abstração intuitiva ao modelar entidades do mundo real em classes e objetos. No entanto, evidências recentes apontam para uma mudança de paradigma: linguagens compiladas e funcionais, como Rust, Go e Elixir, estão ganhando espaço em detrimento das tradicionais linguagens OO, como Java e C#. Esse movimento é impulsionado por avanços em modelos de linguagem especializados, que reduzem a curva de aprendizado de linguagens complexas, e pela demanda por sistemas de alto desempenho em áreas como computação em nuvem, IoT e inteligência artificial. Este artigo explora as raízes históricas da POO, suas limitações intrínsecas e o cenário emergente que desafia sua hegemonia.

A Abstração como Ferramenta Pedagógica

A POO surgiu como resposta às limitações da programação estruturada, oferecendo um modelo mental supostamente mais alinhado à percepção humana de objetos e interações. Conceitos como encapsulamento, herança e polimorfismo prometiam organizar o código de forma modular, facilitando a manutenção e o reúso. Essa característica a tornou popular em cursos introdutórios, onde a analogia entre "objetos do mundo real" e classes simplificava o ensino.
No entanto, essa simplicidade inicial esconde uma complexidade crescente. Projetar sistemas OO robustos exige domínio de princípios como SOLID, padrões de projeto e técnicas avançadas de refatoração—habilidades que demandam anos de experiência. A ilusão de que "objetos são uma forma natural de pensar" desmorona quando problemas de acoplamento, hierarquias rígidas e vazamento de abstrações surgem, exigindo intervenções custosas.

A Hegemonia Corporativa das Linguagens OO

Linguagens como Java e C# consolidaram-se no mercado corporativo devido a fatores além do mérito técnico. O ecossistema de frameworks (Spring, .NET), a vasta documentação e a compatibilidade com sistemas legados criaram um ciclo de retroalimentação: empresas adotavam essas linguagens porque eram populares, e eram populares porque empresas as adotavam. A curva de aprendizado relativamente baixa, comparada a linguagens como C++, permitiu que equipes heterogêneas colaborassem em projetos de grande escala, mesmo que às custas de eficiência.

As Limitações Estruturais do Paradigma OO

Complexidade de Design e Acúmulo de Dívida Técnica

A POO incentiva a criação de hierarquias complexas de classes, muitas vezes levando a estruturas sobre-engineered. O princípio de herança, embora útil, frequentemente resulta em acoplamento rígido e fragilidade—alterações em classes base podem quebrar funcionalidades em dezenas de subclasses. 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.
Além disso, a conciliação entre encapsulamento e desempenho é problemática. O acesso indireto a atributos via métodos getters/setters, embora garanta abstração, introduz overhead desnecessário em cenários de alta performance—um problema crítico em aplicações de tempo real ou processamento massivo de dados.

A Crise de Concorrência e Paralelismo
A revolução multicore dos anos 2000 expôs outra fraqueza do modelo OO tradicional. Gerenciar estado mutável em objetos compartilhados entre threads é propenso a race conditions e deadlocks. Padrões como Singleton, outrora celebrados, tornaram-se antipadrões em ambientes concorrentes. Linguagens funcionais, com seu foco em imutabilidade e funções puras, oferecem uma alternativa mais segura e escalável para sistemas distribuídos modernos.

O Surgimento de Paradigmas Alternativos

Linguagens Compiladas e o Retorno ao Desempenho
Rust e Go emergiram como alternativas viáveis ao C++ e Java, combinando desempenho próximo ao hardware com modernos sistemas de gerenciamento de memória. Rust, por exemplo, elimina trade-offs entre segurança e velocidade através de seu sistema de ownership, garantindo memória segura sem garbage collector. Go, por sua vez, prioriza simplicidade e concorrência eficiente com goroutines, resolvendo problemas que exigiam frameworks complexos em Java.

Programação Funcional em Ascensão

Elixir, baseado na máquina virtual Erlang (BEAM), oferece tolerância a falhas e escalabilidade horizontal nativas—características críticas para sistemas de telecomunicações e aplicações web de alta disponibilidade. Seu modelo de atores simplifica a concorrência, contrastando com a complexidade de frameworks como Akka em Scala.

O Papel dos Modelos de Linguagem Especializados

Redução da Barreira de Entrada em Linguagens Complexas

Ferramentas como GitHub Copilot e ChatGPT estão transformando a maneira como desenvolvedores interagem com linguagens de baixo nível. Ao sugerir snippets de código, otimizar algoritmos e até reescrever funções entre paradigmas, essas IA compensam a suposta "dificuldade" de linguagens como Rust ou C++. Um desenvolvedor pode agora escrever código em Go com orientação em tempo real, reduzindo a necessidade de meses de estudo prévio.
Refatoração Automatizada e Gestão de Legado

Sistemas legados em Java ou C# estão sendo modernizados com assistência de IA. Modelos de linguagem identificam code smells, propõem refatorações e até convertem código OO para estilo funcional—um processo que antes demandava equipes especializadas. Isso permite que empresas migrem gradualmente para linguagens mais eficientes sem interromper operações críticas.

Estudos de Caso: Java vs. Go e Rust

Desempenho em Microserviços

Um benchmark realizado pela Cloudflare em 2024 comparou APIs REST implementadas em Java (Spring Boot) e Go. O resultado mostrou que Go consumia 40% menos memória e respondia a 2x mais requisições por segundo, graças à sua runtime leve e coleta de lixo eficiente. Empresas como Uber e Twitch migraram partes críticas de seus backends para Go, relatando reduções de custos em infraestrutura de até 30%.

Segurança em Sistemas Embarcados

A indústria automotiva, tradicionalmente dependente de C++, está adotando Rust para sistemas ADAS (Advanced Driver Assistance Systems). A garantia de segurança de memória em tempo de compilação eliminou vulnerabilidades comuns em softwares como freios autônomos e controle de estabilidade.

O Futuro das Linguagens de Programação

A Convergência de Paradigmas

Linguagens modernas como Kotlin e Swift ilustram uma tendência de hibridismo: incorporam elementos funcionais (imutabilidade, funções de primeira classe) enquanto mantêm compatibilidade com ecossistemas OO legados. Essa abordagem pragmática permite uma transição suave para novos paradigmas sem descartar investimentos anteriores.
A Priorização de Desempenho sobre Popularidade
Com a computação atingindo limites físicos (Lei de Moore), otimizações de software tornaram-se cruciais. Linguagens que oferecem controle fino sobre recursos hardware, como Rust e C++, estão sendo reavaliadas mesmo em domínios tradicionalmente dominados por Java, como enterprise software.

Conclusão

O declínio das linguagens OO não é um fenômeno abrupto, mas uma transição gradual alimentada por demandas técnicas e avanços tooling. Enquanto Java e C# permanecerão relevantes em sistemas legados, seu domínio em novos projetos está sendo desafiado por alternativas que priorizam desempenho, segurança e concorrência. A ascensão de modelos de IA como facilitadores dessa mudança sugere um futuro onde a "melhor ferramenta para o trabalho" prevalecerá sobre inércia tecnológica, marcando o fim da era de ouro da POO como paradigma universal.
Neste sentido, há muitos canais que fazem comparação entre linguagens, e é um convite ao pagamento da dívida técnica.

Para se inspirar:

Canal de comparação entre linguagens:
[Anton Putra] (https://www.youtube.com/watch?v=PL0c-SvjSVg)

Desenvolvedor brasileiro Victor Taelin, é o criador da linguagem de programação Bend:
[Fireship] (https://www.youtube.com/watch?v=HCOQmKTFzYY)

Carregando publicação patrocinada...
6
maniero

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

1
nataferreiradev

Sobre o fato dos likes e deslikes ainda sou novo na plataforma e não sei oque está acontecendo, mas sobre o assunto principal da publicação, acredito que POO fez e tem feito a estruturação das maiores ideias de programação, ideias que podem ser e serão adaptadas por liguagem em outros paradiguimas, afinal livros como desing patterns e refactoring não podem morrer em detrimento ao paradiguima no qual foi idealizado e devem ser adaptados, a minha duvida para as futuras linguagens é saber se elas possuirão um padrão de linguagem assim como as orientadas a objeto possuem. Tenho me aventurado em golang e vejo que posso trazer parte de meus estudos de orientação a objeto para esse ambiente alterando alguns conceitos e ignorando a parte critica da orientação a objetos que é a herança.

-1
maniero

É uma crença interessante.

Design pattern nem é o que as pessoas acham que ele é, tem muita informação errada por aí porque tem muita gente querendo views venda de livros com títulos chamativos, mesmo que dentro tenha muita coisa falsa ou pelo menos misleading, vender cursos, palestras, etc. A esmagadora maioria consumo sem entender o que está fazendo, sem questionamento, sem pesquisa extra para confrontar fontes, sem usar método científico, e só vai piorar com a IA.

As linguagens não são orientadas a objeto, nem mesmo Smalltalk que foi toda criada em cima disso não é, e até seu autor diz que Lisp, que é funcional, é mais orientada a objeto que a criação dele. Ele inclusive diz que criou o termko mas se referia a outra coisa que as epssoas usam. Sem nem saber o que é OO fica complicado aplicar. As linguagens são em sua maioria imperativas, alguns poucas de outras forma, poucas funcionais, e algumas tem uma pequena parte dela, menos importante que facilita fazer a tal orientação a objeto, então não podemos falar que a linguagem é orientada a objeto.

As linguagens continuarão ser imperativas, cada vez mais com mecanismos das funcionais, sem mudar o paradigma e aqui e ali terão paradigmas secundários (que alguns dizem que sequer deveria chamar de paradig ma, de tão secundário que é), algumas serão melhores para lidar com vetores de dados, outras com concorrência massiva, muitas delas mais funcionais, terão aquelas focos mais específicos, como robustez e contratos fortes, orientadas a eventos, etc. Nem a IA que pedia uma linguagem com um paradigma diferente existente (lógico) há muitas décadas fez esse paradigma ganhar destaque e aprendermos programar com predicados.

Curiosamente você fala da herança da orientação a objeto, que eu digo que é o que realmente diferencia esse paradigma, que só ele tem. Muitos puristas de OO dizem que não é isso, que é outra coisa, alguns dizem que é o encapsulamento por exemplo, algo que tem em outras linguagens. Negacionismo tem em todo lugar. Há discussão se a linguagem x ou y tem ou não os mecanismos necessários para ser OO, alguns não falam se tem, mas se a linguagem é, que é um erro, conforme eu expliquei.

Temos que aprender com fatos, quase tudo que usam em OO hoje é criticada e até não recomendada por muita gente, com fortes argumentos, começando pela herança. E olha que eu nem sou tão radical assim.

1
walacysilva

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.

Essa parte é uma verdadeira raridade na internet! kkkk encontrar alguém que veja a inutilidade de Rust quanto salvador do mundo contra o C/C++. Se você se aprofunda em C++ sabe que não se codifica mais como antes, você não está mais em 1980! Aliás, C++ já deixou de ser um braço de C faz um bom tempo... smartpointers, modulos, conceitos... tudo que o Rust faz é liberar a memoria, coisa que os ponteiros do C++ já fazem sozinhos também. A diferença está nos binarios maiores do rust e no tempo de compilação(por conta das regras do rust, claro). Aliás, o C++ aceita o paradigma funcional, mas isso é bem avançado e ainda não cheguei a ver kkkkk obviamente não é para sair criando software critico em funcional no Cpp né!

As pessoas simplesmente estão largando tudo e correndo pro outro lado sem se aprofundar, sem entender, e principalmente, sendo excludentes! Quem disse que não posso aprender Python só porque programo em Javascript??

Concordo muito com a parte que fala de adoções inpensadas, simplesmente porque todo mundo está adotando.

2
maniero

Concordo com quase tudo, mas Rust não é inutil, só não é tão útil quanto alguns acham. Mas a maioria sabe o tamanho certo. Na verdade apesar de todo o burburinho, a maioria dos programadores iniciantes que falam que vão aprender Rust, desistem muito rápido, eles mal conseguem apender JS ou Python direito. Os programadores de C e C++ sabem que Rust não substitui 100% essas linguagens e que elas possuem soluções, então a maioria continua neles. Existem os casos que faz sentido a pessoa mudar, fazem um barulho tremendo, mas ainda é pouca gente. Vai aumentar porque Rust tem sua função, vai tirar um pouco do mercado das linguagens deceniais de nível um pouco mais baixo que a maioria.

C++ aceita alguns mecanmismos que ajudam um estilo mais funcional, mas ele é essencialmente imperativo mesmo, não adota o paradigama funcional, assim como Rust e tantas outras não adotam. Esses paradigamas são basicamente excludentes na sua totalidade.

Eu até gostaria que o comitêde C++ fosse mais radical e aceitasse certas propostas feitas, de uso opcional, mas com flags no compilador que fariam C++ o que é, manter suas vantagens e ser mais do que Rust entrega :), tá lá só esperando a coragem. A última até falam em C++2 que não será aprovada nunca, porque no fundo vira outra linguagem, concorre mais com Carbon, mas também traz as vantagens de Rust.

1
Pilati

A impressão que me deu, mas posso estar errado, é que o negativo foi só um "não era o que eu queria ouvir"

É exatamente isso. Pessoas novas na plataforma usam os votos como like e dislike. Não como a proposta inicial da ferramenta. O que tende a ocorrer é que os votos da publicação normalizem mais tarde.

2
Oletros

Meus 2 cents:

Eh um texto claramente feito por IA - em diversos momentos usa termos diferentes para falar da mesma coisa ou mesmo na construcao da argumentacao.

O assunto pode ate ser pertinente - mas teria de ser feito por uma pessoa. Ficar discutindo texto espirrado por maquina acho o cumulo.

Nao que textos criados por IA nao sejam uteis - mas este eh um forum de debates, entao que pessoas debatam.

Ficam criticando o uso de IA para programacao - mas babam ovo para um texto escrito por IA.

4
Pilati

Nao que textos criados por IA nao sejam uteis - mas este eh um forum de debates, entao que pessoas debatam.

Pode até ser feito por IA, mas não é o padrão escrito pelo GPT depois do prompt "escreva um texto sobre tal assunto". O autor no mínimo se esforçou pra deixar um texto legível e congruente.

Devemos mesmo dar negativo apenas porque o autor usou uma ferramenta?

Ficam criticando o uso de IA para programacao - mas babam ovo para um texto escrito por IA.

Não vejo ninguém criticando o uso. Vejo apenas críticas quando a ferramenta é mal usada.

Eu pessoalmente critico quem usa IA da mesma forma que vejo código feio e mal feito. Se o resultado ficou bom tem seu mérito

-4
Oletros

Meus 2 cents extendidos:

Devemos mesmo dar negativo apenas porque o autor usou uma ferramenta?

Sim, devemos.

IA eh apenas um analisador semantico que cospe texto baseado em estatisticas - cada palavra eh baseada estatisticamente nas palavras anteriores e vai formando o fluxo. As vezes da certo. As vezes da muito errado.

Uma pessoa razoavelmente treinada/acostumada percebe os padroes que a IA usa em textos - o caso aqui eh bem identificavel. Mas para nao parecer injusto, submeti o texto a 5 detectores de IA diferentes e a reposta de todos foi unanime: IA (variando de 80% a 90%)

Qual o problema disso ? O autor acaba escrevendo textos verborragicos sem necessidade (a IA costuma ser bastante prolixa) - e que no final das contas sao apenas juntados de outros textos obtidos no treinamento, ou seja, nao constituem uma opniao e/ou experiencia de usuario, mas uma saida puramente estatistica que parece fazer sentido.

Este eh um forum de debates: nao eh sobre estar certo ou errado - mas sobre as vivencias e experiencias de cada um. Ainda que ache alguns autores verborragicos e chatos de galocha, sao pessoas que estao colocando aquilo que viveram e portanto merecem respeito - ate porque permitem que os novatos tenham contatos com estas experiencias.

O texto baseado em IA mata isso - eh apenas alimento para o ego e vaidade do autor receber 'upvotes' e se sentir importante, quando na verdade nao produziu de si nada de valor real.

Usar IA para correcao, checagem de referencias - de boa. Criar mais de 70% do texto via IA ? Eh no minimo uma falta de respeito para com os leitores.

2
claytonpassos

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

2
maniero

OOP incentiva um certo acomplamento, se a pessoa não faz, ótimo, mas ela está se afastando do paradigma. E se ela evita a hierarquia, que pode ser boa em alguns casos, ela está abandonando o paradigma, porque herança é o único mecanismo que só OO tem.

É fato que o maiuor problema é o programador do que o paradigma, mas ele contribui para a pessoa ser assim, e ele existe para as pessoas que são assim. Os melhores programadoes não precisam de OO para ajudá-lo se organizar. Quem precisa disso é o medíocre. O ruim nada salva.

OO de fato não adicionar muito custo de processamento e consumo de memória, mas nao é custo zero. Tem muitas outras coisas que contam absurdamente mais, incluindo a capacidade de otimização do compilador e/ou runtime, algumas outras features da linguagem, o jeito que a pessoa programa e como é o gerenciamento de memória ou a qualidade do GC e o viés que ele busca mais.

OO é um paradigma secundário, como tantos outros, e eles não são escludentes, só os raros primários são excludentes, e mesmo assim dá para ter alguns mecanismos de um em outro, mas não o todo.

Imutabilidade dificilmente melhora a performance, a não ser quando facilita a vida do criador do GC (se imutável seja obrigatório). Tem casos, mas o que acontece mais é na verdade degradação de performance por imutabilidade, pouca, mas acotece porque cópias passam ser necessárias onde a mutabilidade evitaria. E o grosso dos programadores não se atentam a isso, até porque geralmente não precisam que tenha a melhor performance. Tem padrões que fazem o GC trabalhar absurdamente mais.

As pessoas sequer entendem o que é design patterns, eu botei link em outro comentário meu aqui na página. SOLID é só um nome bonitinho para falar sobre coesão e acoplamento.

O texto de fato é incompleto e falho, mas é uma boa base para gerar alguns debates. Msmo sendo imperfeito ele criou conteúdo relevante aqui mais do que a soma de vários outros nos últimos dias somados. Seu texto ajudou muito nisso, então a missão dele está cumprida.

Eu já conhecia os "maus argumentos", mas obrigado por esse livro que sempre ajuda fixar melhor ou aprender sob outro ângulo.

-1
Oletros

Meus 2 cents extendidos:

Eh um texto gerado por IA que apenas regurgitou cliches sobre o assunto - nao da para esperar muito. Assunto relevante - pena que mal conduzido.

Parabens pelos comentarios e compartilhar sua experiencia !

1
rtwander

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.

1
DanielSchardosin

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.

1
ocaducorrea

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.

1
DevCritico

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.

1
1
noti0nS

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.

2
maniero

Fora o 0.x% dos programdores do topo, os projetos que eu vejo por aí as pessoas não sabem fazer componentes reutilizáveis, isso vale para a esmagadora maioria dos sêniors CTO, etc. A maioria começou aprender a programar nos anos 90 ou depois quando se começou ensinar a programar de forma equivocada, com nase em projetos quer a maioria nunca faria, e as pessoas apassaram adotar complexidade sem ganho ou ficar fazendo repetidas vezes as mesmas coisas, por isso usam coisas em camadas que se você precisa mudar um campo, precisa mexer em pelo menos 3 lugares diferentes e as pessoas acham isso normal. Ficam gastando montanhas de horas/homem fazendo CRUDs.

Muito códigos são bagunçados justamente porque seguem "boas práticas", que são horríveis se a pessoa não entende oque está por trás delas, Quanto mais eu vejo as pessoas falando em boas práticas mais os códigos ficam piores, porque estão seguindo receitas de bolo em vez de estudar a computação como um todo.

Inclusive boa parte do código OOP que é criado não traz vantagens que poderiam existir, porque a pessoa nem entende oque está fazendo. Isso precisa mudar. Mas primeiro a pessoa precisa reconhecer que faz errrado, e isso não está acontecendo. As pessoas sequer entendem que OOP é para gerenciar complexidade. E acham que não tem jeito de fazer código organizado sem ela. Como exemplo, talvez a maior base de código do mundo não passa nem perto de OOP, até por ser feito em C, todo mundo põe a mão e funciona maravilhosavamente bem. É clar oque tem a vantagem que só programador bom põe a mão, quando os programadores não são tão bons, começa ter que usar mecanismo para gerenciar a bagunça que eles fazem.

Go possue GC sim, e apesar de ser bom em um certo padrão, ele é menos sofisticado que o do .NET ou alguns da JVM, que provavelmente são os melhores do mercado, ainda mais os pagos para terceiros (que alguns zoam que é porque Java gera muito lixo e se ele tivesse GC mesmo quando o código terminasse de executar ele seria engolido pelo GC :D :D :D). Go consegue aqui e ali, não em tudo ser um pouco mais rápido por causa da forma como lida com corrotinas e porque tem uma biblioteca um pouco mais pensada para sistemas e não aplicação enterprise. Algumas abstrações custosas a menos na linguagem ajudam um pouco também. Fora isso também é a cultura. Por enquanto a maioria dos programadores Go costumam ser um pouco melhores, mas está mudando e logo terão hordas de programadores ruins como tem em C#, Java, Python, PHP, JS, etc.

Essa coisa do JITter poder dar mais performance tem um fundo de verdade mas na prátrica o grande ganho foi quando o .NET começou ter AOT e PGO, é muito difícil dar essa performance tyeórica que o JITter seria capaz e gera um outro custo. O JITter pode dar algum ganho maior pontualmente, mas está cada vez mais raro.

De fato não dá muito para comparar as linguagens que ele comparou, e cada um terá seu segmento forte, mas o foco dele é que OOP não é tão necessário assim e as linguagens mais modernas estão se afastando disso, da mesma forma que estão abandonando exceções, que foi outra coisa errada que inventaram.

1