Sim, mas a questão era que Ruby tem bibliotecas SSH disponíveis, não que o Capistrano faz deploy no windows 
(e caramba, deploy no windows? Que os deuses tenham piedade!)
Estou movendo a benchmark pra esse tópico se alguém se interessar a ajudar -> http://www.guj.com.br/posts/list/109782.java
Sim, mas a questão era que Ruby tem bibliotecas SSH disponíveis, não que o Capistrano faz deploy no windows (e caramba, deploy no windows? Que os deuses tenham piedade!)[/quote]
Eu sei do net-ssh, e que o Capistrano apenas o utiliza pra cumprir seu objetivo, como era de se esperar. Só tava mesmo esclarecendo o neófito quanto a dúvida sobre a disponibilidade de SOs do Capistrano. E sobre usar o Capistrano no Windows, eu já fui “forçado” a fazer isso. 
Eu já comentei sobre isso antes… o ponto é que se vc aprende meia duzia de frases em turco isso não significa que vc pensa em turco. Para aprender turco vc tem que pensar em turco.
Só quando vc pensar em turco vc pode dizer que aprendeu turco.
O mesmo com linguagens de programação. Ficar pulando de uma para a outro todo o ano não me parece que vc aprenda a pensar naquele formato. Um ano é muito pouco.
O meu ponto é exactamente esse : para aprender uma linguagem vc tem que conhecer , pensar instititivamente, com as estruturas dela. Isso não acontece em um ano.
Porque Java é mais que C. É uma JVM , memoria gerenciável, OO , segura …
A bibliotecas exisitam em C escritas de forma OO ? estruturada sequer ?
A questão é exatamente essa Rubi é mais que Java ? O que justifica eu reescrever o JMS ou JAAS ou o JNDI Ou JDBC em Rubi ? Não é melhor simplesmente escrever o rails em Java ?
Se o ponto é adquirir conceitos novos, importa-os para a platafora que já usas. Se o ponto é mudar de linguagem, tem que reimplimentar tudo. E qual é a vantagem nisso ?
Java pode ter reimplementado algumas coisas já feitas antes, mas haviam vantagens claras. Quais são essas vantagens claras do Rubi que a plataforma Java não tem?
Existe plataforma RoR? Não!
[/quote]
Eu nunca disse que existia. Aliás esse é tb o ponto : como justificar trocar uma plataforma por uma simples linguagem sem plataforma ?
O ponto é que ainda não roda em Java. Mas quanto rodar eu simplesmente estarei usando a plataforma java.
É exactamente isso que é logico, trazer o RoR para java e não levar os programadores java para Rubi (fora da jvm). Tenho que aprender rubi para usar o RoR, ok. Mas não tenho que sair da plataforma java. Poderei usar o JNDI, JAAS, JDBC, Hibernate , etc…
O pessoal intrepretou mal o exempl odo Grails. O ponto não é que é uma copia do RoR, o ponto é que o port dos conceitos que foram novidade no RoR para a plataforma Java.
Básicamente o pessoal de RoR defende usá-lo em vez de java. Mas qual é a vantagem disso?
-
Aprender conceitos novos e uma linguagem nova. Não apenas conceitos de meta-programção, mas uma sintaxe nova. Com Grails vc aprende os mesmos conceitos de meta-programação com a mesma sintaxe do java (que pode evoluir naturalmente para uma linguagem mais script, sem pressa e sem forçar a barra).
-
Aprender outra tecnologia. Para quê ? Qual é o futuro dela ? Quem aposta nela ? Alguem está usando rubi sem ser com rails para criar coisas que possam substituir digamos… EJB3 ? JMS ? JNDI ? etc… a resposta que se ouve é “não tem mais vai ter. e vc pode implementar o seu…” … oras! eu posso implementar Rails em java , muito mais simples que implementar EJB , JMS ,etc… em rubi… E ai que entra o exemplo do Grails mais uma vez. Simplesmente agrupa um bando de frameworks já tradicionais e joga um pó-de-script-like-syntax-sugar e pronto. Mas nem precisa de goovy para fazer isso. Java normal e uma boa dose de bytecode manipulation e voilá (afinal grrovy é uma forma elegante de bytecode mnipulation assim como jrubi e qq outra linguagem de script para jvm)
Estes argumentos para ir para rubi/ RoR não são fortes o suficiente para quem já sabe, usa, tem experiencia, tem bagagem com java. Dai o exemplo do cara que sai da facul, para esse tanto faz escolher um ou outro, mas para quem já investiu X anos em java é preciso mais do hype para fazer a mudança. Não ?
Como o bytecode pode ser considerado interpretação ? Se assim for o java tb é interpretado ( e java é hibrido) …
Grovvy e Java para a JVM é a mesma coisa. AS vantagens e desvantagens são as mesmas.
A unica coisa diferente são as invocações especiais do grovvy que tem que ser simuladas via objetos
Com as novas jvm que vêm por ai isso vai mudar. É uma questão tencologia.
Agora, rubi ( sem ser jrubi) é intrepretado como java era na versão 1, sem hotspot. Isso sim é ser intrepretado.
Acho que vc está misturando groovy com script groovy (esse sim 100% intepretado) via Script API. Não ?
[quote=Leonardo3001]
:arrow: Alguém citou que Groovy compila em bytecode Java e que Ruby não. Falso, todo pacote JRuby vem com o compilador jrubyc que faz essa compilação. Então talvez a performance entre as linguagens não seja tão diferente.[/quote]
Vc sabe que Rubi e JRubi são coisas diferentes , certo ? JRubi é a linguagem rubi rodando na jvm. rubi é a linguagme rubi rodando fora da jvm.
Portanto, Groovy compila bytecode, rubi não. É claro que não porque rubi nem roda na jvm.
Agora Grovvy e JRuby, sim, compilam para bytecode.
[quote=sergiotaborda][quote=leonardo3001]
RoR é um framework que roda, primariamente, em plataforma LAMP. Existe também a possibilidade de rodar em cima da plataforma Java. Não entendo seu ponto.
[/quote]
O ponto é que ainda não roda em Java. [/quote]
O Rails já roda na plataforma Java há tempos através do JRuby.
[quote=sergiotaborda]Agora, rubi ( sem ser jrubi) é intrepretado como java era na versão 1, sem hotspot. Isso sim é ser intrepretado.
Acho que vc está misturando groovy com script groovy (esse sim 100% intepretado) via Script API. Não ?[/quote]
Considerando que você está falando de JRuby e não de Ruby (que não tem haver com o assunto), não.
Além de haver um compilador estático, o jrubyc, todo o código JRuby é sim transformado pra bytecode e o bytecode é interpretado. Tanto o é que um dos primeiros problemas do JRuby era JITar código demais, estourando o permgen da JVM.
[quote=Mauricio Linhares]
Vamos lá, esse foi provavelmente o comentário mais obtuso que você já fez aqui. Espero que quem esteja lendo essa thread ignore por completo essa sua afirmação e entenda que não se aprende outras linguagens pra se conhecer a fundo, mas para conhecer outras formas e outros paradigmas de se resolver os mesmos problemas.[/quote]
Pode se adaptar isso aos frameworks afinal… são varias maneiras diferentes para resolver o mesmo problema