[color=“blue”]Oi pessoal !!! Olha, não conheço muito dessas linguangens de script que rodam na JVM mais vou tentar dar a minha opinião sobre o que eu sei.
Uma das grandes vantagens pra mim é que você tem mais opções em relação a linguagem de programação a ser utilizada, ou seja, você pode utilizar a linguagem que mais lhe agrada.
A desvantagem… para os programadores não vejo nenhuma. Essas novas linguagens de scripts trazem novos recursos interessantes que podem ser utilizados. :roll:
Ha, eu ainda não tenho o gmail… se alguem tiver um convite sobrando eu tô dentro !
Vantagens: diversidade de opcoes, facilidade em termos de sintaxe para certas coisas (syntax-sugar), calar a boca da MS que diz que o .NET suporta diversas linguagens e o Java nao.
Desvantagens: nenhuma. Quanto mais opcao melhor.
Utilidade: nao sei. Nao fui a fundo com alguma linguagem de script dessas que rodam na JVM (entao nao leve muito a serio minha opiniao).
Pra mim as vezes parece pura futilidade - a maioria dos artigos sobre Groovy p.ex., citam a ausencia de ponto-e-virgula, a nao-necessidade de declarar variaveis, e recursos do tipo, como vantagens extraordinarias (caramba! nao preciso mais digitar ponto-e-virgula!). Acho que nao eh bem por ai. Gostaria de ver mais artigos/opinioes apontando para vantagens REAIS do uso desse tipo de linguagem. Porque com IDEs no nivel do Eclipse, esse acucar sintatico nao tem mais tanta importancia.
Eh isso. Apenas minha opiniao. Quero um invite do GMail tambem - ate agora nao entrei nesse barato.
(apesar disso, a opiniao eh sincera - nada interesseira :mrgreen:)
closure = {a, b | c = (a+b)*0.1 - 4; println(c)}
closure(2, 3); // -3,5
Pronto! Estas são as famosas closures. Ainda não viu utilidade? Bom, eu vou dizer duas:
testar código / criar protótipo;
Para arquiteturas WEB mais simples, em que não seria nenhum pecado usar JSP-raw, pode funcionar como uma maneira simples de se criar um código não-tão-feio-assim. [nota: ok, péssimo exemplo!]
Linguagens de script são ferramentas perfeitas para trabalhos “quick’n dirty” de qualquer tipo.
Outra utilidade muito grande que eu vejo é na customização de sistemas, colocando boa parte da regra de negocio em scripts a base em java fica mais simples e rígida; bom para todos.
Vantegens:
:arrow: Escreve-se menos (maior produtividade)
:arrow: Pode-se alterar o funcionamento sem ter que recompilar o código
:arrow: Simplicidade
:arrow: Menor curva de aprendizado (na minha opinião)
Desvangens:
:arrow: Desempenho comprometido
:arrow: Erros são mais difíceis de detectar
:arrow: O código pode ficar menos legível, por ter muitas coisas implícitas
Mais ou menos… muita, mas muuuuuita gente que nao eh ‘Great Hacker’ e ta longe de ter o nariz empinado como o Paul Graham reclama do fato de Java nao ter closures. Alias, existem diversos esforcos procurando uma maneira de implementar closures e continuations no Java sem quebrar (muito) a especificacao.
[quote=“cv”]Mais ou menos… muita, mas muuuuuita gente que nao eh ‘Great Hacker’ e ta longe de ter o nariz empinado como o Paul Graham reclama do fato de Java nao ter closures. Alias, existem diversos esforcos procurando uma maneira de implementar closures e continuations no Java sem quebrar (muito) a especificacao.
Mas vocês concordam que o código fica bem menos legivel, e isso contribui muito para assustar as pessoas, como quando me referi ao Perl (aquela linguagem pra louco, exatamente por ter um código bem dificil de entender). E outra, isso não fere os principios da orientação a objetos?
Na verdade, em muitas situacoes, usar closures torna o codigo MUITO mais legivel (tratamento de eventos em UIs eh um exemplo, gerar XML tambem, mas existem muitos outros).
Sobre ferir a orientacao a objetos, nao entendi onde vc quer chegar… pq um bloco de codigo tambem nao pode ser um objeto? Na verdade, eh mais OO do que a situacao atual do Java (lembrando que Smalltalk tem blocks e closures como uma das bases da linguagem)
Não concordo. Imagine aquele lindo código que descreve uma GUI usando Swing, cheio de annonymous inner classes para lá e para cá. Isso sim é um código ilegível. Closure funciona mais ou menos como uma AIC que implementa o Command Pattern, o que PODE tornar seu código mais elegante.
Sobre ferir a OO, não vejo como isso pode acontecer.
pra falar a verdade, o problema de leitura de um código perl é devido ao excesso de utilização de regular expressions na linguagem
uma ER é uma ferramenta extremamente poderosa, principalmente da maneira como é implementada em perl (por isto a maioria das linguagens hoje suportam PCRE)
mas uma ER grande, é uma coisa que só quem escreveu consegue ler e sómente por no máximo dois dias, depois aquilo se torna um enigma mesmo para o seu criador, que normalmente prefere apagar aquela e escrever uma nova
[quote=“urubatan”]pra falar a verdade, o problema de leitura de um código perl é devido ao excesso de utilização de regular expressions na linguagem
uma ER é uma ferramenta extremamente poderosa, principalmente da maneira como é implementada em perl (por isto a maioria das linguagens hoje suportam PCRE)
mas uma ER grande, é uma coisa que só quem escreveu consegue ler e sómente por no máximo dois dias, depois aquilo se torna um enigma mesmo para o seu criador, que normalmente prefere apagar aquela e escrever uma nova :-)[/quote]
Apenas saindo um pouco da linha principal para discordar do urubatan.
Nao acho que o problema do Perl seja esse. O lance eh que o mote (e orgulho) do Perl eh “existem varias maneiras de se fazer uma coisa - use a que voce achar melhor”. Parece legal - mas como a sintaxe da linguagem eh bizarra em alguns pontos, o que eventualmente temos eh codigo “write-only” (principalmente quando o cara tem aquelas sindromes de “quanto menor o codigo, melhor”, “quanto mais esquisito o codigo, melhor”, etc).
ER eh um recurso poderoso, utilizado por diversas linguagens/editores/ferramentas/etc.
skyblue e kuchma - mandem o e-mail de vocês em pvt pra receber o convite