Estou disposto a aprender uma linguagem de scripting… acho que está mais do que na hora…
a pergunta é… Ruby é a escolha Certa™ ? a IDE para Ruby do NetBeans 6.0 está bem legal…
o python eu achei fraco ( o jython esta quase morto) e o Perl tem uma sintaxe terrivel !!!
Alguem ae usa Ruby que não seja me frameworks web ? (a lá RoR)
Alguem ae realment escreveu sistemas e usou ruby para implementar tudo ?
Onde devo utilizar uma linguagem de scripting ??? e por q ?
valeus !
Esquece essa historia de “linguagem de scripting”. Linguagem de programacao eh linguagem de programacao e ponto.
Bom não há como negar que a galera de Ruby anda fazendo bastante barulho.
A linguagem tem sido usada em varias empresas renomadas é só dar uma busca no google que você acha.
Duas que eu conheço é TW (cv) que tem um produto feito em Ruby e a Webmedia utiliza tambem (calcado ou chapiewski).
Se eu nao me engano eu vi algum post do pcalcado dizendo que usava o Ruby pra
automatizar algum tipo de deploy ou algo do tipo na Webmedia ai teria que aguardar por respostas do pessoal.
Onde você tem mudanças em runtime constantes ou não… 
Porque com uma linguagem interpretada você nao precisa de
restart’s e seu sistema de alta disponibilidade sempre estara disponivel… 
Bons estudos. :thumbup:
Acho que deveria também considerar fortemente o Groovy. O crescimento da linguagem e melhoramento da mesma, com refinamento de algumas (MOP - por exemplo) têm trazido muita gente boa à apostar na mesma.
Seam, possui integração com Groovy, a JetBrains colocou Grails e Groovy em evidência na sua nova versão de IDE.
Um fato que muitos se esquecem é que a melhor plataforma para se rodar Ruby dentro de pouco tempo será (senão já é) Java, via projeto JRuby. Entretanto, quando comparado ao Groovy em diversos quesitos, ainda está muito atrás.
A sintaxe e linguagem são interassantíssimas, muito menos verbosa que o groovy que lembra bastante o java. A parte boa é a migração, fica bastante simples sem precisar pensar de maneira muito diferente.
Particularmente não acho excludentes, estudo as duas Ruby e Groovy, cada qual com suas características, mas hoje pela melhor integração, nos projetos com Java prefiro utilizar a segunda.
[]´s
Felipe.
PS: Alguém já viu os requisitos de memória do Mingle para rodar ? (JRuby) Comparem com Xplanner … aliás melhorou muito desde a última vez que tinha olhado o projeto.
PS2: Groovy não precisa de maracutaia para ser compilado, caso o desenvolvedor queira manter seu código à salvo, propriedade intelectual … PS3: Louds , conheço decompiladores, sei que técnicas de ofuscação não são sinônimo de garantia, mas melhora melhora 
…por exemplo?
Hmm… sei la, eh justamente esse “sem pensar de maneira diferente” que me faz perder o interesse por Groovy/Grails. Nao me ajuda muito migrar de uma linguagem chata e burocratica pra uma que seja so chata :mrgreen:
O que tem os requisitos de memoria do Mingle?
Idem em JRuby… ja deu uma olhada no jrubyc?
[color=olive]Performance , está bem atrás de groovy… Integração com Java ? Ainda também deficitário, quando comparado ao groovy…diferenças entre Ruby e JRuby no modo de programar… Groovy é nativo e as anotações da versão 1.1 começam a tornar a linguagem bem atraente, para estender Spring, Hibernate, Seam … a coisa vai ficar boa para quem veio do mundo Java.
Quem quiser uma comparação de sintaxe tá ae : http://blogs.sun.com/sundararajan/entry/java_groovy_and_j_ruby
[/color]
[color=green]
Está exagerando, o groovy tem MOP bem desenhado entre outras características como closures e por aí vai … É mais verboso, mas o Ruby também tem suas esquisitices, aliás para alguns a sintaxe Human com @@ para indicar escopo, não é a coisa mais linda do mundo[/color].
[color=olive]1GB pra rodar um trequinho pequeno… que com Xplanner, um tomcat com 256 dá e sobra. [/color]
Não conhecia, bacana saber
Pra finalizar, já que a melhor plataforma Ruby é Java, penso em porquê jogar o legado de conhecimento e frameworks fora bem constituiídos. Se a questão é produtividade, grande argumento dos Rubisistas, com groovy tens a produtividade e maturidade.
Concordo que a linguagem não é tão sexy quanto Ruby, mas serve ao seu propósito, no meu ponto de vista.
Eu não sei o porquê dar preferência ao Groovy/Grails ao invés de Ruby/Rails. Apesar de eu ser um hobbyista nos dois, acho que a desvantagem do primeiro é ficar muito atrelado ao Java, dá pra rodar com sintaxe puro-Java se quiser. E com Ruby, não tenho dificuldade nenhuma em rodar em cima do Java EE.
E às vezes fico com dúvida se a mistura Ruby/Java é boa, exemplos:
Não consigo imaginar o Spring gerenciando beans do Ruby, por exemplo. (Nessa linguagem, acho que nem se chama bean!)
Não sei se Hibernate seria uma boa ao invés do Active Record do Rails.
Será que o managed bean do JSF poderia ser um objeto escrito em Ruby?!
Seria legal o Ruby invocar um EJB3? Aliás, Ruby aceita as annotations do Java?
O Controler do Ruby, poderia ser um Stateful Session Bean controlado pelo Seam? (Não conheço o Seam integrado ao Groovy, apenas ao JSF.)
São mais dúvidas do que certezas.
[quote=Leonardo3001]Eu não sei o porquê dar preferência ao Groovy/Grails ao invés de Ruby/Rails. Apesar de eu ser um hobbyista nos dois, acho que a desvantagem do primeiro é ficar muito atrelado ao Java, dá pra rodar com sintaxe puro-Java se quiser. E com Ruby, não tenho dificuldade nenhuma em rodar em cima do Java EE.
E às vezes fico com dúvida se a mistura Ruby/Java é boa, exemplos:
Não consigo imaginar o Spring gerenciando beans do Ruby, por exemplo. (Nessa linguagem, acho que nem se chama bean!)
Não sei se Hibernate seria uma boa ao invés do Active Record do Rails.
Será que o managed bean do JSF poderia ser um objeto escrito em Ruby?!
Seria legal o Ruby invocar um EJB3? Aliás, Ruby aceita as annotations do Java?
O Controler do Ruby, poderia ser um Stateful Session Bean controlado pelo Seam? (Não conheço o Seam integrado ao Groovy, apenas ao JSF.)
São mais dúvidas do que certezas.
[/quote]
Bom, aí vc precisa estudar também um pouquinho mais os cenários e frameworks. ActiveRecord nem de longe se equipara ao Hibernate e isso já foi discutido anteriormente aqui.
Comparar Rails com Grails também não tem muito haver, mas uma das coisas que menos gosto quando vejo projetos rails são regras de negócio atreladas ao controle de fluxo MVC. No Grails vc pode isolar essa parte e fazer por IoC com o Spring por debaixo dos bastidores.
Assim como no Rails que há uma série de plugins, no Grails também, desde Compass ( framework de busca) à Acegi para segurança.
A questão inerente à infra-estrutura EJB vai depender do tipo de cenário que possui, desde cluster fail-over à mensagens assíncronas com MDB´s para integração.
Aí começam algumas diferenças e realmente como developer java, não quero jogar minha expertise no ralo e quebrar a cabeça pra resolver questões como essa, que estão bem resolvidas no framework ejb3 por exemplo.
Kenobi, discordo que o JRuby seja a melhor implementação do Ruby. Isto é uma questão bastante subjetiva, existindo uma implementação mais adequada para cada situação. Ainda assim, mesmo ganhando em questões de performance quando comparado com o MRI, o JRuby ainda tem o IronRuby como concorrente, sem mencionar as versões futuras do Ruby, que usaram a YARV e terão novidades que demorarão a ser adicionadas em ambas as implementações paralelas, se é que um dia serão. Enfim, cada implementação tem suas vantagens e desvantagens, portanto não acho que exista uma delas que possa ser definida categoricamente como a melhor.
De qualquer forma, respondendo ao chun, atualmente estou direcionando os meus estudos para Ruby e Rails, e acho que ambos são excelentes plataformas de desenvolvimento. Além disso, gostaria de lembrar que a expressão linguagem de script automaticamente nos faz presumir que a linguagem tem utilidade limitada, o que, pelo menos no caso do Ruby, está longe da verdade.
Opa… onde vc acha a coisa deficitaria?
@@ eh pouquississimo usado num codigo “normal”… mas se vc quiser ver coisas bizarras, class_eval eh seu amigo :mrgreen:
É impressão minha ou a SUn tá absorvendo o Ruby para a família Java?
Apoio ao JRuby, suporte no glassfish, netbeans…
Será que Ruby vai ser uma alternativa ao Servlets / JSP / [ JSF | Framework ] ?
IMagino algo
RoR + EJB + JPA…
Seria possível? Ou tô falando besteira?
Ps: Nunca usei Ruby, mas tenho me interessado por ela…
cv,
Quanto a linguagem de scripting… me refiro por ser 100% interpretada… e isso conta sim… imagina q vou simplesmente opitar por ruby pela sintaxe e pela maravilhosa forma de criacao de DSL’s… ai chego na ponta e me ferro por causa de performance e integracao…
Java tem uma api para parte visual… o Swing… e em Ruby ? vou ter que ficar usando binds para GTK ou para Swing mesmo… ae que comeca a salada…
Percebo que ruby eh legal para um monte de coisas… mas para sistemas complexos, que mereca um nivel de integracao com outras tecnologias… ruby está bem atras …
Por isso deste topic… quero saber as reais vantagens de se programar com uma linguagem deste tipo
Conta? Cade os seu benchmark realista baseado em uma aplicacao de verdade rodando em JRuby ou MRI me dizendo que a performance do Ruby eh insuficiente? Sem dados de verdade, eh a minha palavra contra a sua. Mas eu tenho exemplos de aplicacoes em que a performance foi mais do que aceitavel - tanto que a gente nem precisou de fragment caching, e mesmo assim bateu nos 400 requests/segundo:
[quote=josenaldo]Imagino algo
RoR + EJB + JPA…
Seria possível? Ou tô falando besteira?[/quote]
Perfeitamente possivel 
Hummm…
Seria o Ruby on Rails então mais uma opção de MVC com integração com o Java e suportada pela Sun?
Isso mataria o JSP/JSF ou seria apenas mais uma opção?
Se for uma opção, em quais casos podemos ter vantagem utilizando o RoR e não o JSP/JSF?
José, aí entra outra discussão, Component Based vs ActionBased e a plataforma Java possui um número bastante abrangente de frameworks em cada um dos dois modelos.
Só para salientar JSF sozinho não resolve os problemas de persistência, segurança entre outros como RoR; por isso teria que comparar RoR com Seam por exemplo.
Aí entra a discussão do frontend, entre Component Based e ActionBased, qual dos dois modelos é mais produtivo e isso vai depender muito do nível da interatividade com o usuário. Também tem questões técnicas envolvidas, até a versão corrente do JSF mesmo os componentes não possuindo estado, o seu ciclo de vida possui. Há até uma recomendação do Garry para a versão 2.0 do cliclo ser statless.
Voltando para o Seam, uma coisa que me deixou feliz foi a possibilidade de desacoplar JSF e plugar outro mecanismo component based.
PS: Se bem que alguém podia criar renderkit (Flex-Flash) para JSF, pois a evolução do JSF também promete.
Em fim, acho que para aplicações de pequeno e médio porte, sem integração com sistemas legados e um modelo relacional relativamente simples, ele vai muito bem. À partir daí vc tem outras alternativas, como o dito anteriormente - Grails, onde a camada de abstração de dados é realizada pelo Hibernate e na próxima versão será totalmente integrado à JPA.
Hoje ficaria com esse esquema:
-Grails || RoR (Aplicações pequenas e médias para rápida conclusão)
-Seam (Aplicações de médio e grande porte)
Deixando claro que não sou à favor de se usar uma arquitetura pronta pra sopinha para todos os casos.
Em muitos cenários, será necessária a presença de um arquiteto para desenhar uma solução condizente ao problema utilizando Patterns (implementados muitas vezes por frameworks), alguns módulos como SpringIoC, Hibernate, Compass, EJb3, Drools e por aí vai , criando uma estrutura que contemple as necessidades de negócio do cliente.
Chun, foi 100% equivocado aqui. A linha entre ser interpretado ou não é muito tênue. Poderíamos ficar aqui discutindo 15 páginas qual a diferença entre gerar código nativo ou simplesmente andar numa AST e só ficar chamando código nativo pré-compilado. Não sei nem se dá para dizer que isso é ser interpretado mesmo…
Enfim, mesmo eu não querendo discutir isso, você está errado. Ruby não precisa ser e não é 100% interpretado. O JRuby, por exemplo, já gera bytecode Java a partir de código Ruby faz um tempinho (você deu uma olhada no jrubyc que o cv comentou?). Na mesma linha, o Gardens Point Ruby.NET tb compila ruby para .Net (eu não lembro como chama o bytecode deles) e o XRuby tb vai compilar código Ruby para bytecode Java. O Rubinius e a YARV geram bytecode próprio.
Mesmo Java no começo todo mundo dizia que era interpretado, aí vem um tal de JIT. Mesma coisa com Ruby, o JRuby já vem com o JITer de presente.
Por isso eu concordo com o que o cv disse. Para com isso de linguagem de script, é linguagem de programação e ponto. Essa coisa de ser interpretado ou não quase nunca vale.
Mesma coisa… se você quiser você faz código Ruby usando Swing. É o exemplo mais comum de uso do JRuby que se tem por aí.
Nem eu, nem a Oracle, nem a TW acham (por exemplo).
Cara na dúvida aprenda as duas. Eu começaria de Ruby para fugir um pouco desse “jeito Java de pensar” do Groovy e abrir um pouco a cabeça. Acho que mudar de paradigma é o maior ganho que você leva de uma experiência dessa.
Conta? Cade os seu benchmark realista baseado em uma aplicacao de verdade rodando em JRuby ou MRI me dizendo que a performance do Ruby eh insuficiente? Sem dados de verdade, eh a minha palavra contra a sua. Mas eu tenho exemplos de aplicacoes em que a performance foi mais do que aceitavel - tanto que a gente nem precisou de fragment caching, e mesmo assim bateu nos 400 requests/segundo:
Depois de ler essa nota no InfoQ http://www.infoq.com/news/2007/11/oracle-mix-jruby-experiences, pergunto, quantas empresas tem a oportunidade de contratar a empresa que vc trabalha CV para dar suporte ao desenvolvimento ?
Viu que o JRuby estava com bug e a performance era terrível ? Tinha lido meses antes sobre o desempenho e foi isso que reportei.
Agora 200x mínimo (pra mais) mais lento, acho que onera bastante TCO.
[]´s
Como eu trabalho no Windows, Ruby é a minha salvação na hora de automatizar tarefas. Eu recomendo instalar o Ruby e usá-lo em testes, builds, e naquelas tarefas de manipulação de arquivo que normalmente você faria com muito duplo-clique e drag-and-drop. Você vai ver que o Ruby não coloca obstáculos na sua frente. Em vez disso, ele se curva obediente ao programador e se desdobra pra satisfazê-lo.
Agora, para quem está com medo de Ruby acabar com JSF, Hibernate, e tudo aquilo que você penou por anos pra dominar, vamos com calma que não é por aí. Ruby não vai acabar com Java, do mesmo jeito que ASP.Net também criou muito barulho como “Java-killer” e no final virou mais uma opção. Então, antes de falar que Ruby é lento, não se integra bem com outras plataformas, ou não funciona para sistemas grandes, tente deixar o seu medo de lado e faça um teste objetivo.
A gente nao escolhe cliente a dedo - eh o contrario
De qualquer forma, o trabalho que o pessoal ta fazendo com o RubyWorks e JRuby eh aberto e opensource bonitinho do jeito que o povo gosta. No fim, o tempo que a galera do Mix investiu em melhorar a performance do Mix e JRuby acabou melhorando a vida de todo mundo que usa JRuby.
Hein!? Leia o quote de novo:
De 20-40 pra 200 pra 400-600 depois do warm-up com dois dias de trabalho oneram bastante o TCO onde?!