Ruby ou Groovy

Debugger Membro desde: 30/10/2004 18:53:48 Mensagens: 62 Offline

Fiz um post de manhã para saberum pouco da opnião de vocês sobre o Ruby e seu cresimento meteórico.
Achei melhor colocar esse novo post para falar sobre ruby e groove.

Podemos dizer que Groovy é a resposta do java a linguagens como o Ruby?

É obvio que o ruby já está "pegando" e eu não tenho mais duvida de que é um bom negócio apreder essa linguagem. Mas tentando antever o futuro o que podemos dizer do Groovy? Vale apane apreder mais essa linguagem?

existem aspectos semelhantes ao ruby passiveis de comparação ou "uma coisa é uma coisa e outra coisa é outra coisa".

Outra coisa isso não é um Flamewar!

é 'groovy'

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

Bom, se a Sun citou o JRuby (porte do Ruby para a JVM) no Sun Tech Days, e não citou o Groovy ...

Estuda Ruby!

Debugger Membro desde: 30/10/2004 18:53:48 Mensagens: 62 Offline

OK!
Vou estudar Ruby.
Na minha opnião o JRuby é uma forma de atrair os desenvolvedores Ruby para a plataforma java e evidar a evação dos desenvolvedores java para o Ruby.
Em contra partida a plataforma java agora oferece a sua propria nova linguagem dinâmica em resposta a "estagnação" da linguagem java. Foi a mesma estratégia que a Ms usou quando lançou a plataforma .NET. Há uma implementação da linguagem java para a .NET (o J#), mas em contra partida a .NET possui sua propria linguagem (o C#).
Apesar de muitas comparações que a própria midia faz, C# e java não são exatamente concorrentes. Acho que o mesmo irá acontecer com Ruby e Groove.
Alias. Por falar em MS. Parece que a plataforma .NET não possui nada semelhante a Ruby. Será que eles tb não entar na briga?

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Bom..

Não é preciso muito esforço pra aprender as 2 linguagens.. (puramente as linguagens)

Se você estivesse comparando Ruby on Rails com Grails ai eu te diria para escolher uma e começar por ela..

Groovy tem muita coisa interessante assim como Ruby..Hoje eu estaria mais inclinado a aprender Grails (rails com groovy) do que RoR porque iria aproveitar grande parte do meu conhecimento na plataforma Java,

Sobre JRuby, é Ruby rodando na JVM - ira facilitar a integração com Java - mas eu nao teria a vantagem de estar "migrando" conhecimento como no caso do Grails

Questão pessoal hehe..

Thread.start() Membro desde: 31/10/2006 12:04:24 Mensagens: 27 Offline

Eu diria: aprenda as duas. Nunca é demais aprender mais uma linguagem. Se você já é um programador, entender o básico de Ruby não deve levar mais que algumas horas.

Groovy é interessante e o framework Web Grails inspirou-se bastante no Rails. Mas sem dúvida nenhuma Rails é único no que faz e para isso ele precisa de Ruby. Comparações linha a linha não fazem justiça à utilização e desenvolvimento em si, você precisa experimentar para saber do que estamos falando.

JRuby lançou ante-ontem a versão 0.9.9, estamos muito, mas muito próximos da versão 1.0 estável, que deve permitir rodar aplicações Rails diretamente em um container Java como Glassfish ou Tomcat. Além disso a ponte que o JRuby fornece permite importar todas as bibliotecas Java existentes. O próprio suporte de banco de dados usa JDBC por baixo dos panos.

Nunca pense em escolher uma pela outra. Não existe uma linguagem perfeita. Cada uma é boa naquilo que faz. Ruby não é um "meio Perl", "meio Python", "meio Smalltalk". Ruby é Ruby. Pronto. É simples para começar, tem recursos avançados se você resolver se aprofundar, e tem um framework prazeroso de desenvolver. Mesmo que seja apenas por hobby, dê uma olhada.

Akita, falando um pouco mais de Rails, mais especificamente DDD, o que você acha do modelo de domínio do Rails ? Será que você não fica muito preso ao modelo relacional, com um modelo sistêmico que é um paradoxo da orientação a objetos ?

Thread.start() Membro desde: 31/10/2006 12:04:24 Mensagens: 27 Offline

Não entendi sua preocupação. No Rails, você tem o ActiveRecord, que é um ORM como outro qualquer. Não tem jeito, modelo relacional e OO sempre foi uma integração não trivial, principalmente em matérias de tabelas polimórficas. Alguns reclamam porque os models do Rails são classes que extendem de ActiveRecord::Base, mas não vejo problema nisso a menos que você seja purista e queira todas as suas classes como "POJO"s. Tanto faz. O mapeamento do Rails com banco é muito mais trivial e flexível do que um Hibernate. Até mesmo trabalhar com tabels polimorficas não é complexo no Rails.

AkitaOnRails wrote:O mapeamento do Rails com banco é muito mais trivial e flexível do que um Hibernate. Até mesmo trabalhar com tabels polimorficas não é complexo no Rails.

Opa, devagar aqui, pode ser mais simples trabalhar com ActiveRecord, mas a flexibilidade do Hibernate está a anos luz do ActiveRecord. Só ter uma API completa pra definição de buscas sem SQL (a 'criteria') já demonstra o quanto o Hibernate é uma solução bem mais flexível.

Tem muita coisa onde o Rails nao eh flexivel de proposito (por exemplo, ao praticamente te obrigar a ter um id integer autoincrement em todas tabelas do modelo), e a filosofia do framework eh interessante por si soh.

Mas po, nunca senti falta da Criteria (que eu uso o tempo todo no Hibernate). Parece que fica meio fora de lugar numa linguagem dinamica.

Thread.start() Membro desde: 31/10/2006 12:04:24 Mensagens: 27 Offline

Hehe, essa é uma questão polêmica, eu entendo a visão. Do ponto de vista de desenvolvedor, quando "criamos" alguma funcionalidade (como um ORM, ou um framework MVC), temos a "vontade" de atender todos: gregos e troianos. Daí a grande quantidade de configurações e parametrizações possíveis que a maioria dos frameworks acaba tendo.

Mas já ouviu aquele ditado: "mais vale um pássaro na mão do que dois voando". Qual foi a idéia de um HQL ou uma classe Criteria no Hibernate? No meu ponto de vista foi um objetivo nobre: digamos que você fez seu sistema com JDBC (e um DBCP ou C3P0 para pooling de conexão, não sejamos tão 1999 também

. Sua empresa usava MySQL. Um ano depois ela resolveu que não sabe usar MySQL e quer colocar Oracle no lugar. Ferrou-se! Temos que vasculhar todo o código e sair dando replaces, copy & pastes, e toda gama de gambiarras pra fazer as coisas funcionares. Ao passo que se fosse tudo feito com HQL, seria só o caso de retestar tudo e fazer alguns poucos tweaks no código.

É óbvio que o Gavin King tentou cobrir essa possibilidade e eu acho que foi uma boa idéia na época. Porém, na vida real, quantos projetos você já viu que realmente passou por esse cenário. Eu vi alguns, mas a maioria eram bancos de dados extremamente velhos, Ingres, Adabas, etc pulando para versões mais recentes de DB2, Oracle ou SQL Server. E os programas antigos foram jogados fora, muitos deles feitos sobre 4GL, Cobol, etc.

No fundo, é muito raro - não impossível - de se ver um sistema feito em Java recente, sofrendo uma mudança de infraestrutura, sem sofrer também uma revisão dos processos implementados.

Portanto, HQL é uma boa idéia, mas ela é uma complexidade extra que com que acabamos tendo que lidar em projetos que dificilmente serão plug-and-play de banco pra banco num futuro próximo. Claro, para desenvolvedores de produtos, a coisa pode ser diferente: eles precisam aceitar vários bancos justamente para ficar mais fácil de vender. Mas acredito que a proporção de projetos tailor-made é ordens de grandeza maior do que projetos de produtos com um life-cycle maior.

Ou seja, o ActiveRecord, por exemplo, não tem algo semelhante ao HQL. Ele usa SQL puro do banco. O bom e velho string. Isso é um problema? Se você for um desenvolvedor de produtos, pode até vir a ser caso não se planeje com mais cuidado. Mas não chega a ser um impeditivo. E para a grande maioria dos casos, dificilmente fará falta.

O uso de Surrogate Keys (primary keys numéricas auto-incrementáveis, nesse caso) é uma convenção, mais uma vez, porque na maioria dos casos é tudo que você precisa. Você quer Composite Keys? Não tem problema, existe plugin para isso, mas a maioria não precisa principalmente se for começar um projeto do zero, quando você pode planejar com antecedência para ser aderente às convenções.

Mais do que isso, o ActiveRecord tem convenções para nomenclatura das tabelas, das classes models, das colunas para foreign keys, etc. Seguindo as convenções, num novo projeto, não é esforço algum. Você gostaria de usar uma base de dados já existente sem mexer nela? Não tem problema, o ActiveRecord aceita isso.

E em uma época de Mesh ups, S3, serviços, também não vejo problema em, por exemplo, criar uma camada de aplicação de serviço (Web Service SOAP, REST) e criar uma aplicação Rails que, em vez de conversar diretamente com o banco, conversa via API com um serviço.

Existem inúmeras possibilidades se houver disposição para arquitetar uma solução que melhor se encaixe ao seu problema. "Arquitetar uma solução" é moldar sua solução ao problema em mãos, não o contrário. Os requerimentos são importantes. Se não existe perspectiva de uma requisição como "vamos migrar de fornecedor de banco daqui 2 anos", uma funcionalidade como HQL não cheira nem fede. E se for uma empresa que prima por time-to-market, um requerimento pode ser "precisamos ter esse produto no mercado em 2 meses, mas o investimento é limitado". Nesse caso, um Rails pode ajudar, por exemplo.

Akita,

A maior vantagem de qualquer bom framework ORM, incluindo Hibernate e JPA, nunca foi idnependência de SGBD e sim... ORM. Com Criteria e HQL eu consigo abstrair completamente o SQL e modelo relacional em favor de classes e objetos.

Dado que é um problema histórico de Ciência da Computação é justificável a complexidade de um framework/engine como Hibernate.

Claro que o suo de A ou B depende do que você quer/precisa em termos de persistncia e arquitetura.

Thread.start() Membro desde: 31/10/2006 12:04:24 Mensagens: 27 Offline

Hm, claro que fica em aberto isso, mas trocar

SELECT * FROM PESSOA WHERE NOME = 'JOSE'

por

SELECT obj FROM PESSOA as obj WHERE obj.NOME = 'JOSE'

não me parece exatamente 'abstrair' o SQL

Não estou dizendo que HQL não seja útil, mas só para constar.

A diferença é que em JDBC você faria a query, receberia um ResultSet com Objects e precisaria remapear campo a campo em uma instância de uma classe, que é o que o Hibernate vai automatizar. Mas não é muito mais do que isso. Claro que eu super-simplifiquei, mas na maioria dos casos é a mesma coisa.

Hibernate e ActiveRecord são dois paradigmas diferentes. O primeiro é um Data Mapper, o segundo - como o nome diz - é um Active Record. E funciona simples assim:

@pessoa = Pessoa.find_by_nome "JOSE"

ou ainda

def altera_cidade(nome, cidade)
@pessoa = Pessoa.find :first, :conditions => [ "nome = ?", nome ]
@pessoa.cidade = cidade
@pessoa.save
end

Essa classe Pessoa seria definida assim:

class Pessoa < ActiveRecord::Base
end

Eu poderia ter uma classe Cargo e Pessoa assim:

class Pessoa < ActiveRecord::Base
belongs_to :emprego
end

class Emprego < ActiveRecord::Base
has_many :pessoa
end

@emprego = Emprego.find_by_nome('Secretario')
@pessoa = @emprego.pessoas.create(:nome => 'Jose')
@pessoa.save

Novamente, fui super-simplório e nem arranhei a casca tanto de Hibernate quanto ActiveRecord nesses exemplos, mas só para dar uma idéia do que quero dizer e incentivar uma pesquisa mais profunda em ambos os assuntos.

Ou melhor:

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Esse active record me cheira a entity beans hehehe..

essa historia de herdar de base_record não me agrada mas a maneira de usar é bem interessante..

Notícias, artigos e o maior fórum brasileiro sobre Java