[quote]Da mesma forma que uma aplicação A feita por João não vai gerar os mesmo bytecodes que uma aplicação B feita por José.
Mas isso não tem nada a ver com o fato da linguagem ser dinamica ou estatica.[/quote]
Na verdade tem. A JVM foi implementada inicialmente para rodar Java. As linguagens que conseguem tirar mais proveito da JVM geram um bytecode mais parecido com o que o Java gera, o que é o caso de Scala. Se vc quiser implementar caracteristicas de linguagens que nao tem nada a ver com o Java (linguagens dinamicas ou funcionais, por exemplo) vc terá um trabalho adicional para isso e o bytecode não será tão otimizado.
[quote=dlt]
O que eu disse que não tem a ver é a questão do hot-swapping, que realmente não tem nada a ver com trocar métodos em tempo de execucao. Tem a ver com carregar código novo na VM, atualizar uma aplicacao sem reiniciar o servidor, etc…[/quote]
Uai… trocar métodos em tempo de execução, não é carregar código novo na JVM não?
A JVM na verdade até suporta o hotswap… mas limitado… vc pode trocar o corpo do método… mas nao sua assinatura…
Não. Em ruby (e em outras linguagens, principalmente c/ orientacao a objetos prototipica: javascript, self, Io) é bastante comum. Vc pode adicionar métodos na classe ou no objeto em tempo de execucão. Dá uma pesquisada sobre metaprogramacão em Ruby.
Não. Em ruby (e em outras linguagens, principalmente c/ orientacao a objetos prototipica: javascript, self, Io) é bastante comum. Vc pode adicionar métodos na classe ou no objeto em tempo de execucão. Dá uma pesquisada sobre metaprogramacão em Ruby.
[/quote]
Há tá… saquei o que vc tá querendo dizer…
Eu estava falando de métodos Java… (os que nao podem ter sua assinatura alterada, logo não podemos carregar esses métodos novos para a JVM)
Os métodos em JRuby de acordo com o que eu li no seu link… são feito mais ou menos da forma do map mesmo que citei anteriormente… onde cada método é uma classe Java…
Logo um método novo em JRuby para a JVM não é um método Java novo, e nem uma assinatura nova… Assim o hotswap para o JRuby é possivel…
É possivel voce carregar classes novas na JVM (classes Java novas)… mas nao métodos Java novos…
Se o método em JRuby é na verdade uma classe Java… vc pode carregar novos métodos JRuby…
Isso. Eu tava falando sobre a estratégia de implementacao do JRuby pra deixar adicionar métodos em tempo de execucao (no Ruby, nao no Java).
Ainda assim, discordo com vc quanto ao lance do hot-swap, porque metaprogramacao não me deixa atualizar uma aplica’cão (corrigir um bug, adicionar uma nova feature) sem reinicializar a JVM.
[quote=dlt][quote]Da mesma forma que uma aplicação A feita por João não vai gerar os mesmo bytecodes que uma aplicação B feita por José.
Mas isso não tem nada a ver com o fato da linguagem ser dinamica ou estatica.[/quote]
Na verdade tem. A JVM foi implementada inicialmente para rodar Java. As linguagens que conseguem tirar mais proveito da JVM geram um bytecode mais parecido com o que o Java gera, o que é o caso de Scala. Se vc quiser implementar caracteristicas de linguagens que nao tem nada a ver com o Java (linguagens dinamicas ou funcionais, por exemplo) vc terá um trabalho adicional para isso e o bytecode não será tão otimizado.[/quote]
Entendi. Se pra vc “tirar proveito da JVM” significa rodar no máximo de performance ao inves de contornar as limitações de hotswap do Java por exemplo, tudo bem.
Mas pra mim é o mesmo que dizer que uma mesma aplicação A sem uma funcionalidade X é mais “otimizada” do que a aplicação B com uma funcionalidade X já implementada.
Na maioria das vezes X é algo que vc precisa ter independe de uma superficial perca de performance da aplicação.
[quote=dlt]Isso. Eu tava falando sobre a estratégia de implementacao do JRuby pra deixar adicionar métodos em tempo de execucao (no Ruby, nao no Java).
Ainda assim, discordo com vc quanto ao lance do hot-swap, porque metaprogramacao não me deixa atualizar uma aplica’cão (corrigir um bug, adicionar uma nova feature) sem reinicializar a JVM.[/quote]
Mas com uma solução mais robusta… acho seria possível tb…
[quote]Entendi. Se pra vc “tirar proveito da JVM” significa rodar no máximo de performance ao inves de contornar as limitações de hotswap do Java por exemplo, tudo bem.
Mas pra mim é o mesmo que dizer que uma mesma aplicação A sem uma funcionalidade X é mais “otimizada” do que a aplicação B com uma funcionalidade X já implementada.
Na maioria das vezes X é algo que vc precisa ter independe de uma superficial perca de performance da aplicação[/quote]
Aqui já estamos falando das limitacoes da JVM pra implementacao de linguagens dinamicas/funcionais. Vc havia dito antes que o fato da linguagem ser dinamica ou não, não interfere no bytecode gerado, o que é um equívoco.
[quote=dlt][quote]Entendi. Se pra vc “tirar proveito da JVM” significa rodar no máximo de performance ao inves de contornar as limitações de hotswap do Java por exemplo, tudo bem.
Mas pra mim é o mesmo que dizer que uma mesma aplicação A sem uma funcionalidade X é mais “otimizada” do que a aplicação B com uma funcionalidade X já implementada.
Na maioria das vezes X é algo que vc precisa ter independe de uma superficial perca de performance da aplicação[/quote]
Aqui já estamos falando das limitacoes da JVM pra implementacao de linguagens dinamicas/funcionais. Vc havia dito antes que o fato da linguagem ser dinamica ou não, não interfere no bytecode gerado, o que é um equívoco.[/quote]
Não acho que esteja equivocado, é questão de ponto de vista. Minha impressão é que o fato de Scala gerar bytecode parecido com Java faz dela otimo para algumas aplicações que exigem 2% a mais de performance, e ao mesmo tempo pouco pragmática para outras aplicações mundanas, como desenvolvimento web.
Mas pra mim o que continua interferindo no bytecode gerado são aplicações com diferentes requisitos. Antes de qualquer distinção entre dinamica e estatica.
Eu acho que uma linguagem dinamica e funcional gerar bytecodes para uma VM projetada para uma linguagem estática e imperativa é uma Senhora Interferência.
Vou ter que implementar alguma coisa c/ o Lift antes de falar o quanto ele é pragmático. A propaganda que os usuários de Lift fazem é boa, e a linguagem é bem menos “hype-free” que Ruby.
Pra falar verdade, eu gosto bastante de scheme e acho que não teria dificuldades para me adaptar com Clojure. O que me deixa com o pé atrás é que pelo pouco que pesquisei, os frameworks para desenvolvimento web ainda não são muito maduros e tem poucas bibliotecas disponíveis. Compojure, que é o mais falado nas listas de discussão e fórums, foi feito inspirado pelo Sinatra, que é um framework Ruby bastante minimalista. Não quero uma coisa minimalista, quero batteries included. Vendo por esse ponto de vista e assumindo que Lift realmente é tão produtivo quanto Rails, Scala parece uma melhor escolha.
Exatamente. É o que estou dizendo desde quando vc comecou com a conversa de que não há diferenca entre bytecodes de linguagens diferentes. Felizmente, esse assunto já terminou, já que concordamos em discordar.
Há quanto tempo vc está usando Clojure e o que está achando da linguagem? Já colocou alguma coisa em producão?
Só uma dica pra quem vai fazer algo na Web com Scala, testem o PlayFramework mod Scala, pq o “Lift” é muito esquisito, eu ao menos não gostei. O Play lembra bastante o jeitão do Rails :-), fica a dica.
Quanto à linguagens dinâmicas em cima da JVM, ficaria com JRuby pela sintaxe maravilhosa do Ruby, adoro programar na linguagem e Scala, por ser poderosa, mesclar funcional, atores - concorrência.
Usaria Scala para projetos pesados de integração e JRuby para aplicações mais light Web :-).
A linguagem é bastante produtiva, o desenvolvimento flui natualmente, sem atrapalhar o programador pensar na logicada aplicação, e o codigo é bastante expressivo tb. Tenho em produção um sistema com menos de 400 linhas de código, onde clientes (agentes) fazem o crawler do conteúdo de alguns sites e disponibilizam para uma API REST. Neste caso a arquitetura minimalista do compojure foi uma mão na roda para implementar o servidor REST, por se tratar de uma arquitetura baseada em componentes.
Mas confesso que pra alguem com experiencia apenas no paradigma imperativo/objetos, até conseguir entender o paradigma funcional e isolar o estado mutável do resto da aplicação para então aproveitar todo os recursos da linguagem leva um tempinho. Mas os benefícios em termos de produtividade são enormes já que vc tera toda a diversidade de bibliotecas Java disponível ao mesmo tempo do poder de uma linguagem como Lisp.
[quote=mochuara][quote=Kenobi]
Usaria Scala para projetos pesados de integração e JRuby para aplicações mais light Web :-). [/quote]
Quem aqui tem tempo pra ficar estudando linguagem X pra fazer uma coisa, linguagem Y pra fazer outra, linguagem Z pra outra…
[/quote]
Cada um tem um rítimo de aprendizagem, talvez o seu seja mais lento… Mas garanto que existem várias pessoas aqui no fórum que programam em mais de 3 linguagens, como Java, Erlang, Ruby, Python e por aí vai …
Aliás, em qualquer faculdade de primeira linha você vai sair programando em algumas, e se aparecer nos Dojos que rolam na USP vai ver isso na prática, Haskell, Lisp, Ruby e por aí vai …
