REST, CRUD e Domain Model

[Rafael Noronha]

Este final de semana assisti este keynote do DHH, de 2006.
Achei muito interessante, sempre bom conferir o que se passa na cabeça
do pessoal de RoR.

Fica a dica pra quem puder conferir, e talvez fazer uma discussão em
cima.

[]'s
Rafael Noronha
http://rafanoronha.net
http://twitter.com/rafanoronha

[Rafael Noronha]

Faltou o link =D

http://www.scribemedia.org/2006/07/09/dhh/

A enrolação termina no primeiro vídeo.

[]'s

[Rafael Rosa]

Essa palestra é realmente muito interessante, foi uma das primeiras que assisti e que me convenceu a ir para o Rails. Segue o link:

http://www.scribemedia.org/2006/07/09/dhh/

Atenciosamente,
Rafael Rosa
www.rafaelrosafu.com
www.rubyinside.com.br

[Rodrigo Vieira]

Opa, já tenho "televisão" pra ver hj a noite então...valeu pela dica.


2009/7/22 Rafael Rosa <rafael...@gmail.com>:

[Giovanni Bassi]

Só para esclarecer, já que essa é uma comunidade de .Net:
DHH significa David Heinemeier Hansson, e ele é o criador do Rails.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/7/22 Rafael Noronha <rafan...@gmail.com>

[Giovanni Bassi]

Assisti à palestra. O DHH realmente tem bons conceitos em mente. Ele advoga bons princípios que também tratamos no grupo o tempo todo, assim como todo bom grupo que preza por um bom desenho de uma aplicação. É uma palestra que vale a pena ver.

É sempre interessante ver como o ASP.Net MVC tem um paralelo fortíssimo com o Rails. O que fica pra mim, atualmente, quando vejo Rails, é que é um ótimo framework, mas, com a experiência que tenho, e sob meu ponto de vista do mundo de software, prefiro trabalhar com C# e MVC. Convenções e decisões tomadas por mim são boas, mas acho que talvez o Rails tome muitas, e eu gosto de ter o controle. Sei que ele permite trocar algumas coisas, mas, como o próprio DHH diz, se você sair do caminho especificado pelo Rails, vai doer. E eu não acho que deve doer.

Acho que a grande mensagem que o Rails me deixa é: mantenha seu código simples. É algo que tenho perseguido. Na minha carreira como arquiteto, houve momentos em que abandonei a busca da simplicidade pelo purismo. Hoje não faço mais isso, busco um compromisso entre os dois, não me permito não ser produtivo. Hoje, com C#, ASP.Net MVC, jQuery, um bom ORM e um bom container de DI, consigo programar para a web como se a infra estrutura não existisse, focando no negócio, que é algo que o DHH advogou em toda sua palestra.

De certa forma, ainda me incomoda um pouco trabalhar com uma linguagem dinâmica em um contexto de desenvolvimento web. Ela traz coisas muito interessantes, mas em momentos em que não preciso. Talvez não sejam a melhor ferramenta para o trabalho, quando o caso é desenvolvimento web, na minha opinião. Não vejo casos onde teria grandes benefícios sobre o C# por estar trabalhando com Ruby. Talvez os Rubyistas de plantão no grupo possam indicar um caso concreto (isso significa: com código) onde uma linguagem dinâmica é superior a uma estática nesse cenário. Eu realmente gostaria de ver tais exemplos concretos.
Ok, duck typing é bonito, mas eu faço o que eu preciso com interfaces. Poder mudar tipos em tempo de execução é legal, mas eu raramente precisei disso (e nesse caso recorri a uma linguagem dinâmica). Poder compilar sob demanda (scripts) é algo legal, mas isso é possível em linguagens estáticas também (e talvez venha ao C# na versão 5). Criar DSLs com Ruby é também muito bonito, e o Rails tem sua própria DSL para desenvolver para web, mas outros frameworks também tem, e posso criar DSLs com C#, apesar de ser bem mais difícil, mas não estamos falando disso, estamos falando do desenvolvimento web.
Porque preciso de uma linguagem dinâmica neste cenário (web)? Certa vez ouvi que o compilador nada mais é do que um teste a mais, e que as linguagens dinâmicas resolvem esse detalhe da checagem de tipos com testes, mas talvez eu não queira escrever testes para garantir que minhas classes tem o método XYZ, eu gostaria que fosse mais simples.

Em tempo, há outros cenários em que me parece que uma linguagem dinâmica é mais apropriada. Gostaria de entender o que vocês acham deste cenário específico.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/7/22 Giovanni Bassi <gig...@giggio.net>

[Rafael Noronha]

Giovanni,

O que me faz vez ou outra olhar atentamente para o Rails é justamente
a simplicidade.

A natureza opinativa provavelmente é o grande motivo por trás do
sucesso.
É pouco flexível? Sim, mas atende 99% dos cenários a que se propõe
atender.

Em relação ao dinamismo, me parece que existem algumas vantagens
bastante interessantes.
Quando me vejo tendo que apelar para DI, IoC, Moqs, AOP, paro pra
pensar se realmente estamos utilizando a ferramenta certa.
Com RoR praticamente não existe a necessidade de escrever código de
infra-estrutura, em um cenário comum.
Está tudo lá pronto, e se você precisar de UM POUCO de flexibilidade,
você não precisa apelar pra toda essa magia negra.

O que conta ponto para o .Net é a robustez da plataforma e da IDE, e o
apelo corporativo.
Para Rails conta ponto a expressividade do Ruby, o perfil da
comunidade, e mais foco no produto, menos na tecnologia.

Na verdade a minha idéia com a thread era discutir a visão do DHH de
REST e CRUD, mas se descambar pra .Net X RoR, tudo bem.

[Rafael Rosa]

Salve,

Uma vez que já desenvolvi dos dois lados, ainda que nem de longe tenha sua experiência com .NET, posso dar minha avaliação com conhecimento de causa.

Primeiro: contexto é tudo. Rails não é feito para resolver qualquer coisa, ele é montado para ser utilizado em aplicações web que utiliza dados persistidos em um banco de dados SQL. Esse cenário atende muito bem a 90% dos projetos web, onde usaríamos ASP.NET, por exemplo, mas ele não cobre todas as necessidades, é sempre bom ter isso em mente, e tenho certeza que você sabe disso.

As convenções do Rails são, em geral, boas e razoáveis, tive pouquíssimas crises, e existem para não termos que nos preocupar com a infra do sistema e sim com o negócio, como você disse muito bem. Realmente "sair dos trilhos" (trocadilho infame) dói, mas é intencional, e geralmente significa que você provavelmente está fazendo algo desnecessariamente complexo.

Minha crítica ao ASP.NET MVC é justamente precisarmos escolher todos os outros componentes para recheá-lo: ORM, javascript, IoC, etc. O Rails já te dá tudo isso pronto, dá para customizar praticamente tudo, mas se for mudar muito, qual a utilidade de um framework completo como o Rails? Se é necessário/desejado ter controle dos mínimos detalhes recomendo frameworks menores, como o Sinatra, aí você monta o resto, mas acredito que para a maioria dos casos isso seja um tiro de canhão, reinventar a roda, nos obrigar a tomar decisões que tomam tempo e exigem muito setup quando poderiamos já estar produzindo com um nível igual de qualidade. Vale lembrar: pilhas de pessoas deram pitacos no Rails, quantas olharam as estruturas que montamos a partir do zero?

Trabalhar com linguagens dinâmicas é, em muitos casos, uma questão de gosto, de troca. Dado o contexto de desenvolvimento web, eu troco velocidade por flexibilidade e expressividade, mas nem todos concordam com essa troca. Num contexto MVC velocidade só me é extremamente útil no M, onde tenho estruturas razoavelmente estáveis, no V e no C flexibilidade dá muito mais retorno. Em Rails eu não preciso de views tipadas, 300 interfaces, IoC, etc, etc, justamente por causa dos tipos dinâmicos. O preço é velocidade, mas muitos dos gargalos estão em outros lugares (conexão, I/O, etc), ou seja, a diferença de performance não é tão relevante. Se estivesse num cenário onde precisasse fazer milhares de cálculos por segundo, aí sim escolheria uma linguagem estaticamente tipada.

Respondendo item a item:
- Interfaces x Duck Typing: interfaces são um construto a mais para se preocupar, mais complexidade, sendo que na maioria das vezes acabamos criando interfaces que são utilizadas apenas por uma classe para facilitar os testes.
- Mudar tipos em execução, estou entendo como alterar a estrutura das classes em runtime, é muito útil quando queremos adaptar o código há informações que obtemos apenas em runtime, mas realmente não é essêncial na maioria dos casos, existem outras formas de se chegar a mesma solução. A questão é: quando podemos fazer isso sem nenhum custo, mudamos nossa abordagem para fazer algumas coisas, e isso se torna parte do estilo de programação. Realmente só entende quem já brincou com metaprogramação, é viciante :)
- Scripts são úteis, existem cenários em que são muito práticos e a simples razão de serem "normais" numa linguagem como Ruby faz com que possamos nos utilizar deles sem nenhum overhead, diferente de tentar fazer o mesmo em outras linguagens.
- Criar DSLs em Ruby é um sonho. Tive que escrever uma há alguns dias, e não consegui me imaginar fazendo o mesmo com C#, tendo que me preocupar com interfaces, tipos estáticos, typecasting, sem poder usar method missing, pesadelos com objetos proxies e coisas similiares. No Ruby DSLs são naturais, você pode usá-las sempre que isso for deixar seu código mais limpo e flexível, e não vai te custar caro, é mais uma ferramenta a mão. Ah, e o projeto no qual estou trabalhando é um projeto Rails, web, rodando sobre uma aplicação SAP, e o próprio Rails é considerado uma DSL. Toda vez que você tiver trabalho para escrever uma interface fluente, como o Fluent NHibernate, pense que em Ruby isso é um décimo do trabalho.

Finalmente os testes. Eu mesmo disse o que você citou, um compilador é apenas um teste para ver se as variáveis são do tipo certo. Ok, isso ajuda, seria ótimo ter essa verificação se ela fosse de graça, mas os problemas realmente graves, aqueles que não dependem de recebermos e mandarmos os tipos corretos para lá e para cá, os erros de lógica e implementação errada, não são pegos pelo compilador. Quando fazemos alterações como sabemos se o código quebrou? Ou seja: precisamos testar de qualquer maneira.

Bons rubistas não escrevem testes para ver se os tipos estão certos, e sim para ver se o programa está funcionando como esperado. Nesse cenário, enviar tipos corretos é consequência de código limpo e funcionando direito, pois só assim ele vai funcionar de acordo com os testes. Se os testes garantem que o programa funciona, qual a utilidade de type checking, sendo que eu preciso adicionar um monte de complexidade para facilitar coisas essências, como testes, e ainda acaba aumentando a quantidade de código para dar manutenção? Sinceramente não vejo o menor motivo.

No fim das contas, as diferenças intrínsecas entre os paradigmas de programação e a cultura em torno da linguagem mudam o modo com programamos. Programar em Ruby com o mesmo mindset de C# é perda de tempo, código de péssima qualidade e nenhuma vantagem real. É preciso entender as diferenças, aprender os conceitos, dominar as técnicas diferentes para se ter toda a produtividade/qualidade/flexibilidade que a ferramenta oferece. É como programar em C# com e sem lambdas, com e sem genéricos: são estilos totalmente diferentes.

Além dessa análise, programar em Ruby é uma questão de ajuste à filosofia da linguagem: o Ruby foi feito para seres humanos e não máquinas. Particularmente, só isso já vale, é suficiente, mas essa é uma escolha extremamente subjetiva, uma questão filosófica e não técnica.

Com o advento do IronRuby, que deve estar chegando à versão 0.9 por esses dias, podemos realmente escolher a melhor ferramenta para cada caso, ou a ferramenta que mais combina com a filosofia de cada um. O Ruby e o Rails passam a ser tão .NET quanto o resto, a única diferença é que não foram feitos na nave mãe :)

[Giovanni Bassi]

Oi Rafael,

Legal seu feedback. Vou tentar colocar minhas dúvidas e questões com relação ao que você falou.

Entendo que você tem total razão, e eu concordo plenamente, que se formos adotar uma linguagem dinâmica, tem que ser de corpo e alma. Programar Ruby como C# seria uma grande perda de tempo. E o mesmo fale para qualquer outra linguagem: temos que abraçar o que ela tem de melhor. Você pode, por exemplo, programar F# com se fosse C#, com mutabilidade e foreachs em tudo quanto é canto, mas isso não faria sentido.

Entendeo esse negócio de ter que escolher conteiner de DI, ORM, etc, etc ser uma dor. Para mim isso é algo absolutamente natural, e leva pouco tempo para montar, já sai naturalmente quando estou programando, eu sequer me preocupo. Coloco quando preciso. Não dói, entende? Então o foco é o negócio. Quando esses detalhes estão prontos, você já pode sair codificando. Se formos falar de mais opinião, talvez poderíamos usar o S#arp, que já tras bem mais coisa.
Entendo o benefício de todo mundo estar olhando, é real. Ao mesmo tempo, cada aplicação é diferente, conseguimos encaixá-las todas no mesmo conceito? Toda aplicação que eu faço, em cada cliente, sempre tem pontos muito diferentes. Por exemplo, o DHH fala de usar CRUD pra tudo. Na boa, não é tudo que é CRUD... e eu não quero que seja difícil não ser CRUD. Não deve doer. Legal, REST é bonito, mas e daí? Preciso me prender ao padrão em todas as minhas apps?
Ao mesmo todo, entendo que a grande maioria das empresas não tem a menor idéia de como aplicar IoC, usar um ORM, etc. E quando sabe o que é, muitas vezes faz errado, então nesse sentido, o Rails ajuda a guiar quem está começando.

A questão de performance X expressividade e flexibilidade é diferente pra mim. Com a devida arquitetura, você tem código muito expressivo com C#. Lambdas ajudam muito nisso, mas não só elas. Há diversas técnicas. Demora para saber escrever uma app fácil de ler, expressiva. Mas alcançar senioridade em qualquer coisa demanda esforço.
Flexibilidade também. Ferramentas como Resharper me permitem codificar muito em pouquíssimo tempo e com grande flexibilidade. Minha produtividade é muito alta, e não custa quase nada. Não faço 300 interfaces, só faço interfaces se preciso substituir o objeto em algum lugar (muitas vezes por causa de testes). E essas interfaces, com frequência, vêm trabalhadas com generics, o que me permite fazer 1 interface genérica, e outras que só crescem sobre ela, mais específicas. E para fazer os testes unitários posso usar Ruby, que é um dos contextos onde ele brilha. Daí nem preciso de interfaces. E então tenho a performance de uma linguagem estática em todo lugar.

O que você disse de bons rubistas escreverem testes para testar o negócio, não o tipo, é válido. A questão é: quando você refatora o teste quebra. E cada vez quebra em um lugar diferente. Imagino que você leva muito mais tempo para arrumar as coisas quando quebra uma entidade em várias, por exemplo, ou muda o nome ou parâmetros de vários métodos. Com C#, você fica sabendo na hora, porque tem o compilador em background, verificando cada toque no teclado. Não preciso rodar os testes pra isso. Meus testes servem para verificar erros de lógica, de negócio. Entendo que essa é uma preocupação a mais em linguagens dinâmicas.

Linguagens de programação ficam no meio do caminho entre o homem e a máquina. Não sei se quero que a máquina decida tanto assim por mim em todo lugar. Mas também não posso falar tanto, preciso me aprofundar em Ruby, e farei isso em breve. Daí aviso vocês do que achei. De qualquer forma entendo que quanto mais as linguagens olham para a máquina com mais abstração, mais elas possibilitam. Foi o que o C fez com o Assembler, o que o C++ fez com o C, e o que o C# fez com o C++. As questões são: quando é demais? Quando é apropriado?

Quanto ao IronRuby, sim, vai sair esses dias a versão que vai compilar quase tudo e passar quase todos os testes da RubySpec (v0.9). O anúncio na OSCON seria feito hoje. Mas ele é sim feito pela nave mãe. Quem paga os desenvolvedores chave, responsáveis pelo projeto, é a Microsoft. No entanto, a Microsoft aceita contribuições no projeto, desde que você assine um termo liberando o copyright, ou seja, é mesmo OSS.

E queria um exemplo concreto. Código...

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/7/23 Rafael Rosa <rafael...@gmail.com>

[Rafael Rosa]

Salve camarada,

Entendo que você tem total razão, e eu concordo plenamente, que se formos adotar uma linguagem dinâmica, tem que ser de corpo e alma. Programar Ruby como C# seria uma grande perda de tempo. E o mesmo fale para qualquer outra linguagem: temos que abraçar o que ela tem de melhor. Você pode, por exemplo, programar F# com se fosse C#, com mutabilidade e foreachs em tudo quanto é canto, mas isso não faria sentido.

Concordamos.
 

Entendeo esse negócio de ter que escolher conteiner de DI, ORM, etc, etc ser uma dor. Para mim isso é algo absolutamente natural, e leva pouco tempo para montar, já sai naturalmente quando estou programando, eu sequer me preocupo. Coloco quando preciso. Não dói, entende? Então o foco é o negócio. Quando esses detalhes estão prontos, você já pode sair codificando. Se formos falar de mais opinião, talvez poderíamos usar o S#arp, que já tras bem mais coisa.

Em ASP.NET MVC (por exemplo) "Leva pouco tempo para montar", em Rails eu não levo tempo algum :) O maior problema é que o mesmo juntando tudo, ORM, o DI, etc, não são totalmente integrados, são genéricos, podem ser usados em qualquer lugar, então você tem que ajustar o framework a eles. Com a experiência que você tem, resolve isso em 3 minutos, mas ainda sim exige que você codifique boilerplate, código customizado, que você escreveu na mão e ninguém mais conhece. Com Rails as coisas já estão prontas, tudo que você precisa está sempre nos mesmos lugares, todo mundo que conhece o framework sabe e pronto, não depende de ajustes. Também há uma diferença de origem: o Rails foi extraído de um projeto real, os frameworks da MS sairam de laboratórios. Será que isso não afeta o quão pragmática é a abordagem de cada um?
 

Entendo o benefício de todo mundo estar olhando, é real. Ao mesmo tempo, cada aplicação é diferente, conseguimos encaixá-las todas no mesmo conceito? Toda aplicação que eu faço, em cada cliente, sempre tem pontos muito diferentes. Por exemplo, o DHH fala de usar CRUD pra tudo. Na boa, não é tudo que é CRUD... e eu não quero que seja difícil não ser CRUD. Não deve doer. Legal, REST é bonito, mas e daí? Preciso me prender ao padrão em todas as minhas apps?

CRUD é o feijão com arroz, você sempre vai ter, mas eu mesmo quase não escrevo muitos CRUDS, e quando preciso o Rails resolve isso em 5 minutos. REST não é só bonito, é lógico, facilita o entendimento de como o sistema está organizado, e vai além dos CRUDS, e o Rails facilita muito definir rotas. Por exemplo:

map.resources :clients

Pronto, em uma linha eu defini todas as rotas REST para CRUD (inclusão, inserção, edição) da entidade, com URLs como localhost:3000/client/new. Se quiser adicionar rotas para entidades filhas, para ter uma url como localhost:3000/client/1/orders ou localhost:3000/client/1/addresses, basta:

map.resources :clients, :has_many => [:orders, :addresses]
ou
map.resources :client do |client|
  client.resources :orders
  client.resources :addresses
end

O CRUD sai naturalmente, sem esforço. Se quiser uma rota REST para uma action específica, como localhost:3000/client/1/block_credit que só funciona com o verbo GET, eu posso fazer assim:

map.resources :clients, :member => {:block_credit => :get}

Código simples, sucinto, que irá gerar URLs limpas e humanamente inteligíveis, que é a idéia do REST e por isso ele "deve" ser usado. O Rails só torna isso estupidamente simples. Obviamente roteamento é um assunto meio chato, tem dezenas de variações, mas o tipo de código acima resolve 90% das necessidades dos projetos.

Se um sistema não se encaixa no sweetspot do Rails (aplicação web com banco de dados) então é melhor não utilizá-lo, assim como não é uma boa idéia tentar usar MVC em aplicações desktop. A questão é Pareto: 80% dos casos usam a mesma estrutura, e o Rails é focado nesses casos. Para os outros 20% você pode usar Sinatra, Merb, Camping, etc, ou fazer o seu.

Ao mesmo todo, entendo que a grande maioria das empresas não tem a menor idéia de como aplicar IoC, usar um ORM, etc. E quando sabe o que é, muitas vezes faz errado, então nesse sentido, o Rails ajuda a guiar quem está começando.

Certamente o Rails ajuda quem está começando, mas a maioria das pessoas, mesmo para sistemas grandes, não sai do básico, caso contrário não teríamos centenas de sistemas de grande porte usando DataSets. Por isso, tudo que é comum, útil e uma boa prática na maioria dos casos, o Rails já traz como padrão ORM, diretório de config, sistema de plugins, etc. Pra que perder tempo pensando no óbvio? Precisamos de uma tela em branco toda vez que começamos um projeto? É por isso que gosto de coisas como o SharpArchitecture, mesmo achando ele meio grande demais.

A questão de performance X expressividade e flexibilidade é diferente pra mim. Com a devida arquitetura, você tem código muito expressivo com C#. Lambdas ajudam muito nisso, mas não só elas. Há diversas técnicas. Demora para saber escrever uma app fácil de ler, expressiva. Mas alcançar senioridade em qualquer coisa demanda esforço.

Concordo, mas você está assumindo que há uma boa arquitetura, que já vem montada no Rails, e é difícil achar coisas mais óbvias que:

start_time = 10.minutes.ago

ou

class Client
  has_many :addresses
end

São exemplos óbvios, mas não demandam muito cérebro para entender. Ser óbvio não quer dizer ser simplório e sim claro e natural. As versões mais novas do C# tem muitas coisas para ajudar nisso, mas usar extensions, por exemplo, ainda é considerado algo novo, complexo ou avançado por muitos. Expressividade e simplicidade são as regras do Ruby e do Rails, mesmo no básico.

Flexibilidade também. Ferramentas como Resharper me permitem codificar muito em pouquíssimo tempo e com grande flexibilidade. Minha produtividade é muito alta, e não custa quase nada. Não faço 300 interfaces, só faço interfaces se preciso substituir o objeto em algum lugar (muitas vezes por causa de testes). E essas interfaces, com frequência, vêm trabalhadas com generics, o que me permite fazer 1 interface genérica, e outras que só crescem sobre ela, mais específicas. E para fazer os testes unitários posso usar Ruby, que é um dos contextos onde ele brilha. Daí nem preciso de interfaces. E então tenho a performance de uma linguagem estática em todo lugar.

Ruby é fantástico para testes, tem razão. O problema das interfaces é que é mais código para manutenção, e que em geral tem quase nenhuma função além cumprir as regras da linguagem, que não contribuem para o negócio. Outro ponto: se analisarmos a produtividade de profissionais de ponta, como você, sempre teremos números similares. E o resto da população? A produtividade deveria ser alta mesmo para quem está começando, e mais os avançados sempre terão mais produtividade, em qualquer cenário.

O que você disse de bons rubistas escreverem testes para testar o negócio, não o tipo, é válido. A questão é: quando você refatora o teste quebra. E cada vez quebra em um lugar diferente. Imagino que você leva muito mais tempo para arrumar as coisas quando quebra uma entidade em várias, por exemplo, ou muda o nome ou parâmetros de vários métodos. Com C#, você fica sabendo na hora, porque tem o compilador em background, verificando cada toque no teclado. Não preciso rodar os testes pra isso. Meus testes servem para verificar erros de lógica, de negócio. Entendo que essa é uma preocupação a mais em linguagens dinâmicas.

Bons rubistas usam testes automatizados que rodam a cada vez que você salva um arquivo de código e te dizem imediatamente onde o erro aconteceu. Até onde me consta, quando você refatora código os testes não mudam automaticamente, você precisa ir e alterá-los manualmente, ou o Resharper já é inteligente o suficiente para ver os refactoring do código e fazer as mudanças equivalentes nos testes? Da última vez que usei ele só apontava os lugares que eu teria que mexer, o mesmo que acontece quando um teste quebra em Ruby.

As IDEs para Ruby tem avançado bastante, especialmente na procura de classes, méotodos e coisas do tipo, então achar trechos de código e lugares onde uma classe é utilizada, por exemplo, está se tornando cada vez mais simples. IDEs para .NET e Java são mais completas, maduras, e facilitam muito a refatoração, não há o que discutir, mas os testes continuam sendo necessários do mesmo jeito.

Linguagens de programação ficam no meio do caminho entre o homem e a máquina. Não sei se quero que a máquina decida tanto assim por mim em todo lugar. Mas também não posso falar tanto, preciso me aprofundar em Ruby, e farei isso em breve. Daí aviso vocês do que achei. De qualquer forma entendo que quanto mais as linguagens olham para a máquina com mais abstração, mais elas possibilitam. Foi o que o C fez com o Assembler, o que o C++ fez com o C, e o que o C# fez com o C++. As questões são: quando é demais? Quando é apropriado?

O C# e o Ruby são equivalentes no quesito "poder fazer qualquer programa", ambas podem fazer as mesmas coisas, a questão é qual fica mais próxima da linguagem e raciocínio humanos, e por consequência, facilita o entendimento, o aprendizado e a manutenção. O Ruby tem um alto nível de abstração, e ele ainda nos dá poder para mudar tudo, classes, métodos, etc, ou seja, os limites do que podemos fazer ou não são reduzidos, vai do usuário querer descer à esses níveis ou não. Entre uma linguagem que me "protege da complexidade" me proibindo de fazer as coisas e outra que me deixa fazer o que eu quiser por conta e risco, fico com a segunda. 

 

Quanto ao IronRuby, sim, vai sair esses dias a versão que vai compilar quase tudo e passar quase todos os testes da RubySpec (v0.9). O anúncio na OSCON seria feito hoje. Mas ele é sim feito pela nave mãe. Quem paga os desenvolvedores chave, responsáveis pelo projeto, é a Microsoft. No entanto, a Microsoft aceita contribuições no projeto, desde que você assine um termo liberando o copyright, ou seja, é mesmo OSS.

Quando disse que ele não é da nave-mãe me referia ao Rails e todas as bibliotecas a volta do Ruby. Podemos acessar tudo que o .NET oferece, e muito mais, porém, esse "muito mais" é feito pela comunidade, sem as regras, limitações ou recursos da MS.

Ainda acho que a escolha final é filosófica: OSS ou proprietário, comunidade ou enterprise, dinâmico ou estático, liberdade total ou restrições. Acredito que profissionais altamente capacitados e experientes em qualquer linguagem são basicamente similares, podem fazer sistemas com funcionalidades, performance e produtividade muito próximas, apesar do caminho ser diferente. O problema é que a média do mercado não é essa, nem de longe.

Hoje, dada minha experiência, não pretendo voltar a trabalhar com linguagens estáticas, estou muito muito feliz com Ruby, e esse sentimento de felicidade, por mais estranho que pareça, é comum na nossa comunidade e tido por muitos (eu incluso) como fator decisivo escolher a linguagem, porém, felicidade é algo subjetivo. Espero que todos se sintam felizes quando programam em C#, eu não me sentia.

Se tiver algum algoritmo específico que você gostaria de ver em código Ruby é só falar. Não tenho muita imaginação para exemplos de código, necessidades reais são mais simples de suprir.

[Juan Bernabó]

Olá pessoal,

Primeira mensagem minha no grupo.

Sou um cara que historicamente fui strong typed tendo trabalhado
décadas com c++, depois Java e c# e recentemente comecei a mexer com
ruby e rails.

Uma coisa interesante que caiu minha ficha é que c++, Java e c# não
são linguagens orientadas a objetos e sim a classes.

Num projeto que estaba trabalhando precisei usar uma quantide
gigantesca de patterns e aspect programming que depois estudando ruby
simplesmente é desnecesario já que posso modificar não uma classe mais
um objeto e posso interceptar mensagens (métodos) usando a própria
linguagem, nada raro como geração de código e coisas assim.

Quando entendi isso vi que a maioria de design patterns são para
conseguir resolver um problema criado pela orientação a classes das
linguagens e a ser ripados fortemente.

Meus 2 cents...

Abs.
Juan

On Jul 23, 2:53 am, Rafael Rosa <rafaelros...@gmail.com> wrote:
> Salve camarada,
>
> > Entendo que você tem total razão, e eu concordo plenamente, que se formos
> > adotar uma linguagem dinâmica, tem que ser de corpo e alma. Programar Ruby
> > como C# seria uma grande perda de tempo. E o mesmo fale para qualquer outra
> > linguagem: temos que abraçar o que ela tem de melhor. Você pode, por
> > exemplo, programar F# com se fosse C#, com mutabilidade e foreachs em tudo
> > quanto é canto, mas isso não faria sentido.
>
> Concordamos.
>
> > Entendeo esse negócio de ter que escolher conteiner de DI, ORM, etc, etc
> > ser uma dor. Para mim isso é algo absolutamente natural, e leva pouco tempo
> > para montar, já sai naturalmente quando estou programando, eu sequer me
> > preocupo. Coloco quando preciso. Não dói, entende? Então o foco é o negócio.
> > Quando esses detalhes estão prontos, você já pode sair codificando. Se

> > formos falar de mais opinião, talvez poderíamos usar o S#arp<http://code.google.com/p/sharp-architecture/>,

> ...
>
> read more »

[Phillip Calçado]

Oi, Juan,

2009/7/23 Juan Bernabó <juan.b...@gmail.com>:

> Sou um cara que historicamente fui strong typed tendo trabalhado

> ruby e rails.

Não sei se eu entendi corretamente a sentença mas, de qualquer forma,
é bom lembrar que Ruby possui tipagem forte. Tipagem forte/fraca não
possui relação com tipagem dinamica/estática.

> Uma coisa interesante que caiu minha ficha é que c++, Java e c# não
> são linguagens orientadas a objetos e sim a classes.
>
> Num projeto que estaba trabalhando precisei usar uma quantide
> gigantesca de patterns e aspect programming que depois estudando ruby
> simplesmente é desnecesario já que posso modificar não uma classe mais
> um objeto e posso interceptar mensagens (métodos) usando a própria
> linguagem, nada raro como geração de código e coisas assim.

Isso não é exatamente verdade. Quando você adiciona um método "a um
objeto" ao invés de "a uma classe" em Ruby você está adicionando (ou
removendo, ou alterando...) métodos à eigenclass -que é um termo bem
obscuro para se referir à uma classe que é criada exclusivamente para
aquele objeto. Em termos de linguagens todas as citadas se comportam
de maneira parecida com relação à classes e objetos, a diferença em
Ruby é que:

1 - Classes podem ser modificadas em runtime
2 - Cada instância possui sua propria e exclusiva classe, derivada da
classe original

> Quando entendi isso vi que a maioria de design patterns são para
> conseguir resolver um problema criado pela orientação a classes das
> linguagens e a ser ripados fortemente.

Sim e não. Os Design Patterns da GoF, por exemplo, surgiram na
comunidade Smalltalk, que é uma linguagem Orientada a Objetos tipada
dinamicamente e com Open Classes, exatamente como Ruby. Toda linguagem
utiliza algums padrões e faz outros desnecessários. E isto não tem
nada a ver com tipagem.

Eu creio que praticamente nenhuma das vantagens atribuídas a C# ou
Ruby nesta ou em qualquer outra discussão que tenha lido tem a ver com
tipagem. Estão apenas comparando funcionalidades das linguagens.
Tipagem dinamica ou estatica apenas diz quando seu programa vai fazer
verificação de tipos, se na compilação ou em runtime. Por si só nem
uma nem outra forma possui muitas vantagens, tudo vai depender das
funcionalidades da sua linguagem e, principalmente, do que é um tipo
nela.

[]s

--
Phillip Calçado
http://fragmental.tw
http://www.fragmental.com.br

[Rafael Noronha]

Acabei de escrever um tweet sobre meu descontentamento com c#.

Difícil dizer com certeza, mas acredito que minha primeira opção na
web passa a ser Rails.
Chega de ser escravo do compilador. =D

[Giovanni Bassi]

Oi Philip,

Acho que você está se pegando nos detalhes e deixou a discussão anterior passar batida. "Strong Typing" é um termo amplo. Amplo demais, talvez. Alguns entendem o termo exatamente como o Juan o colocou, ou seja, como static typing, referente ao momento em que a checagem do tipo é feita, compilação (static) ou execução (dynamic). Outros entendem como você o colocou, o que, diante das muitas conotações para o termo, não ficou exatamente claro (type safety, fixed-typing, etc).

Quanto à comparação de C# e Ruby não ter a ver com tipagem, é algo que discordo. O Rafael colocou a ideía de recursos de metaprogramação, que não são possíveis em C#, mas são em Ruby, devido ao dynamic typing. A criação de DSLs segue na mesma linha. Da mesma forma, os recursos de static typing permitem a existência dos erros do compilador do C#, mas isso não é possível no Ruby.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/7/23 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi, Giovanni,

2009/7/24 Giovanni Bassi <gig...@giggio.net>:

> Acho que você está se pegando nos detalhes e deixou a discussão anterior
> passar batida. "Strong Typing" é um termo amplo. Amplo demais, talvez.
> Alguns entendem o termo exatamente como o Juan o colocou, ou seja, como
> static typing, referente ao momento em que a checagem do tipo é feita,
> compilação (static) ou execução (dynamic). Outros entendem como você o
> colocou, o que, diante das muitas conotações para o termo, não ficou
> exatamente claro (type safety, fixed-typing, etc).

Eu nao acho que me apeguei ao detahe, me apeguei a definicao formal
dos conceitos. Uma das coisas que Patterns e Domain-Driven Design nos
ensinam eh que eh muito importante ter uma linguagem comum bem
esclarecida. Tipagem e um tema comum em ciencia da computacao ha
muitas decadas, existem algumas partes mais confusas mas os termos
citados sao bem definidos, nao ha porque cada um criar sua propria
interpretacao.

E, pior ainda, existe uma vasta gama de material retratando como
tipagem fraca e um problema. Eu ja vivi muitos momentos onde alguem
associa estes problemas a Ruby ou Python porque acredita erradamente
que estes possuem tipagem fraca. E bom deixar as coisas claras porque
elas significam coisas completamente diferentes.

Como efeito de comparacao seria como se alguem rejeitasse C# porque
ouviu dizer que e procedural e nao orientada a objetos porque o que eu
chamo de OO nao eh o que voce chama de OO.

> Quanto à comparação de C# e Ruby não ter a ver com tipagem, é algo que
> discordo. O Rafael colocou a ideía de recursos de metaprogramação, que não
> são possíveis em C#, mas são em Ruby, devido ao dynamic typing. A criação de
> DSLs segue na mesma linha. Da mesma forma, os recursos de static typing
> permitem a existência dos erros do compilador do C#, mas isso não é possível
> no Ruby.

Nao sao possiveis em C# porque C# nao possui as capacidades que os
tornam possiveis, e isso nao tem nada a ver com tipagem. Se voce olhar
como Scala e Haskell, duas linguagem estaticamente tipadas e muito
mais rigorosas que C# quanto a isso, implementam DSLs e
metaprogramacao voce vai entender o que eu estou dizendo.

Nao eh porque voce faz verificacao de tipos durante a compilacao que
voce nao tem metaprogramacao ou DSLs. Voce tem um gostinho disso em C#
com LINQ e extension methods.

Este e um problema de entendimento bem comum. Minha recomendacao e a
leitura do material de Luca Cardelli que eh o papa do assunto e
escreve de maneira bem acessivel. Em algumas semans eu vou fazer uma
apresentacao sobre exatamente este tema e assim que os slides
estiverem online eu dou um UP aqui.

[Giovanni Bassi]

Oi Philip,

A questão não é essa. A questão é que a discussão do tópico é outra, e por isso você pegou um detalhe da discussão e mudou o assunto dela. Independentemente se isso está nos livros ou não, ela é um detalhe no contexto desta discussão.
Mas concordo que temos que dar os nomes corretos às coisas. Eu mesmo já disse isso no grupo. Só que strong typing é algo que possui significados diferentes dependendo com quem você fala. Livros são só mais uma fonte.
Eu não disse que DSLs não são possíveis em C# (eu mesmo já fiz as minhas). Só são mais difíceis. Gostaria de ver como Scala implementa metaprogramação, você teria um exemplo concreto (com código)?
Sou da opinião de que se algo é difícil demais, na prática não existe, senão por uns poucos malucos que se aventuram. DSLs com linguagens de tipagem estática é algo mais complexo de ser feito do que com tipagem dinâmica. Metaprogramação parece ser outro caso onde as linguagens dinâmicas se saem melhor. Você não acha que esse padrão existe? Voltando à questão colocada pelo Rafael e pelo Juan, será que essa não é a raíz da questão?

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/7/24 Phillip Calçado <pcal...@gmail.com>

[Phillip Calçado]

Oi,

2009/7/24 Giovanni Bassi <gig...@giggio.net>:

> A questão não é essa. A questão é que a discussão do tópico é outra, e por
> isso você pegou um detalhe da discussão e mudou o assunto dela.
> Independentemente se isso está nos livros ou não, ela é um detalhe no
> contexto desta discussão.

Discordo completamente. Mais de tres vezes nesta thread foi citado que
A ou B que Ruby faz e C# nao (ou o contrario) e por causa do sistema
de tipos. Fora que o email do Juan, que foi o unico que respondi pelo
que sei, eh quase que exclusivamente sobre este tema (e sobre classes
x objetos, que tambem respondi).

> Mas concordo que temos que dar os nomes corretos às coisas. Eu mesmo já
> disse isso no grupo. Só que strong typing é algo que possui significados
> diferentes dependendo com quem você fala. Livros são só mais uma fonte.

Se livros, com provas matematicas, sao "apenas mais uma fonte" para
voce tudo bem, para mim eles sao trabalho cientifico e eu gosto de
basear meu trabalho em ciencia e nao em apenas opinioes.

> Eu não disse que DSLs não são possíveis em C# (eu mesmo já fiz as minhas).
> Só são mais difíceis. Gostaria de ver como Scala implementa metaprogramação,
> você teria um exemplo concreto (com código)?

Uma busca no Google traz muitos resultados:
http://www.google.com/search?q=scala+metaprogramming

> Sou da opinião de que se algo é difícil demais, na prática não existe, senão
> por uns poucos malucos que se aventuram. DSLs com linguagens de tipagem
> estática é algo mais complexo de ser feito do que com tipagem dinâmica.
> Metaprogramação parece ser outro caso onde as linguagens dinâmicas se saem
> melhor. Você não acha que esse padrão existe? Voltando à questão colocada
> pelo Rafael e pelo Juan, será que essa não é a raíz da questão?

O que falei no meu email anterior e vou repetir aqui eh que isto nao
esta ligado a tipagem e sim as funcionalidades da linguagem. O fato de
que C#, Java, C++ e etc. se baseiam em C enquanto Ruby j'a foi
conhecida como "Matz's little Lisp" diz muito sobre o quao isto esta
relacionado com a heranca da linguagem e nao exatamente com tipagem.

[Bruno Fiorentino]

Rafael,

Se um sistema não se encaixa no sweetspot do Rails (aplicação web com banco de dados) então é melhor não utilizá-lo, assim como não é uma boa idéia tentar usar MVC em aplicações desktop. A questão é Pareto: 80% dos casos usam a mesma estrutura, e o Rails é focado nesses casos. Para os outros 20% você pode usar Sinatra, Merb, Camping, etc, ou fazer o seu.

Saindo um pouco do foco da discussão, me interessei sobre MVC em desktop não ser uma boa ideia. Eu não tenho experiência significativa com Windows Forms/WPF e até hoje não participei de nenhum projeto desktop, mas gostaria de saber mais a respeito. Voce (ou alguém) poderia apontar alguns links sobre o assunto?

[]s,
Bruno Fiorentino

2009/7/23 Rafael Rosa <rafael...@gmail.com>