Você é programador Java?
Este blog deixou de ser mantido, mas o autor continua escrevendo aqui. Não deixe de assinar o novo feed!
Há bastante tempo (desde sempre, pelo que me consta) observamos uma segmentação muito forte no que diz respeito às linguagens de programação, principalmente por parte dos próprios programadores; existem aqueles que se auto-denominam programadores C, programadores Java, programadores Delphi, programadores ASP, programadores PHP e assim vai.
Você sabe, as coisas costumam funcionar assim: é bem provável que um cara que se auto-denomina programador C, mesmo tendo poucos conhecimentos em outras linguagens, consiga resolver — de um jeito ou de outro — os problemas que precisa usando essa linguagem. O mesmo acontece com outros programadores proficientes em outras linguagens. Isso faz sentido para você? Fazia para mim. Fazia.
Ontem, escutei ao podcast do AboutGroovy.com, onde o entrevistado da vez é Neal Ford, Arquiteto de Aplicações na ThoughtWorks, e um dos assuntos levantados nesse podcast é o conceito de Polyglot Programming (ou programação poliglota).
Segundo Ford, linguagens de programação como o Java estão começando a mostrar sinais evidentes de “velhice”, o que não é algo realmente agradável. Como é de conhecimento geral, o Java se apoiou em diversas características introduzidas pelo C, com a diferença de incluir uma VM e mais um punhado de outras coisas. O plano era que esse negócio aí fosse inteligente o suficiente para diminuir bastante as dores de cabeça dos programadores quanto a alocação de memória e tudo mais (coisa que costumava tirar o sono de muitos na época). Isso me leva a concluir que a pretensão do Java era ser o que o C seria se este tivesse sido feito da forma correta! (assim como o Subversion é em relação ao CVS, segundo Linus Torvalds).
Devo dizer que o Java foi extremamente bem-sucedido nessa tarefa. Como todos sabemos, a coisa não parou por aí, tanto é que hoje temos uma plataforma extremamente robusta e eficiente. Porém, essa definitivamente não é minha opinião quando vejo a parte “linguagem” do Java. Hoje, a coisa está mais ou menos assim: numa mão temos uma excelente plataforma: rápida, robusta e amplamente usada pela indústria; na outra mão temos uma linguagem que está ultrapassada e que definitivamente não está em condições de ser usada de modo a extrair o máximo dessa plataforma.
Sabendo desse problema, um grande esforço foi iniciado há algum tempo com o objetivo de melhorar a plataforma Java, permitindo que esta fosse capaz de trabalhar com diferentes linguagens. O mais legal é que isso é possível de ser feito sem que seja necessário abrirmos mão das qualidades com as quais estamos acostumados. Hoje podemos escrever programas em Ruby, Groovy, Python, JavaScript e em uma infinidade de outras linguagens e, ainda assim, programamarmos em Java! E é justamente por esse motivo o podcast é tão interessante (você deveria ouvir, sério). Entre outras coisas, ele diz que nós deveríamos parar de nos preocupar com a parte “linguagem” do Java para tirarmos mais vantagem da parte “plataforma” do Java.
Tá, eu já sabia disso… e é provável que você também. Mas é sempre mais interessante ouvir isso de outra pessoa, principalmente quando essa pessoa é bem mais experiente e sabe muito mais do que você. 
- Ahh… mas eu não posso fazer aplicações corporativas usando linguagens de dinâmicas… e também não sei como chegar para o meu chefe e propor o uso delas sem ter que pegar minha cabeça no chão depois.
Já disse e repito: ouça o podcast. Uma abordagem muito interessante que o Ford sugere para facilitar a entrada do Groovy — e outras linguagens do gênero — nas empresas é usá-las na criação de test cases. Sim, pois trata-se de código que não vai para produção. Então, quando todo mundo perceber que é muito mais fácil e rápido desenvolver com Groovy em vez de Java, oportunidades para uso da primeira começam a surgir naturalmente.
A propósito, se alguém acha que não se pode usar Groovy em aplicações corporativas, eu gostaria de saber qual é a sua definição de “aplicação corporativa”, pois, existe uma grande chance dela estar equivocada.
Algumas reflexões…
Pra quê criar aplicações em um framework Java qualquer (que, no fim, acabam sendo diferentes sabores da mesma gororoba) se podemos criar aplicações com o Grails — muito mais fácil e rapidamente, diga-se de passagem — e gerar um arquivo WAR/EAR lá no final da mesma forma que você faria com outro framework Java qualquer?
Pra quê ficar tentando convencer o compilador de que você não é um idiota e sabe exatamente o que está fazendo? Sim, pois é justamente isso que frameworks como o JMock fazem. Podemos criar test cases muito mais simples e eficientes em Groovy — inclusive com Mock Objects — sem ter que dar elásticos e dribles-da-vaca no compilador.
Pra quê gerar XMLs com API s que são mais verbosas que o Galvão Bueno em final de Copa do Mundo se você pode usar, por exemplo, o XML Builder do Groovy e outras alternativas tão poderosas (e simples) quanto?
O que o Ant faz sozinho que não poderia ser feito mais elegantemente em código Groovy? Aliás, existe uma forma de se criar scripts Ant com código Groovy, o que nos deixa numa situação bem mais confortável uma vez que não precisamos meter a mão em quilos de arquivos XML.
Temos que deixar de programar em Java, ou em C# ou em Brainfuck e programarmos nas linguagens que forem adequadas para fazer o trabalho da forma mais simples possível. Um óbvio que de tão óbvio passa desapercebido por muitos.
Fotos por: manhattan.about.com, Google Images
Tags: java, linguagens de programação, plataforma, podcast, polyglot programming
29 de julho de 2007 às 1:01 am
Fala Daniel!
Trouxe alguns pontos interessantes neste post ;D. Só para expandir a discussão:
Sobre a plataforma Java, é verdade, ela pode e está sendo utilizada como base para outras linguagens. Mas, perguntemos: em qual extensão e quão eficiênte ela é capaz de suportar tal idéia? Não posso dizer com autoridade, mas já ouvi comentários sobre a JVM mostrando a dificuldade que é implementar certas linguagens para o bytecode/VM java. Pelo que entendo, a linguagem java é altamente acoplada à plataforma java. Descontente com minha cabacidade de ir mais fundo nisso, acabei de encontrar a thread mais completa que já li a este respeito (e Gilad Bracha é quem está falando):
Link
Note que, no início, ele enfatiza o “very” em “JVMs are currently very, very poorly suited to running dynamic languages”.
Compartilho também da idéia de que o ideal seria escolhermos linguagens que são adequadas para o fazer o trabalho da forma mais simples possível.
Mas algo me entristece sempre que leio coisas do gênero. Afinal, quantas linguagens conhecemos? Em quantas delas somos fluentes? E, mais importante, as linguagens que somos fluentes mais se parecem entre si ou mais se distanciam? Se elas mais se parecem (ex. C, C++, java, C#, Perl, PHP, VBScript etc), escolher uma delas para o trabalho talvez seja como escolher um dentre 7 garfos para cortar a carne. Teria sido melhor procurar uma faca. Mas, se preferir a gente volta para a velha analogia do martelo e do prego
29 de julho de 2007 às 2:44 am
E aí, Thiago!
É verdade. Um bom exemplo é o próprio JRuby… os caras estão praticamente tendo que operar milagres. Mas, por outro lado, também penso que essa dificuldade é extremamente natural.
A plataforma Java está aí a mais de dez anos, mas só de uns tempos para cá o pessoal começou a trabalhar nessa coisa de “diferentes linguagens na JVM”. Então, se levarmos em conta que foram gastos (ou investidos, sei lá) dez anos no Java enquanto plataforma E linguagem (como se fossem duas peças de um mesmo objeto), é natural que tais peças estejam acopladas entre si de modo a complicar um pouco as coisas agora que o foco é outro.
Inclusive, esse fato parece transparecer nesse quote de Gilad Bracha que você colocou em seu comentário:
Bem sutil o currently ali no meio da frase, mas compartilho da mesma opinião: que esse trabalho está apenas começando. Que hoje a JVM ainda não está em plenas condições de satisfazer plenamente os requisitos dessas várias linguagens. Mas isso vem mudando… mesmo que a passos de tartaruga.
Boa observação! Aliás, eu sou fluente em diversas linguagens, desde que estas linguagens sejam Java!
Brincadeira… mas, como você disse, todas as linguagens em que possuo um conhecimento maior são justamente as linguagens Java-like (C/C++/C#, Pascal etc).
Entretanto, o que me conforta em relação a esse negócio de Polyglot Programming é que ele não precisa ser levado ao extremo para trazer bons resultados. Quero dizer, não vou usar Groovy para mexer com XML, JRuby para criar testes unitários, JavaScript para criação de build scripts e Java para escrever o método
main(). E, por esse motivo, acredito que não precisamos ter a mesma fluência em diversas linguagens.Por exemplo, se durante uma pesquisa na Internet eu descobri no Groovy uma boa alternativa ao JUnit + EasyMock (argh), nada me impede de usar o Groovy. E o interessante é que eu não preciso ser realmente fluente em Groovy; basta saber como trabalhar com assertions e mock objects (além do básico da sintaxe) para ter boas condições de testar grande parte do código. Ou, em poucas palavras, o aprendizado dessas linguagens auxiliares se dá de forma “on demand”.
Oh my….
30 de julho de 2007 às 10:19 am
Muito pertinente este seu post.
Sobre linguagens dinâmicas:
Elas estavam ai desde sempre, e nunca deram muita bola pra elas. Veja-se python, a qual era bastante usada pelo povo do linux, e sempre era mal vista por Programadores-de-outras-estirpes. Mas o bom, é que ela está sendo posta em questão para a maior comunidade de programadores hoje (ao menos eu acho que é a maior). E isto está sendo feita a muito pouco tempo. Tem o que 2 anos?! Talvz até menos. As pessoas demora um tempo para se acostumar a essas coisas “novas”.
Sobre Programadores do [coloque aqui sua linguagem]:
Uma coisa que sempre digo é: Você precisa conhecer os dois caminhos de uma bifurcação para saber qual o melhor caminho a seguir. Conhecer outras linguagens, é ótimo, desenvolve a sua gama de conhecimento e solução de problemas. As vezes até é bom, para quebrar paradigmas, para dar uma visão dferente sobre o mesmo problema, mesmo que a linguagem não seja adotada para resolver o problema, mas ao menos vc consegue enxergar o problema por outro lado.
Bom é isso… Parabéns pelo post. Ah, e valeu pelo link do podcast (muito bom, BTW)
30 de julho de 2007 às 11:24 am
Fala Juliano!
O exemplo do Python é muito bom… também percebo isso. Tanto é que esse aumento no interesse em linguagens como Python (e o próprio Ruby) me fizeram parar para pensar se havia a possibilidade de eu estar perdendo alguma coisa se deixasse de dar uma olhada nelas. E, a verdade é que sim, tem muita coisa legal acontecendo por essas bandas que vale a pena dar uma olhada.
A alguns dias atrás eu tava vendo algumas screencasts e tutoriais sobre o Django e confesso que achei aquilo uma baita mão-na-roda. Vi que, vários projetos que hoje são feitos do zero em Java (ou whatever) poderiam ser feitos em horas usando o Django. Algo semelhante acontece com o Ruby on Rails, Grails e outros frameworks mais recentes.
É exatamente esta a conclusão que eu tiro disso tudo. Continuando com o que eu estava dizendo, agora sei que para sites CMS-like o Plone (ou até mesmo o Django) é uma excelente opção. Então, pra quê eu irei fazer em Java, por exemplo, se poderia fazer com Python/Django em muito menos tempo?
Aí vem aquela: “ahh, mas você não sabe Python nem Django!”. Não importa! O tempo que eu levarei para fazer a aplicação como Django é muito, mas muito menor do que seria se fizesse com Java; e por esse motivo que o tempo gasto aprendendo Python/Django é insignificante, pois é quase certeza de que terminarei o sistema mais rapidamente. E você sabe, se tem um cara que entrega um sistema em dois meses e outro que entrega o mesmo sistema em quinze dias, qual dois dois tem mais chance de levar?
Opa, eu que agradeço pelo comentário. Até mais!