Arquivo Discussoes de Programacao e Tecnologia Bom dia,
Qual você prefere ? outra ?
* AspectJ
* Clojure
* Duby
* Fantom
* Groovy
* Ioke
* Jaskell
* JavaFX Script
* JRuby
* Jython
* Noop
* Rhino
* Scala
http://www.developpez.net/forums/d894018/java/general-java/langage/langage-jvm-promis-bel-avenir/
Abraços
Scala tem boa performance mas é estatica e por isso não é muito apropriada para desenvolvimento web.
JRuby ainda possui uma implementação muito pobre na JVM.
Groovy é boa para web mas assim como Ruby, não para aplicações que requer alta performance.
Para substituir Java como linguagem que é pau pra toda obra e desenvolver qualquer tipo de programa, Clojure sem dúvida. A comunidade esta crescendo bastante, assim como o suporte oferecido por IDEs.
AspectJ
Groovy
vlw
Scala tem boa performance mas é estatica e por isso não é muito apropriada para desenvolvimento web.JRuby ainda possui uma implementação muito pobre na JVM.
Groovy é boa para web mas assim como Ruby, não para aplicações que requer alta performance.
Para substituir Java como linguagem que é pau pra toda obra e desenvolver qualquer tipo de programa, Clojure sem dúvida. A comunidade esta crescendo bastante, assim como o suporte oferecido por IDEs.
E porque estatica nao seria boa para web?? O que estatica tem haver com web ou qualquer outra coisa?
O fato é que ser estatica é exatamente um ponto defendido pelos criadores e adeptos.
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .
Não conheço muito C#… já trabalhei a muito tempo atrás com ela…
Tem uns recursos que realmente Java nao tem…
A unica coisa que nao gostei foi o padrao de nomeclatura… onde tudo era maiusculo…
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .
Na verdade nao!! depende do compilador que fizerem. Por exemplo é fato que o JRuby é lento, e que o do Scala roda praticamente igual java na JVM!
Uma pergunta para os conhecedores de scalla…
Scalla suporta hot swap? Se alterar os métodos da classe por exemplo…
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .Na verdade nao!! depende do compilador que fizerem. Por exemplo é fato que o JRuby é lento, e que o do Scala roda praticamente igual java na JVM!
Scala parece ser bem interessante pra desenvolver pra web, usando o Lift. Dessas ‘novas’ linguagens que tem uma boa plataforma e suportam concorrência, Scala parace ser a mais pragmática pra mim, que desenvolvo pra web. Não acho que tenha muita coisa a ver a linguagem ser estática/dinâmica e a produtividade que ela te dá. A maioria do pessoal que critica linguagens estáticas dizendo que são verbosas e menos produtivas, falam isso porque as linguagens estáticas que conhecem tem sistemas de tipos pouco expressivos comparados a haskell, ml, ocaml.
Segundo o criador do Lift, que já trabalhou com Rails, Scala tem grande parte da flexibilidade do Ruby e ainda tem as vantagens que um bom sistema de tipos em uma linguagem estaticamente tipada pode trazer. Parece ser uma boa apsota pra quem quer sair do lugar comum e não quer ficar preso a uma linguagem que tem features interessantes, mas que não é muito pragmática.
JRuby =D
Scala parece ser bem interessante pra desenvolver pra web, usando o Lift. Dessas ‘novas’ linguagens que tem uma boa plataforma e suportam concorrência, Scala parace ser a mais pragmática pra mim, que desenvolvo pra web. Não acho que tenha muita coisa a ver a linguagem ser estática/dinâmica e a produtividade que ela te dá. A maioria do pessoal que critica linguagens estáticas dizendo que são verbosas e menos produtivas, falam isso porque as linguagens estáticas que conhecem tem sistemas de tipos pouco expressivos comparados a haskell, ml, ocaml.Segundo o criador do Lift, que já trabalhou com Rails, Scala tem grande parte da flexibilidade do Ruby e ainda tem as vantagens que um bom sistema de tipos em uma linguagem estaticamente tipada pode trazer. Parece ser uma boa apsota pra quem quer sair do lugar comum e não quer ficar preso a uma linguagem que tem features interessantes, mas que não é muito pragmática.
O Alex Payne em seu livro tambem fala isto, ele fala que a verbosidade se da tambem pela falta de type inference, o que scala tem:
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .Na verdade nao!! depende do compilador que fizerem. Por exemplo é fato que o JRuby é lento, e que o do Scala roda praticamente igual java na JVM!
JRuby é mais lento porque carrega mais dependencias na inicialização. Isso é perfeitamente visível usando um debugger. Depois que o hotspot compilou para código nativo, ele roda na mesma velocidade que java, ou qualquer outro código na jvm, porque são praticamente o mesmo código. Quem dita isso é o hotspot.
Bom eu não tenho muito know-how para discutir isto profundamente, mas seguindo tua logica todos os códigos feitos em C por exemplo rodariam na mesma velocidade. E onde fica a optimização??? Falei do compilador porque os caras podem ter feito um que gera um bytecode sofrivel, sem pensar na performance.
Scala tem boa performance mas é estatica e por isso não é muito apropriada para desenvolvimento web.JRuby ainda possui uma implementação muito pobre na JVM.
Groovy é boa para web mas assim como Ruby, não para aplicações que requer alta performance.
Para substituir Java como linguagem que é pau pra toda obra e desenvolver qualquer tipo de programa, Clojure sem dúvida. A comunidade esta crescendo bastante, assim como o suporte oferecido por IDEs.
E porque estatica nao seria boa para web?? O que estatica tem haver com web ou qualquer outra coisa?
O fato é que ser estatica é exatamente um ponto defendido pelos criadores e adeptos.
Aplicações web costumam requerer 100% de disponibilidade, poder corrigir bugs sem precisar derrubar o servidor é um grande negócio. Em clojure voce poder conectar com um processo web e efetuar as alterações necessárias remotamente.
Acredito que isso possa ser feito em outras linguagens dinamicas, mas clojure é melhor projetada pra esse tipo de coisa. Como vc faria em Scala?
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .Na verdade nao!! depende do compilador que fizerem. Por exemplo é fato que o JRuby é lento, e que o do Scala roda praticamente igual java na JVM!
JRuby é mais lento porque carrega mais dependencias na inicialização. Isso é perfeitamente visível usando um debugger. Depois que o hotspot compilou para código nativo, ele roda na mesma velocidade que java, ou qualquer outro código na jvm, porque são praticamente o mesmo código. Quem dita isso é o hotspot.
Ou seja, nem todas as linguagens na JVM tem a mesma performance, depende de como ela foi projetada. Se ela faz uso constante de reflection por exemplo, claro que sera mais lenta. Não fale besteira.
Você pode corrigir bugs de apps feitas em clojure sem sequer reinicializar o servidor?
Scala parece ser bem interessante pra desenvolver pra web, usando o Lift. Dessas ‘novas’ linguagens que tem uma boa plataforma e suportam concorrência, Scala parace ser a mais pragmática pra mim, que desenvolvo pra web. Não acho que tenha muita coisa a ver a linguagem ser estática/dinâmica e a produtividade que ela te dá. A maioria do pessoal que critica linguagens estáticas dizendo que são verbosas e menos produtivas, falam isso porque as linguagens estáticas que conhecem tem sistemas de tipos pouco expressivos comparados a haskell, ml, ocaml.Segundo o criador do Lift, que já trabalhou com Rails, Scala tem grande parte da flexibilidade do Ruby e ainda tem as vantagens que um bom sistema de tipos em uma linguagem estaticamente tipada pode trazer. Parece ser uma boa apsota pra quem quer sair do lugar comum e não quer ficar preso a uma linguagem que tem features interessantes, mas que não é muito pragmática.
Tenta fazer uma aplicação web usando lift e depois volta pra dizer pra gente quanto scala é pragmatica. :lol:
Scala tem boa performance mas é estatica e por isso não é muito apropriada para desenvolvimento web.JRuby ainda possui uma implementação muito pobre na JVM.
Groovy é boa para web mas assim como Ruby, não para aplicações que requer alta performance.
Para substituir Java como linguagem que é pau pra toda obra e desenvolver qualquer tipo de programa, Clojure sem dúvida. A comunidade esta crescendo bastante, assim como o suporte oferecido por IDEs.
E porque estatica nao seria boa para web?? O que estatica tem haver com web ou qualquer outra coisa?
O fato é que ser estatica é exatamente um ponto defendido pelos criadores e adeptos.
Aplicações web costumam requerer 100% de disponibilidade, poder corrigir bugs sem precisar derrubar o servidor é um grande negócio. Em clojure voce poder conectar com um processo web e efetuar as alterações necessárias remotamente.
Acredito que isso possa ser feito em outras linguagens dinamicas, mas clojure é melhor projetada pra esse tipo de coisa. Como vc faria em Scala?
E eu sei la como eu faria? Faria como é feito hoje com 99% das aplicações web :lol: Bom eu nao sei se em Scala tem essa feature, ainda nem sai do primeiro capitulo do livro que peguei pra ler :oops: , Mas se esta falando de Hot Code Swapping, pelo que andei vendo aqui neste Scala x Erlang o erlang levou o ponto neste quesito, mas pelo que entedi o problema não é da linguagem em si, é a JVM que não tem muito suporte para isto, ou seja qualquer outra linguagem que estiver rodando na JVM estaria na mesma condição.
Ai ficam as perguntas:
1 - É sobre hot code swapping que estas falando?
2 - Clojure consegue fazer isto DENTRO da JVM? Pois a pergunta do post é sobre linguagem para a JVM.
Sim. Voce pode compilar codigo java em tempo de execução. Compilação AOT é permitido, mas não obrigatório.
1 - É sobre hot code swapping que estas falando?
Estou falando de alterações no código surtirem efeito sem precisar reiniciar a aplicação. Chame isso do que quiser.
2 - Clojure consegue fazer isto DENTRO da JVM? Pois a pergunta do post é sobre linguagem para a JVM.
Atualmente clojure so roda na jvm, apesar que existe um projeto em andamento para portar para CLR.
1 - É sobre hot code swapping que estas falando?Estou falando de alterações no código surtirem efeito sem precisar reiniciar a aplicação. Chame isso do que quiser.
2 - Clojure consegue fazer isto DENTRO da JVM? Pois a pergunta do post é sobre linguagem para a JVM.Atualmente clojure so roda na jvm, apesar que existe um projeto em andamento para portar para CLR.
Então é possivel isto com Clojure? Bacana, e como chamam esta feature? Tem nome?
Confesso que exagerei ao puxar sardinha para linguagens dinamicas em geral, como ultimamente programa apenas em clojure minha tendencia é acreditar que toda linguagem dinamica poderia oferecer esse tipo de coisa. Mas creio que seja mérito da linguagem clojure mesmo. Ruby por exemplo apesar de dinamica, não sei se da pra fazer isso normalmente, ou seja, sem qualquer tipo de magia negra ou outros subterfugios inconvenientes, como hacks na propria linguagem. Alguem com mais experiencia em Ruby poderia se manifestar?
Mas o fato é que, o simples fato da linguagem ser dinamica e nao haver etapas de compilação obrigatorio, já é suficiente para reduzir o down-time da aplicação e isso é muito importante em aplicações web.
Então é possivel isto com Clojure? Bacana, e como chamam esta feature? Tem nome?
Veja o link que passei anteriormente. Se não me engano é a primeira feature disponivel no menu a esquerda.
Sobre o Hot Swap…
A JVM realmente não suporta o Hot Swap, caso você altere assinaturas de métodos, ou altere os membros de uma classe por exemplo. MAS as linguagens dinâmicas que rodam na JVM costumam suportar isso. Como?
As linguagens dinâmicas não traduzem a classe em bytecode igual Java traduz… Ao invés disso, são criados mapas com os atributos e métodos, os atributos e métodos então podem ser adicionados e removidos desse mapa dinamicamente. Mas o código não está por exmeplo em um método separado igual é na linguagem Java. Por isso, uma linguagem dinâmica, teria que ter performance inferior a uma linguagem Java… Imagine que Java é nativo para a JVM e uma linguagem dinamica tem que ser interpretada…
em java vc tem em bytecode:
class MyClass {
public void meuMetodo(){
....
}
}
eu uma linguagem dinamica, o mesmo código poderia virar em bytecode:
class MyClass {
public Object executeMethod(String name, Object[] params){
if(name.equals("meuMetodo"){
....
}
}
}
Nao é exatamente assim… mas dá pra entender aqui… como funcionaria o hotswap…
Dá pra fazer alguma coisa nesse sentido também… usando um class loader turbinado…
Existe um class loader chamado jRebel… que permite que seja usado o hotswap…
Então é possivel isto com Clojure? Bacana, e como chamam esta feature? Tem nome?Veja o link que passei anteriormente. Se não me engano é a primeira feature disponivel no menu a esquerda.
É eu acabei achando isto aqui http://travis-whitton.blogspot.com/2009/09/hot-code-swapping-with-clojure.html, um cara mostrando como fazer.
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
nenhuma delas na minha opinião. Sobre performance, todas teriam a mesma, pois quem dita isso é a jvm.
Eu preferiria que a jvm suportasse c#. Acho uma linguagem muito boa. É só uma questão de opinião pessoal .Na verdade nao!! depende do compilador que fizerem. Por exemplo é fato que o JRuby é lento, e que o do Scala roda praticamente igual java na JVM!
JRuby é mais lento porque carrega mais dependencias na inicialização. Isso é perfeitamente visível usando um debugger. Depois que o hotspot compilou para código nativo, ele roda na mesma velocidade que java, ou qualquer outro código na jvm, porque são praticamente o mesmo código. Quem dita isso é o hotspot.Ou seja, nem todas as linguagens na JVM tem a mesma performance, depende de como ela foi projetada. Se ela faz uso constante de reflection por exemplo, claro que sera mais lenta. Não fale besteira.
Besteira onde?. Java usa reflection e não é lenta. O problema do jruby e do jpython se referem a inicialização e nada mais. Faça um benchmark e use uma ferramenta chamada depurador.
Não existe diferença de velocidade entre bytecodes(são a mesma coisa).
Cada uma…
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
Você mesmo disse. Não há diferença mesmo. Passou no hotspot é tudo farinha do mesmo saco.
Em ambiente de desenvolvimento, isso é possível, mas não sei se pode-se chamar isso de hot swapping, no mesmo sentido que usam para erlang. Em producao, no caso do passenger/mod_rails que é uma das alternativas mais usadas, são criadas várias instâncias da aplica’cão e guardadas em um pool (as AST’s de todo o código são geradas e reusadas para todos os requests). Se vc quiser atualizar essas instancias pré-carregadas vc precisa reiniciar o servidor, mas o processo é muito simples (no nginx basta um touch tmp/restart.txt).
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
O Rogel estava certo quando disse que “As linguagens dinâmicas não traduzem a classe em bytecode igual Java traduz…”, já que existe diferenca entre bytecodes gerados por linguagens diferentes.
Deem uma olhada nessa apresentacao: http://www.infoq.com/presentations/click-fast-bytecodes-funny-languages
A JVM realmente não suporta o Hot Swap, caso você altere assinaturas de métodos, ou altere os membros de uma classe por exemplo. MAS as linguagens dinâmicas que rodam na JVM costumam suportar isso. Como?As linguagens dinâmicas não traduzem a classe em bytecode igual Java traduz… Ao invés disso, são criados mapas com os atributos e métodos, os atributos e métodos então podem ser adicionados e removidos desse mapa dinamicamente. Mas o código não está por exmeplo em um método separado igual é na linguagem Java. Por isso, uma linguagem dinâmica, teria que ter performance inferior a uma linguagem Java… Imagine que Java é nativo para a JVM e uma linguagem dinamica tem que ser interpretada…
Por que vc insiste no exemplo de trocar de métodos em tempo de execucão? Se for disso que vc está falando, isso não tem nada a ver com hotswap, pois vc pode inserir/remover/alterar métodos de uma classe em tempo de execucao em algum programa Ruby, sem precisar mudar o codigo que está carregado na VM. Ainda, se for isso disso mesmo que vc está falando, a insercão dos métodos não acontece do jeito que vc disse, usando mapas com atributos e métodos.
No caso do JRuby, quando um método é adicionado uma nova classe é criada e carregada. Tem muito tempo que eu li esse artigo (http://www.realjenius.com/2009/10/06/distilling-jruby-the-jit-compiler/) e posso ter falado algo errado, mas acho que resumidamente é isso mesmo.
As linguagens dinâmicas não traduzem a classe em bytecode igual Java traduz… Ao invés disso, são criados mapas com os atributos e métodos, os atributos e métodos então podem ser adicionados e removidos desse mapa dinamicamente. Mas o código não está por exmeplo em um método separado igual é na linguagem Java. Por isso, uma linguagem dinâmica, teria que ter performance inferior a uma linguagem Java… Imagine que Java é nativo para a JVM e uma linguagem dinamica tem que ser interpretada…
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
Bicho… vc é dificil demais… e depois fala que os outros é que nao sabem interpretar textos…
Por que vc insiste no exemplo de trocar de métodos em tempo de execucão? Se for disso que vc está falando, isso não tem nada a ver com hotswap, pois vc pode inserir/remover/alterar métodos de uma classe em tempo de execucao em algum programa Ruby, sem precisar mudar o codigo que está carregado na VM. Ainda, se for isso disso mesmo que vc está falando, a insercão dos métodos não acontece do jeito que vc disse, usando mapas com atributos e métodos.
No caso do JRuby, quando um método é adicionado uma nova classe é criada e carregada. Tem muito tempo que eu li esse artigo (http://www.realjenius.com/2009/10/06/distilling-jruby-the-jit-compiler/) e posso ter falado algo errado, mas acho que resumidamente é isso mesmo.
Mas o Ruby não roda na JVM…
O hotswap sobre inserir remover alterar métodos de uma classe não funcionam em Java… e funcionam em algumas linguagens dinamicas… por isso coloquei como exemplo…
O negócio de mapas com atributos e métodos… uma vez li sobre uma linguagem que faz assim… infelizmente não lembro qual aqui… mas isso poderia ser uma forma de fazer…
O texto que vc citou é sobre o JRuby… esse sim roda na JVM… mas cada linguagem pode ter uma estratégia de fazer o HotSwap…
Nesse mesmo texto que vc citou… tem lá
Acho que vc não tá muito “aware” sobre isso… heheheh
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
Você mesmo disse. Não há diferença mesmo. Passou no hotspot é tudo farinha do mesmo saco.
Se for compilado para o mesmo código em bytecode não faz diferença. Mas vc não disse isso, vc falou que todas as linguagens tem a mesma performance. Mas isso não pode ser dito por que cada linguagem é implementada de uma maneira.
E o fato da linguagem ser dinamica significa que não se sabe quando o código vai ser compilado. Isso faz parte do projeto da linguagem. Pode ser em tempo de execução, pode ser antes se houver type hints, pode ser nunca, que seria o pior em termos de performance.
Design influencia performance até mesmo em aplicações feitas em puro Java. Porque seria diferente com linguagens?
Mas o Ruby não roda na JVM…
Eu sei que vc não é obrigado a saber que o JRuby existe desde 2001, mas poderia pelo menos ter clicado no link que eu postei antes de responder.
O hotswap sobre inserir remover alterar métodos de uma classe não funcionam em Java… e funcionam em algumas linguagens dinamicas… por isso coloquei como exemplo…
O negócio de mapas com atributos e métodos… uma vez li sobre uma linguagem que faz assim… infelizmente não lembro qual aqui… mas isso poderia ser uma forma de fazer…
O texto que vc citou é sobre o JRuby… esse sim roda na JVM… mas cada linguagem pode ter uma estratégia de fazer o HotSwap…
Nesse mesmo texto que vc citou… tem lá
Java, as you may or may not be aware, prevents the modification of any loaded classes in the VMAcho que vc não tá muito “aware” sobre isso… heheheh
Uai, uma hora vc fala que não roda na JVM e algumas linhas abaixo fala que roda.
Estamos falando de linguagens na JVM, certo? Ruby é uma delas, não é? Eu estava ‘aware’ que java não deixa modificar classes na carregadas na JVM, foi por isso que eu disse o lance do JRuby criar as classes novas toda vez que um método é adicionado.
Editei para corrigir uma trollagem desnecessária. O guj me deixa assim. 
Voce quer pintar todas as linguagens pra JVM no mesmo quadro e acaba falando abobrinha. Linguagens dinamicas como clojure são compiladas, e quando isso acontece vira bytecode e já era, não ha qualquer diferenca entre código nativo e codigo dinamico.
Você mesmo disse. Não há diferença mesmo. Passou no hotspot é tudo farinha do mesmo saco.
Se for compilado para o mesmo código em bytecode não faz diferença. Mas vc não disse isso, vc falou que todas as linguagens tem a mesma performance. Mas isso não pode ser dito por que cada linguagem é implementada de uma maneira.
E o fato da linguagem ser dinamica significa que não se sabe quando o código vai ser compilado. Isso faz parte do projeto da linguagem. Pode ser em tempo de execução, pode ser antes se houver type hints, pode ser nunca, que seria o pior em termos de performance.
Design influencia performance até mesmo em aplicações feitas em puro Java. Porque seria diferente com linguagens?
O design influencia na performance no quesito de haver mais código gerado pelo programador, e que é compilado. A linguagem não tem nada haver com isso.
As instruções geradas pelo compilador de python e do de java são exatamente iguais para o hotspot.
O único problema de performance entre as linguagens é do programador, como citado anteriormente. Agora, isso vale se o compilador python ou ruby seguem o mesmo desenho do java. Não estou falando de lexico ou semantico, mas o linkador, que vai gerar bytecode.
Se ele é diferente não haveria nem porque implementar essas linguagens na jvm.
Eu sei que vc não é obrigado a saber que o JRuby existe desde 2001, mas poderia pelo menos ter clicado no link que eu postei antes de responder.
Já que vc editou a trollagem… editei tb… 
Eu falei que a JVM não suporta o code swap… Então vc tem que usar algumas técnicas… para simular o hotswap…
Tudo certo então… estamos falando a mesma coisa… eheh
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.
Rogel, le o texto inteiro pra vc entender do que estou falando.
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…
O Rogel estava certo quando disse que “As linguagens dinâmicas não traduzem a classe em bytecode igual Java traduz…”, já que existe diferenca entre bytecodes gerados por linguagens diferentes.
Deem uma olhada nessa apresentacao: http://www.infoq.com/presentations/click-fast-bytecodes-funny-languages
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.
Tem a ver com o fato de uma linguagem ser diferente da outra… logo… o compilador de uma … pode gerar código melhor do que o compilador da outra
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.
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.
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…
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.
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.
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.
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.
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.
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.
Mas com uma solução mais robusta… acho seria possível tb…
Talvez o pessoal ainda nao chegou nessa etapa
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
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.
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
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.
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.
Achei aqui… a história do mapa que tinha falado… é sobre o JRuby… inclusive:
Fonte: http://www.zeroturnaround.com/blog/reloading_java_classes_401_hotswap_jrebel/
Tanto é que Scala é estatica e tb não gera o mesmo bytecode que Java. Como vc mesmo disse.
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.
Uma boa oportunidade para exercitar o poder das abstrações. 
Usaria Scala para projetos pesados de integração e JRuby para aplicações mais light Web :-).
Quem aqui tem tempo pra ficar estudando linguagem X pra fazer uma coisa, linguagem Y pra fazer outra, linguagem Z pra outra…
Usaria Scala para projetos pesados de integração e JRuby para aplicações mais light Web :-).Quem aqui tem tempo pra ficar estudando linguagem X pra fazer uma coisa, linguagem Y pra fazer outra, linguagem Z pra outra…
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 …