[quote=Filipe Chagas][quote=Herrera]
Não reivente a roda, use Grails.
Herrera[/quote]
O correto seria: Não reivente a roda, use Rails!
Groovy é uma cópia de Ruby e Grails de Rails (até no nome). Não consigo encontrar motivos para utilizar.[/quote]
Humm… sinto muito - mas sou obrigado a discordar. Os desenvolvedores do Grails assim como você não são do tipo que reinventam a roda. Tanto é que eles não fizeram isso. O Grails roda em cima de frameworks já bem estabelecidos como Spring, Sitemesh, Quartz, Hibernate entre outros. Onde é que eles reinventaram a roda? Provavelmente o caminho que tiveram que percorrer para ter um framework like Rails é bem menor do que os esforço feito para criar o Rails do zero. Sendo assim, acho o Grails válido como opção ao Rails.
Você não acha perigoso dizer jamais? Eu não acho muito dificil ser produtivo em java como no Rails. Se você abrir mão de algumas loucuras arquiteturais que todo projeto java tem e escolher uma arquitetura apropriada, dá pra dar um banho de produtividade no Rails. Por exemplo, dependendo do perfil do projeto vc pode usar um bom framework component-based para o java - temos muitas opcoes. E em Rails, vc sugere o que?
Respeito sua resposta, no entanto, a produtividade tá muito mais ligado ao perfil dos desenvolvedores. Há programadores Rails que vão sempre fazer as Actions e as Views do zero, enquanto outros criam scripts ou customizam os templates de geração de código. Produtividade na minha opinião vai muito além de usar os “generate:views e generate:controllers” ou a simplicidade da linguagem.
Não seria JRuby uma cópia das linguagens que já nasceram pra JVM?
Ruby como linguagem é legal, mas sua VM é bugada, mas quem se importa, hoje em dia ou vc esta na JVM ou tenta, e nessa questão JRuby ainda é uma promessa e sua performance sofrível, sera que alguem aqui usaria JRuby em produção? Acho que o GUJ tentou e voltou atrás. (poderiam confirmar ou desmentir?)
Pelo que sei, os caras mais envolvidos no desenvolvimento do GUJ estão cada vez mais usando também Ruby/Rails. Neste sábado no Devinsampa, o Fabio Kung me contou que na Caelum o Java não foi abandonado mas pélo menos 70% dos seus desenvolvedores são fluentes em Ruby/Rails. E lá também tem gente que manja muito de Scala. Ate brinquei com o Guilherme Silveira (palestrou sobre http://github.com/caelum/restfulie ) que no fim do curso que ele está fazendo na USP de linguagens funcionais, erlang, Scala, etc., sairá o VRaptor para Scala (pura brincadeira mas não duvido nada)
Reiventaram a roda desenvolvendo um framework que faz exatamente as mesmas coisas que um outro framework já existente.
Se você olhar o código do Rails e o código do Grails vai ver que as coisas não são bem assim.
De qualquer forma, não disse que Grails é ruim nem que não é uma opção válida. Eu disse que não consigo encontrar motivos para utilizá-lo, quando se tem um original muito melhor, muito mais maduro e completo à disposição.
Não é perigosoThiago. Usando Java é impossível atingir o nível de produtividade do Rails. Como eu disse, o Rails não é fantástico apenas pelos geradores e conceitos; Rails é fantástico pq usa Ruby e Ruby é absurdamente mais produtivo que Java.
Não Thiago, não dá! Eu gosto de Java e uso em vários projetos. É uma linguagem excelente, uma plataforma fantástica e tem suas aplicações. Mas dizer que é, ou pode ser, tão produtivo quanto Rails, Django ou qualquer framework que utilize linguagens dinâmicas, é loucura.
Não! JRuby é um port do Ruby para rodar na JVM. JVM é hoje uma plataforma e está aí exatamente pra isso: Possuir linguagens rodando sobre sua arquitetura. Um conceito inspirado na plataforma .NET.
Ruby não é legal, é fantástico. Assim como python, scala, etc…
E quanto à sua VM ser bugada, com que base você afirma isso?
[quote=Thiago Senna] Por exemplo, dependendo do perfil do projeto vc pode usar um bom framework component-based para o java - temos muitas opcoes. E em Rails, vc sugere o que?
[/quote]
Eu não utilizo component-based em Java por vários motivos que fogem à nossa discussão. De qualquer forma, Rails é altamente desacoplado e configurável e te dá total liberdade de arquitetura (E isso vai melhorar ainda mais no Rails 3, previsto para o início do próximo ano).
Mas se a sua intenção com essa afirmação é deixar claro que existem casos onde adotar Java a despeito de Ruby/Scala/Python é a melhor escolha, concordo contigo! Existem inúmeras situações onde Java seja a melhor opção! Existem inúmeras onde Scala seja a melhor opção! Existem inúmeras situações onde Erlang seja a melhor opção!
A discussão não é essa, amigo. Eu não disse que Java é do inferno e que jamais deve ser utilizado. Eu disse que, usando Java, é impossível ser tão produtivo quando se usa Ruby. Isso é uma verdade indiscutível e não sou eu que estou dizendo. Estude um pouquinho das duas linguagens e comprove por si próprio.
[quote=Thiago Senna]
Produtividade na minha opinião vai muito além de usar os “generate:views e generate:controllers” ou a simplicidade da linguagem.[/quote]
Exatamente Thiago, você está chegando lá! E é exatamente por isso que Rails é fantástico!
Generators, qualquer um com um pouco de tempo livre, pode criar para qualquer linguagem e arquitetura. Rails não é fantástico pelos generators, vai muito além disso.
Este é o problema do “Blog de 15 minutos” que todo mundo lê e pensa que já aprendeu Rails. Quando se tem contato com o Rails no mundo real, você percebe a diferença de usar uma linguagem dinâmica sobre um framework com conceitos tão inovadores.
De qualquer maneira, não queremos começar flamewares aqui, não é mesmo.
Peço perdão se feri o coraçãozinho de alguém quando disse que não encontro motivos para usar Grails. Se você encontrou os seus, então use!
Lift, Grails, Play Framework, Pylons, Turbo Gears, Cake PHP … tantos frameworks inspirados ou com idéias parecidas ao Rails onde seus desenvolvedores preferiram reinventar a roda? Rails é ótimo, mas não é a última bolachinha do pacote.
[quote=Filipe Chagas]Se você olhar o código do Rails e o código do Grails vai ver que as coisas não são bem assim.
De qualquer forma, não disse que Grails é ruim nem que não é uma opção válida. Eu disse que não consigo encontrar motivos para utilizá-lo, quando se tem um original muito melhor, muito mais maduro e completo à disposição.[/quote]
A minha colocação se diz respeito ao código utilizado para criar o framework, e não para desenvolver nele. ORM, Controle, Jobs entre outras coisas o grails já reaproveitou de frameworks java bem estabelecidos enquanto no Rails eles tiveram que criar tudo isso. Ou seja, o Grails só se deu ao trabalho de copiar o estilo de desenvolvimento de Rails e não precisou criar nada do zero, como por exemplo, criar seu próprio ORM. É isso que eu quis dizer.
Só por causa da linguagem? Ok, então descordamos
Loucura? Sem exceção? Ok, caso sim, descordamos também.
[quote=Thiago Senna]
Lift, Grails, Play Framework, Pylons, Turbo Gears, Cake PHP … tantos frameworks inspirados ou com idéias parecidas ao Rails onde seus desenvolvedores preferiram reinventar a roda? Rails é ótimo, mas não é a última bolachinha do pacote.[/quote]
Não é a última mesmo. É a primeira! As outras são cópias. 8)
Lift é bem legal, vale a pena dar uma olhada. Pylons, só olhei superficialmente, mas me pareceu excelente também. Turbo Gears ainda não tive tempo de estudar. Cake PHP é podre, uma tentativa pífia de fazer em PHP coisas que se faz em Ruby.
[quote=Thiago Senna]
A minha colocação se diz respeito ao código utilizado para criar o framework, e não para desenvolver nele. [/quote]
Eu disse pra você olhar o código do Railse o código do Grails e não de aplicações desenvolvidas com eles.
Estou surpreso de conhecer alguem que nunca tenha ouvido falar de memory leaks no interpretador Ruby!
[quote=Luca]
Pelo que sei, os caras mais envolvidos no desenvolvimento do GUJ estão cada vez mais usando também Ruby/Rails. Neste sábado no Devinsampa, o Fabio Kung me contou que na Caelum o Java não foi abandonado mas pélo menos 70% dos seus desenvolvedores são fluentes em Ruby/Rails. E lá também tem gente que manja muito de Scala. Ate brinquei com o Guilherme Silveira (palestrou sobre http://github.com/caelum/restfulie ) que no fim do curso que ele está fazendo na USP de linguagens funcionais, erlang, Scala, etc., sairá o VRaptor para Scala (pura brincadeira mas não duvido nada)
[]s
Luca[/quote]
Mas afinal eles usam JRuby no site GUJ ou não? Voce sabe?
[quote=Filipe Chagas]Eu não utilizo component-based em Java por vários motivos que fogem à nossa discussão. De qualquer forma, Rails é altamente desacoplado e configurável e te dá total liberdade de arquitetura (E isso vai melhorar ainda mais no Rails 3, previsto para o início do próximo ano).
Mas se a sua intenção com essa afirmação é deixar claro que existem casos onde adotar Java a despeito de Ruby/Scala/Python é a melhor escolha, concordo contigo! Existem inúmeras situações onde Java seja a melhor opção! Existem inúmeras onde Scala seja a melhor opção! Existem inúmeras situações onde Erlang seja a melhor opção!
A discussão não é essa, amigo. Eu não disse que Java é do inferno e que jamais deve ser utilizado. Eu disse que, usando Java, é impossível ser tão produtivo quando se usa Ruby. Isso é uma verdade indiscutível e não sou eu que estou dizendo. Estude um pouquinho das duas linguagens e comprove por si próprio.
[/quote]
Ok!
[quote=Filipe Chagas]Exatamente Thiago, você está chegando lá! E é exatamente por isso que Rails é fantástico!
Generators, qualquer um com um pouco de tempo livre, pode criar para qualquer linguagem e arquitetura. Rails não é fantástico pelos generators, vai muito além disso.[/quote]
Sim, é um diferencial no Rails. Só não concordo com a afirmativa de que Rails é mais produtivo pq também posso fazer isso em java. Mas claro, o ambientes de desenvolvimento Rails e Grails é mais encorajador para utilizar essas práticas.
No java existe um mal parecido. Todo mundo aprendeu uma arquitetura de caixinha e não conseguem ou não querem sair dela. É neste momento que o Play é muito bem vindo - ele simplesmente saiu do senso comum - trouxe um ambiente novo para quem ainda sonha em ser produtivo em java
[quote=Filipe Chagas]De qualquer maneira, não queremos começar flamewares aqui, não é mesmo.
Peço perdão se feri o coraçãozinho de alguém quando disse que não encontro motivos para usar Grails. Se você encontrou os seus, então use![/quote]
Sim, claro!
Loucura? Sem exceção? Ok, caso sim, descordamos também.[/quote]
Concordo que um ambiente dinâmico é fundamental para a produtividade, mas frameworks numa linguagem estática podem simular essa feature (ou até mesmo empregar outras linguagens para o trabalho, que é o caso do framework play que usa linguagens dinâmicas para templates e no build).
Há bugs no interpretador Ruby. Assim como há no interpretador Java, python, etc.
Olha esse site que legal: http://bugs.sun.com/
Quando alguém diz que a ferramenta X é “bugada”, entendemos que ela está quebrada e inutilizável. O que não é verdade nem para o interpretador Ruby, nem para a JVM e nem para o interpretador Python.
Será que o JSF serve para alguma coisa além de justificar a necessidade de uso de IDE?
Dificilmente eu entraria feliz e convicto de que estão adotando a melhor solução no projeto de uma aplicação web usando JSF.
Só por verificar que o livro que ganhei do Ed Burns tem 833 páginas, já confirmei que as novas versões do JSF estão tão complexas como as anteriores. Típica xaropada inventada pelos maus programadores da Sun.
Na revista Mundo Java deste mês tem um artigo sobre os 10 maus hábitos dos desenvolvedores JSF. Ficou faltando só o principal: usar JSF.
[]s
Luca[/quote]
Oi Luca, concordo em partes contigo. Mas uma coisa devemos admitir, a componentização E principalmente, os componentes que o JSF oferece não tem comparação com o que temos hoje por aí em termos de facilidade. Por mais que exista alternativas boas, de mercado e open, na grande maioria te obriga a configurar um xml, registrar um filtro ou dois, customizar o CSS, usar uma TAGLIB :twisted: , e por ai vai…
[quote=Filipe Chagas][quote=mochuara] http://opensynapse.net/post/24570619/ruby-memory-leak-regular-expressions-in-class-methods
Estou surpreso de conhecer alguem que nunca tenha ouvido falar de memory leaks no interpretador Ruby!
[/quote]
Há bugs no interpretador Ruby. Assim como há no interpretador Java, python, etc.
Olha esse site que legal: http://bugs.sun.com/
Quando alguém diz que a ferramenta X é “bugada”, entendemos que ela está quebrada e inutilizável. O que não é verdade nem para o interpretador Ruby, nem para a JVM e nem para o interpretador Python.[/quote]
Então vc concorda que ha bugs no interpretador Ruby mas não concorda em dizer que ele esteja bugada? Ok, eu já deveria saber que não se discute com fanáticos em futebol, religião e linguagens de programação.
ps: Voce não apontou nenhum link com memory leak na JVM, só pra constar…
Loucura? Sem exceção? Ok, caso sim, descordamos também.[/quote]
Concordo que um ambiente dinâmico é fundamental para a produtividade, mas frameworks numa linguagem estática podem simular essa feature (ou até mesmo empregar outras linguagens para o trabalho, que é o caso do framework play que usa linguagens dinâmicas para templates e no build).[/quote]
Concordo contigo mochuara, mas veja o que você disse: “… mas frameworks numa linguagem estática podem simular essa feature …” depois disse “… framework play que usa linguagens dinâmicas para templates e …”. Usaram linguagens dinâmicas para aumentar a produtividade! E não poderiam ter tomado uma decisão melhor.
Essa é a grande sacada da JVM que, na minha opinião, é uma das melhores (senão a melhor) escolha de plataforma de desenvolvimento. Pois te dá a liberdade de usar sua excelente arquitetura unida com a produtividade de linguagens dinâmicas.
E só pra deixar claro que não sou xiita: Eu sou perfeitamente crente na possibilidade de, em breve, desenvolverem um framework muito melhor que Rails, usando linguagens dinâmicas e que rode de forma natural sobre a JVM. A única coisa que me deixa chateado é perderem tempo refazendo o Rails em outras linguagens. Este é o cerne do meu ponto de vista aqui.
[quote=mochuara]
Então vc concorda que ha bugs no interpretador Ruby mas não concorda em dizer que ele esteja bugada? Ok, eu já deveria saber que não se discute com fanáticos em futebol, religião e linguagens de programação.[/quote]
Não sou fanático amigo. Você é que está agindo como um.
Se formos usar o mesmo conceito podemos dizer que a JVM é bugada também?
Não mesmo, eu postei um link com inúmeros bugs na JVM. E nem por isso digo que ela é bugada e inutilizável, muito pelo contrário! (leia meu post anterior)
[quote=mochuara]
Bom então JRuby no site foi um experimento, parece que eles usam Java mesmo.[/quote]
No Guj eu também não utilizaria.
Já estava pronto quando pensaram em incluir, só por diversão, alguma coisinha de JRuby; Foi concebido e desenvolvido desde o início sobre Java e sua plataforma. JRuby não atende neste caso.
[quote=Filipe Chagas]
Concordo contigo mochuara, mas veja o que você disse: “… mas frameworks numa linguagem estática …” depois disse “… framework play que usa linguagens dinâmicas para templates e …”. Usaram linguagens dinâmicas para aumentar a produtividade! E não poderiam ter tomado uma decisão melhor.
Essa é a grande sacada da JVM que, na minha opinião, é uma das melhores (senão a melhor) escolha de plataforma de desenvolvimento. Pois te dá a liberdade de usar sua excelente arquitetura unida com a produtividade de linguagens dinâmicas.[/quote]
A maioria dos frameworks Java consegue aumentar produtividade usando mecanismos que dão mais dinamicidade ao desenvolvimento, vide Reflection API, XML, Annotations, AOP, etc… tudo isto sem abrir mão do Java que é estatico.
Por isso concordo que usar logo uma linguagem dinâmica de uma vez é bem melhor do que toda essa confusão que virou o ecossistema Java. Mas acontece que nem todas linguagens dinâmicas rodam bem na atual JVM, e JRuby é uma delas.
Pelo visto vc não sabe diferenciar bugs em componentes, bibliotecas, frameworks com bugs na implementação da linguagem. JVM é o estado da arte perto do MRI.
[quote=mochuara]Mas acontece que nem todas linguagens dinâmicas rodam bem na atual JVM, e JRuby é uma delas.
[/quote]
Concordo novamente. Por isso opto por usar Ruby e não JRuby. Este é um dos motivos que me deixam a ansiar por um framework inovador, melhor que Rails, que utilize linguagens dinâmicas e que rode sobre a JVM.
[quote=mochuara][quote=Filipe Chagas]
Não mesmo, eu postei um link com inúmeros bugs na JVM. E nem por isso digo que ela é bugada e inutilizável, muito pelo contrário! (leia meu post anterior)
[/quote]
Pelo visto vc não sabe diferenciar bugs em componentes, bibliotecas, frameworks com bugs na implementação da linguagem. JVM é o estado da arte perto do MRI.[/quote]
Amigo, você leu quando eu escrevi que a JVM é uma das melhores (se não a melhor) plataforma de desenvolvimento da atualidade?
JVM é uma plataforma excelente, madura e completa. Melhor que .NET, na minha opinião. JVM é totalmente diferente da MRI (inclusive no seu propósito).
Você é que não sabe diferenciar que estamos discutindo linguagem e produtividade e não plataformas.
