Recentemente Bruce Eckel escreveu em seu blog sobre legados deixados pelo C++ e Java, seu texto gerou muitas reações. Enquanto mencionava sobre erros de design, ele concluiu que ambas as linguagens tiveram um papel significante na evolucão das linguagens de programação e um importante e positivo legado. Mas será que ainda está cedo para falar de seus legados?
Eckel, um membro formado do C++ Standards Committee relembra a decisão tomada em relação à compatibilidade com versões anteriores da linguagem com C desde o início:
Para entender como a linguagem pode ser desagradável e complicada, e possuir um bom design ao mesmo tempo, você precisa manter em mente a primeira decisão de design que afeta tudo em C++:Compatibilidade com C. Stroustrup decidiu - e aparentemente de forma correta - que a forma de fazer a grande massa de programadores C mudarem para objetos era fazer com que isso fosse transparente: para permitir que eles pudessem compilar seus códigos em C sem precisar alterá-los para C++.
Enquanto C++ teve sucesso em atrair a maior parte dos desenvolvedores C para C++, a decisão sobre a compatibilidade teve um severo impacto negativo na evolução da linguagem:
Isso [a compatibilidade com C] foi uma enorme restrição, e sempre sido a maior força do C++ ... é a sua perdição. É o que fez com que C++ foi bem sucedida e é o que fez que fosse complexa da forma que é.
Por exemplo, ele reconhece que o operador de sobrecarga difícil de se usar em C++:
Eles [aqueles que não entendem C++ muito bem] pensaram que a sobrecarga de operador fosse muito difícil para que o programadores a usassem de forma adequada. O que é basicamente verdadeiro em C++, porque C++ tem ambas: alocação de pilha e alocação de heap, e você precisa sobrecarregar seus operadores para poder manipular todas as situações e não causar vazamentos de memória. De fato, isso é difícil.
Evidentemente, essas declarações estão fadadas a iniciar um debate. Archilleas Margaritis não considera que a compatibilidade com C seja um problema:
Eu não acho que C++ não tenha um bom desgin por causa da compatibilidade com C. ADA é compatível com C, mas é uma linguagem muito boa, com forte liderança da sua concepção de engenharia.
O que está errado em C++ é o nível de compatibilidade de código fonte com C. Para fosse possível incluir cabeçalhos C, C++ manteve o sistema preprocessador do C. Isso levou a uma gramática estranha e sem contexto, que levou uma sintexe estranha que tem que se manter compatível com C.
Michele Costabirle considera que a falta de uma biblioteca padronizada, desde o inicio foi uma das falhas do C++:
Eu acho que um sério fardo do C++ foi a falta de uma biblioteca padronizada.
Se eu bem me lembro, Stroustroup escreveu em "O Design e a Evolução do C++" que ele deixou de lado uma biblioteca padronizada em favor da herança multipla. Eu teria tirado muito mais beneficio da outra forma.
Muitas coisas podem ser ditas a respeito do C++, mas uma coisa é certa: o C++ levou os programadores a subir um degrau na escada da programação.
Falando em uma dirente linguagem no mesmo tom, Eckel reitera alguns erros de design feitos em Java:
Por muitos anos, a linhagem da equipe do Java foi "Sobrecarga de operadores é algo complicado demais." Isso e muitas outras decisões em que alguém claramente não faz a lição de casa é a razão pela qual eu tenho reputação por desprezar muitas escolhas feitas por Gosling e a equipe do Java. …
Primitivos "tem que ser incluídos para eficiência." A resposta certa é permanecer fiel a "Tudo é um objeto" e prover uma alçapão para realizar atividade de baixo nível quando houver necessidade de eficiência (isso também seria permitido para tecnologias hotspot para tornar as coisas mais eficientes de forma transparente, como evetuamente ocorreria). Ah, e de fato você não usar processamento de pontos fluantes diretamente para calcular funções transcedentais (ao invés, isso é feito no software). …
Quando eu escrevi sobre o quanto ruim foi feito o design dos generics, eu obtive a mesma resposta, juntamento com "temos que ter compatibilidade com as (más) decições tomadas no Java anteriormente." Ultimamente mais e mais pessoas tem adquirido experiencia com generics para ver o quanto esse realmente são difíceis de usar.
Bill Venners lembra das coisas de maneira diferente:
Eu não estou certo de quanto eu tive a impressão de que a escolha de deixa a sobrecarga de operadores de lado foi feita porque alguém não fez a lição de casa. Eu me lembro de perguntar ao Gosling em uma das minhas entrevistas com ele porque ele estava deixando a sobrecarga de operadores de lado (Eu não acho que essa pergunta e resposta acabou sendo publicada). O que ele basicamente disse para mim, foi que eu o ouvi dizer em outros contextos: Gosling sentiu que o nível de abuso de sobrecarga de operadores que ele viu em prática em outras linguagens (eu não tenho certeza se ele estava se referindo apenas a C++, mas certamente incluia C++) havia sobreposto os benefícios dela. Isso é tudo. Foi uma escolha subjetiva de design.
James Watson favorece as limitações propositadamente introduzidas em Java:
O que faz do Java uma linguagem de fácil adoção foi a sua simplicidade. Sim,Você pode escrever código impossível de ser dar manunteçao em qualquer linguagem, mas você terá que trabalhar duro para fazê-lo em Java. Isso porque não são oferecidos uma série de recursos fáceis de se abusar que outras linguagens oferecem.
Da uma perspectiva individual, isso é terrível. Se eu não quiser utilizar uma funcionalidade, eu não a uso. Quem é a Sun para me dizer o que eu devo ou não fazer? Mas quando pega um grupo de desenvolvedores que possuem idéias diferentes a respeito de o que é uma boa abordagem, o jogo muda. Ter um número limitado de formas de fazer as coisas começa então a fezer sentido.
Noel Grandin deu seu pitaco, ampliando o debate ainda mais incluindo novas linguagens:
A maioria das outras linguagens atraentes como Ruby e Scala nunca serão as principais, isso proque essa são todas fortemente tendenciosas a favor de escrever código, ao invés de ler código.
Java equilibrou corretamente - Java pode até ser verboso e não possuir uma série de funcionalidades legais, mas é realmente fácil de descobrir o que algum código aleatório está fazendo.
Ao final, Eckel falou a respeito do legado Java:
Java trouxe o mainstream dos programadores no mundo do garbage collection, maquinas virtuais e um modelo consistente de manipulação de erros (especialmente ser você deixar de lado as checked exceptions, que é uma que pode ser usada como eu mostrei em Thinking in Java, 4e). Com todas as suas falhas, ela nos elevou a um nível mais alto, ao ponto em que estamos agora, e prontos para linguagens de níveis mais altos.
O fator mais positivo é preparar o caminho para as linguagens do futuro:
De um certo modo, C++ foi a principal línguagem e as pessoas pensaram que sempre seria assim. Muitos pensaram o mesmo a respeito do Java, mas o Java tornou ainda mais fácil de substituir a si próprio, por causa da JVM. Agora é possível que qualquer um crie novas linguagens e as execute com tanta eficiência quanto Java. ... …
E estamos vendo isso acontecer -- ambos, com linguagens de alto nível como Scala, e com linguagens dinâmicas, como Groovy, JRuby e Jython. … …
O benefício não intencional, o verdadeiro brilho acidental de Java é que foi criado um caminho para sua própria substuição, mesmo que o próprio Java tenha atingido um ponto em que ele não pode mais evoluir. Todas as linguagens do futuro tem que aprender com isso: criar uma cultura em que possa haver refatoração (como Python e Ruby fizeram) ou permitir espécies competitivas de crescimento.
Java incendiou muitas disputas quando apareceu, especialmente entre desenvolvedores C++ e os novos desenvolvedores Java. As vozes se acalmaram desde então, e nós podemos ver claramente agora aonde estamos e qual é o legado deixado pelas duas linguagens. Ou talvez ainda seja cedo demais para falar de seus legados? Isso faz soar como se fossem linguagens mortas ou linguagens que estajam morrendo. (Opniões são sempre bem vindas.)