Bug Critico no Groovy

FernandoFranzini:

Já estou lendo meu segundo livro de groovy e todos eles pontuam bastante a verbosidade de código da linguagem Java. Muito bem…nos meus primeiros 10 minutos Groovy descobri que existe um bug - http://jira.codehaus.org/browse/GROOVY-1875 que faz com que qualquer classe groovy executar métodos privados de outras classes. Ou seja, encapsulamento e isolamento que é a base de tudo de uma arquitetura vai para o lixo.
Gostaria de opinião de alguém que já tem adotado groovy em produção…porque na minha modesta opinião (como tomada de decisão de tecnologia) algo critico que me impede de adotar.
Alguém?

Porque é tão crítico? Em Java você pode acessar elementos privados utilizando reflection :S

Jairo Junior:

Porque é tão crítico? Em Java você pode acessar elementos privados utilizando reflection :S

Vc tem projetos em produção?
Como vc encara isso?

FernandoFranzini:

Jairo Junior:

Como vc encara isso?

Se você parar pra ver, os modificadores de acesso são apenas um mecanismo de comunicação. Eu não estou apostando em groovy no momento por outros motivos:
1 - Groovy roda código Java e isso é uma grande armadilha.
2 - O suporte de ferramentas não era/é muito bom.

Esses dois pontos geravam um grande conflito, você tinha que programar em groovy que roda código Java sem todas as ferramentas de produtividade Java ou adotar um estilo mais “ruby” de desenvolvimento (editor de texto/terminal) numa linguagem que roda código Java e usa API’s java.

Acredito que o ponto 2 ainda tem salvação, principalmente com o investimento da SpringSource, o Spring 4 vai suportar groovy [1]. Talvez ainda vejamos groovy dominando como a linguagem mais utilizada da JVM, mas no momento ainda prefiro manter uma posição mais c

“It’s not a bug, it’s a feature.” :evil:

[1] http://blog.springsource.org/2013/01/16/next-stop-spring-framework-4-0/

Eu pelo menos teria tentado simular na versão atual do Grovvy (2.1), já que o bug reportado não é atualizado há tempos, tampouco os relacionados a ele, que reportam apenas para betas das versões 1.x.

Eu to usando a versão 2.x e bug ainda existe.
Pelo que parece foi alocado para ser corrigido na versão 3.

Por que vc acha isso?

Por que vc acha isso?
Vou copiar e colar o que escrevi numa lista de discussão há 1 ano atrás. Não sei se responde exatamente sua pergunta.

Sou fã de groovy há um bom tempo, acho que comprei o Groovy in Action em 2009 e de lá pra cá, sempre tenho acompanhado o projeto.

Mas existem alguns “pitfalls”, vamos começar essa história pela declaração do criador do groovy: ?I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I?d probably have never created Groovy.?

Quando ouvi essa frase pela primeira vez, fiquei muito triste, mas acho que só hoje dá pra entender um pouco os problemas do Groovy. O fato do groovy ser java-like é tanto uma vantagem como uma desvantagem, e é tão perigoso quanto o JAVA do ECMAScript (javascript).

Isso leva justamente a esperar todo o suporte de java (IDE’s, ferramentas e etc) no groovy, aí você entra numa linguagem de scripting puramente orientada a objetos e dinâmica esperando as mesmas facilidades de uma linguagem como java (verbosa, com tipagem estática, não puramente orientada e objetos).

Programadores ruby, python e scala simplesmente não esperam isso, eles aceitam o novo paradigma, aceitam o editor de texto, o terminal e outras ferramentas mais “simples”, em troca da legibilidade, da clareza do código, afinal, você não precisa de um debug ou um autocompletar quando vai escrever algo numa linguagem natural, como português, por exemplo…

Acredito que esse seja o caminho, senão vai ficar parecendo a fábula dos porcos assados, vamos criar soluções para problemas não que existem.

Além disso, groovy ainda não é tão rápido quanto scala, por exemplo, mesmo com o invokedynamic do Java 7.

Então qual o diferencial que você tem ao começar um projeto em Groovy/Grails hoje em dia? Como você justificaria para os investidores a adoção dessa tecnologia?

Eu acho que vc levantou alguns pontos importantes relacionado a cultura da comunidade, mas não para dizer algo sobre “grande armadilha”. De qualquer forma, é rumo para outra conversa. Obrigado pelas dicas…

Acho que meu ponto não ficou claro e talvez “grande armadilha” não foi o termo mais adequado para descrever o problema.

Quando groovy permite que você programe utilizando 100% código Java, você dá espaço para as pessoas programarem em Java, é mais difícil institucionalizar a forma groovy de fazer as coisas, é mais difícil de mudar de paradigma quando você pode fazer da forma antiga. Se você programa em Groovy utilizando a sintaxe do Java, você não tem vantagem alguma.

Afinal, qual o grande atrativo do Groovy? Utilizar a pilha de tecnologias JEE com uma linguagem mais moderna que o Java.

Ficou melhor sim…
Mas me diz uma coisa, essa cara que fez o groovy…não participa do projeto? Não é a spring que cuida disso?

FernandoFranzini:

Ficou melhor sim…
Mas me diz uma coisa, essa cara que fez o groovy…não participa do projeto? Não é a spring que cuida disso?

Ele (James Strachan) é apenas o criador, não sei nem se ele é envolvido com o projeto hoje em dia.