Desenvolvedores Scala, Ruby, a jugular está preparada

Assuntos Gerais
#141

[quote=sergiotaborda]
Não me referia à JS. Me referi à arquitetura ela mesma. Po exemplo, eu não uso DWR. Pelo simples motivo que eu não uso EJB remoto. Não uso remote method invocation ( e pronto). Ok, tem outras coisas no DWR … no dia que justificar usar o DWR eu usaria, mas não à priori. O mesmo para Spring , VRaptor etc…

Alguem falou que os “inexperientes” acham que o bom é programar tudo do zero. Isso não é uma questão de inexperiencia ( aliás os inexperientes que eu conheço adoram usar frameworks ) é uma questão de arquitetura. Existem trade-offs que têm que ser equacionados.
O bom de fazer à mão, é que vc ganha muito mais experiencia com a linguagem e plataforma e se fizer direito - seguindo OO e boas práticas - vc tem uma biblioteca/API/framework próprio e não precisa mais dos outros. Não estou dizendo que tem que reinventar a roda ( embora eu não veja mal nisso) estou dizendo que a roda da carroça não serve para todos veiculos. [/quote]

Nesse ponto discordo de você. Se for para melhorar a roda, blz. Mas pelo simples fato de reinventar, acho desnecessário e perigoso. O DWR encapsula muito da complexidade de usar Ajax com Java. Pensa em reinventar o Spring, maravilha. Interessante idéia se for no sentido de evolução.

Muitos poderiam dizer que o VRaptor estaria reinventando a roda, mas acredito que caminha no sentido da evolução. E com isso, só a plataforma tem a ganhar.

Não sou “framework-based”. Normalmente, nos meus projetos, uso apenas o Hibernate e o DWR. Spring muito raramente. Como eu disse estou muito focado no design OO, vou começar a estudar o livro do Meyer. Mas não por isso deixo de acreditar no lugar e do poder dos frameworks.

#142

[quote=sergiotaborda]Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
[/quote]

Alguém que está usando Rails não está usando Ruby? Não está usando as funcionalidades da linguagem e sim as do framework? COMO É QUE É? De onde você tirou isso?

[quote]
Mas suponhamos que vc está mesmo usand ruby/js/ etc… “puro”. Qual é o método/função em JS para acessar arquivos ? Você consegue utilizar dentro do Browser ? Porquê não consegue ? Porque JS corre sempre dentro de outro algo pq é uma linguagem de script. Ou seja, a maioria das funcionalidades que vc usa em ruby ou js-ss não são da linguagem, são de algum sistema ou framework. Em ruby, por exemplo, tem coisa que é realmente feita em C e o ruby apenas mascara a chamada ( hummm… JNI ?) [/quote]

Você consegue abrir arquivos com JS sim. É claro que você não vai tentar fazer isso de dentro de um browser, você vai usar Rhino que roda em cima da JVM. Quer dizer então que Java uma “linguagem de script”, porque “roda em cima de outro algo” (JVM)?

[quote]
Realmente linguagem de script é para produzir programas. Agora, para produzir aplicações e sistemas é preciso algum mais. Isso é fato.[/quote]

Qual a diferença entre programas, aplicações e sistemas? Até antes desse seu post eu achava que eram sinônimos.

Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real.

#143

[quote=sergiotaborda]Bom, várias coisas:

Java no chip : procure Sun SPOT. Isso é um exemplo concreto de um chip java. Não ha necessidade real / tecnica para utilizar C a JVM pode correr directamente no chip. Lembre-se que bytecode é um tipo de linguagem de máquina como o assembler. Ok, o SPTO corre JavaME, mas é Java non the less.
[/quote]

Eu olhei, e achei muito interessante. Mas não é um microcontrolador, é um sistema embarcado pra sensores e telecomunicações.
Digo um microcontrolador como um pic16, que eu pudesse desenvolver a placa e programar o firmware em java. Isso seria uma revolução.

O sun spot tem a squawk implementado no processador dela, um ARM.

É mesmo muito interessante.

#144

Olá

Pois é… a discussão estava gostosa. Um bate papo sem compromisso. Porém… tinha que acontecer…

Pena… arroubos e arrotos de arrogância… só um detem o conhecimento… o que os outros escrevem são exemplos inúteis, ridículos e por aí vai o modo gentil de conversar do mau dialogador.

O pior é que nem sabe tanto assim. Escreve demais e como todo falastrão acaba dizendo bobagens. Aquela do “Fortran usava essa técnica de ter extensões em C” … é sem comentários.

Gente, parei por aqui neste tópico. Venho para me divertir e não para me aborrecer. Se alguém vem aqui só para menosprezar os outros, é melhor destilar seu mau humor no seu próprio blog.

[]s
Luca

#145

[quote=celso.martins]. Não sei se algum algoritmo mais eficiente que um “for” possa fazer esse trabalho de filtragem. É óbvio que o “for” para listas de 1.000.000 de elementos será muito ineficiente.
[/quote]

Será? Nessas linguagens novas (Scala etc.) o “for” não é exatamente um laço de repetição estúpido e sim uma outra coisa, que só avalia e gera os elementos de uma lista à medida que é necessário. Assim as coisas não são tão ineficientes assim, e podem ser encadeadas sem problemas. E esse conceito também foi absorvido pelo C#, que tem até uma construção especial para isso (“yield”). É o Java que tem de carregar um monte de legado e compatibilidade retroativa que absorve mal as mudanças.

#146

[quote=thingol][quote=celso.martins]. Não sei se algum algoritmo mais eficiente que um “for” possa fazer esse trabalho de filtragem. É óbvio que o “for” para listas de 1.000.000 de elementos será muito ineficiente.
[/quote]

Será? Nessas linguagens novas (Scala etc.) o “for” não é exatamente um laço de repetição estúpido e sim uma outra coisa, que só avalia e gera os elementos de uma lista à medida que é necessário. Assim as coisas não são tão ineficientes assim, e podem ser encadeadas sem problemas. E esse conceito também foi absorvido pelo C#, que tem até uma construção especial para isso (“yield”). É o Java que tem de carregar um monte de legado e compatibilidade retroativa que absorve mal as mudanças. [/quote]

Esse é um aspecto interessante que até então eu desconhecia. Com certeza, ter laços mais eficientes é uma vantagem. Mas não entendi como esse mecanismo (avaliação e geração por demanda) pode ser mais eficiente. Normalmente em um filtro eu demando todos elementos para comparação. Não no mesmo momento, mas preciso de todos. Existe algum benchmark que dê números reais a esse aumento de eficiência. Como esse mecanismo por demanda funciona?

#147

encontrei um microcontrolador da família pic que pode rodar java.
http://www.oopic.com/

Seu compilador suporta sintaxe java, mas o resultado é código nativo do pic. Vantagem codificar em java pelo conforto da linguagem.

#148

[quote=celso.martins]
Esse é um aspecto interessante que até então eu desconhecia. Com certeza, ter laços mais eficientes é uma vantagem. Mas não entendi como esse mecanismo (avaliação e geração por demanda) pode ser mais eficiente. [/quote]

Não é eficiente no quesito “rapidez” (já que uma “lazy list” tem um overhead significativo), mas no quesito “tempo de resposta”.

É em outro sentido (você pode obter o resultado mais rapidamente e usando menos memória, já que em vez de gerar uma lista completa toda em memória, filtrá-la de uma vez para gerar outra lista, você simplesmente indica que o resultado é uma “lazy list”, que será consumida por demanda por outro método, que pode gerar ou não uma outra “lazy list”. ).

Você pode até definir “listas infinitas” (onde você tem um método que gera as tais listas), que podem ser consumidos por outros métodos.

No C# o LINQ tem um conceito semelhante (você pode pegar um resultado aos poucos - lazy - ou então pegar o resultado todo de uma vez. Por exemplo, se você precisa de um resultado ordenado, é necessário, em algum momento, pegar o resultado todo de uma vez, e então ordená-lo. Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.

#149

Esse é um conceito interessante, muito usado em acesso a dados em SGDB. Mas continuo sem ver como isso ajudaria a filtragem de uma lista.

Ela não está completa em memória, mas está completa em algum lugar. Em um SGDB, é lógico onde está o todo, mas e na lazy list? Provavelmente no disco. E acho que é a esse overhead que você se referiu. Concordo que a iteração em uma lista menor por vez pode gerar ganhos significativos de perfomance, mas se colocar esse overhead na balança, talvez esse ganho não seja tão significativo.

[quote=thingol]
Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.[/quote]

Blz… mas não é justamente essa iteração que é o gargalo do algoritmo? Isso precisa ser feito em algum lugar. Pode estar encapsulado em uma funcionalidade da linguagem, mas tem que existir. Não conheço algoritmos mais eficientes de filtragem como existe para ordenação, como o Bubble Sort. Pode ser que exista, mas não conheço.

#150

[quote=sergiotaborda]

Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
Mas suponhamos que vc está mesmo usand ruby/js/ etc… “puro”. Qual é o método/função em JS para acessar arquivos ? Você consegue utilizar dentro do Browser ? Porquê não consegue ? Porque JS corre sempre dentro de outro algo pq é uma linguagem de script. Ou seja, a maioria das funcionalidades que vc usa em ruby ou js-ss não são da linguagem, são de algum sistema ou framework. Em ruby, por exemplo, tem coisa que é realmente feita em C e o ruby apenas mascara a chamada ( hummm… JNI ?)

Realmente linguagem de script é para produzir programas. Agora, para produzir aplicações e sistemas é preciso algum mais. Isso é fato. E a realidade é que as linguagems de script ou evoluem para linguagems gerais ou implementam sub-bibliotecas para coisas nativas com cara de artefato da linguagem (Já o Fortran usava essa tecnica de ter extensões em C)

Com js ou ruby vc faz um programa que corre em um certo ambiente. Com java vc faz o ambiente. São duas coisas diferentes.[/quote]

Olha, eu posso fazer um compilador que Ruby que compile para um código que a máquina entenda da mesma forma que posso fazer com Java. Aliás é isso que fazem com o JRuby, o compilam para a máquina virtual, da mesma forma que Java é compilado para a mesma máquina virtual.

Se você faz programas em JS e Ruby que são interpretados em certos ambientes, eu faço programas em Java que também são interpretados nestes mesmos ambientes. Se você faz ambientes com Java, também o faço com qualquer linguagem normal.

Todas produzem zeros e uns no final, então todas podem fazer a mesma coisa. A diferença é o quanto elas facilitam para fazer essas tarefas.

Agora se você diz que não dá para comparar as APIs que vem com a linguagem, eu concordo. A do Java é um monstro mesmo.

#151

[quote=dlt][quote=sergiotaborda]Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
[/quote]

Alguém que está usando Rails não está usando Ruby? Não está usando as funcionalidades da linguagem e sim as do framework? COMO É QUE É? De onde você tirou isso?
[/quote]

Se um simples fato. quando vc faz “rails minhaapp” é uma coisa nativa ao ruby ou ao rails ? Se acha que é do ruby, remova o rails e tente executar o mesmo comando.

Um exemplo mais altonivel é ActiveRecord. Tudo bem que não é o Rails e apenas um componente do Rails, mas é nativo do ruby ? Não. É construido com Ruby, da mesma forma que JPA é construido com Java.

O Rails é um framework e está no nivel de abstraçção acima de um Mentaway , VRapor ou Spring. No mesmo nivel que um Grails.
O Ruby é uma linguagem. Experimente o Grails. vai ver que consegue o mesmo que em Ruby on Rails. Portanto fazer sites com essa facilidade não é uma coisa que depende da linguagem e sim do frameowrk utilizando que tem um certo poder. Um projeto “antigo” chamado JSpider ( se não me falha a memoria) era algo no nivel do rails mas diferente. Todos esses são application generators, que é um tipo de framework que mistura features de ferramenta.

O Grails é escrito usando o Hibernate e não o ActiveRecord. Mas uma implementação de ActiveRecord é possivel em Groovy já que ele tem as mesmas features de linguagem que ruby. Então, em tese, tudo o que existe em RoR poderia ser migrado para groovy sem problemas. É que o pessoa do Groovy optou por usar frameworks já consagrados. O ponto é este : Rails é um tipo de webapplication generator que mistura features de ferramenta com features de framwork. Nada disto tem a haver com a linguagem em si.

Então não é o JS que abre o arquivo, é a API Java que o JS manipula via Java Scripting. Isto é obvio.
Embora a linguagem seja o JS a API é do Java. O ponto era ilustrar a diferença entre uma linguagem e uma API.

O ambiente do JS é uma API . O JS roda dentro de uma API, uma biblioteca ( A Java Scripting). Java corre em cima de uma máquina.
É diferente.

Legal. Então vc pode listar exemplos de uso de ruby em cada uma das categorias ? ( estou especialmente curioso para saber como ruby acessa openGL ou que não seja através da biblioteca nativa escrita em C como a SDL… É que o Java tb use esse truque via API. Então não é justo dizer que isso é uma feature da linguagem… )

#152

[quote=celso.martins][quote=thingol]
Não é eficiente no quesito “rapidez” (já que uma “lazy list” tem um overhead significativo), mas no quesito “tempo de resposta”.
[/quote]

Esse é um conceito interessante, muito usado em acesso a dados em SGDB. Mas continuo sem ver como isso ajudaria a filtragem de uma lista.

Ela não está completa em memória, mas está completa em algum lugar. Em um SGDB, é lógico onde está o todo, mas e na lazy list? Provavelmente no disco. E acho que é a esse overhead que você se referiu. Concordo que a iteração em uma lista menor por vez pode gerar ganhos significativos de perfomance, mas se colocar esse overhead na balança, talvez esse ganho não seja tão significativo.

[quote=thingol]
Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.[/quote]

Blz… mas não é justamente essa iteração que é o gargalo do algoritmo? Isso precisa ser feito em algum lugar. Pode estar encapsulado em uma funcionalidade da linguagem, mas tem que existir. Não conheço algoritmos mais eficientes de filtragem como existe para ordenação, como o Bubble Sort. Pode ser que exista, mas não conheço.[/quote]

Bubble Sort é um dos piores para ordenação ;). E um algoritmo de filtragem que pode considerar é por exemplo que use várias CPUs de uma vez, como o divisão e conquista.

O que tem que pensar mesmo é quando coleções inteiras são uma vantagem, e quando um ter só iterador para elas é melhor.

Para este último já existe até um paradigma de programação próprio, o Stream Processing. Normalmente é usado em aplicações em tempo real, ou aquelas que você precise ter o resultado na tela o mais rápido possível, e não dá pra ficar esperando a aplicação carregar tudo e processar.

Paginação de resultados é outro uso que tenho em mente.

#153

Não, Ruby não tem melhor implementação de nada. Metaprogramação é muito útil, mas vai muito além de alterar classes em tempo de execução.[/quote]

Você é novo no Java né?

Não pegou a época do XML hell, Struts, Spring, EJB, etc.

A questão não é ir além, mas consertar o problema em questão, ou pelo menos oferecer uma solução.[/quote]

E o que isso tem a ver com a implementação OO do Ruby? Já trabalho com Java faz 6 anos, e antes disso já o usava bastante.

#154

Desenvolver em Rails não é só usar esses geradores de código. Isso é só uma parte do desenvolvimento, a menor delas. É preciso escrever muitas linhas de código em Ruby pra uma aplicação web. Não faz o menor sentido dizer que alguém que usa o framework não está programando em Ruby.

Não interessa em cima de que a linguagem foi construída. Interessa é que é possível sim abrir arquivos usando JavaScript.
Uma hora você fala que linguagem é só sintaxe e semântica, outra hora faz considerações sobre o ambiente em que a linguagem foi desenvolvida. Se a linguagem roda em cima da JVM ou usa a API do Java não vale… Seja mais coerente.

[quote]Legal. Então vc pode listar exemplos de uso de ruby em cada uma das categorias ? ( estou especialmente curioso para saber como ruby acessa openGL ou que não seja através da biblioteca nativa escrita em C como a SDL… É que o Java tb use esse truque via API. Então não é justo dizer que isso é uma feature da linguagem… )

Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real. [/quote]

Releia minha frase: “Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real.”

Por acaso eu disse que acesso a OpenGL é uma feature da linguagem? Não.
Eu disse que Ruby é usado nos cenários que você citou, apenas pra desbancar seu argumento falacioso de que Ruby só serve pra web. Como isso é feito são outros quinhentos.

Desktop: Shoes, bindings pra Gtk, ruby/tk, FXRuby, JRuby + Swing, entre outros.
Embebbed: Apresentação sobre Ruby embarcado.
Apps cloud: JRuby no Google Application Engine
Aplicações educativas: o que impede alguém de desenvolver uma aplicação educativa em Ruby?
Games 3D: Wolfstein. Tem vários bindings pra bibliotecas 3D.
Celular: Aplicações pro Iphone

Eu fui muito ingênuo ao cair na tentação de responder um troll. Respondi só pra desmitificar alguns argumentos infundados.

#155

Desenvolver em Rails não é só usar esses geradores de código. Isso é só uma parte do desenvolvimento, a menor delas. É preciso escrever muitas linhas de código em Ruby pra uma aplicação web. Não faz o menor sentido dizer que alguém que usa o framework não está programando em Ruby.
[/quote]

Pois é. Mas quando vc usa Spring vc fala “estou usando SPring” e não “Estou usando Java”. É obvio que vc vai programar com a linguagem. O ponto da conversa - que vc esqueceu - é saber se o Ruby é assim tão melhor que o Java ( não é comparável, é coisa de gosto) e se migrar do ambiente java para o do ruby (que não o JRuby) é uma boa escolha.

O argumento usual é que Ruby:

  1. é melhor porque se fazem aplicações web mais depressa. Ok. O meu contra-argumento é “mais depressa não significa melhor” e “é mais depressa por causa do Rails, retire o rails e vai demorar tanto ou mais” e “o mesmo é possivel com groovy - que é java based - logo migrar para ruby não tem vantagem tecnica”
  2. é possivel fazer mais coisas com menos linhas. Ok. O contra-argumento é “desde quando programas OO se medem por linhas?” e “é possivel condensar as coisas em Java tanto quanto em qualquer linguagem quando são features da API”
  3. Ruby é usado em muitos ambientes. Ok, Java também, em mais até. Portanto, dai tb nã ovem nenhuma vantagem.
  4. O projeto JRuby quer correr ruby sobre um JVM porque existem problemas de performance, gc, threads, etc… na vm padrão.
    Temos noticias de sites que foram construidos em ruby e estão sendo obrigados a mudar para outra coisa porque ruby ( não jruby) não escala a contento e/ou é dificil manter a longo prazo. Coisas como scala estão substituindo o rubi e até o JRuby acaba sendo uma machadada no ambiente ruby não baseado em JVM. Portanto, sair para a “plataforma” ruby fora da JVM é asneira neste momento.

A conclusão é simples: quer mudar de linguagem ? escolha outra que não ruby. Quer mudar de plataforma ? Grande asneira.

Eu sou coerente. É você que afirmou que " sim abrir arquivos usando JavaScript" e “É claro que você não vai tentar fazer isso de dentro de um browser, você vai usar Rhino que roda em cima da JVM.”
Admita, vc não sabe a diferença entre uma linguagem de script e uma linguagem de proposito geral.

Esse é o ponto. Não é uma feature da linguagem, tal como em Java não é. Mas em Java é uma feature de um API tal como em Ruby é uma feature de uma API. Não podemos comparar linguagens com base nas suas API padrão ou extensões. Apenas de features da linguagem si mesma. ( a sua sintaxe, a sua semantica, etc…). Se falamos de API, performance, facilidade de criar aplicações do tipo X usando frameworks ( que são APIs). estamos falando da plataforma. E vc acha -seja honesto - que a plataforma ruby é melhor ( mais robusta,mais confiável, mais abrangente) que a plataforma Java ?

Eu , sendo honesto, acho que ainda não. E portanto, mudar agora é suicidio. Scala, por exemplo (que não é uma linguagem de script), ou Groovy (que compete com ruby) são muito melhor candidatos. E como o inventour do Groovy já falou que se conhecesse scala não teria inventado o groovy, ora ai tem quem está sendo escolhido como a alternativa à linguagem Java. Mas a plataforma ? essa é a Palaforma Java. A razão é simples. É a mais evoluida que existe no mercado (univeersidades e prototipos não valem).

Você foi ingênuo ao pensar que pode convencer alguem que Ruby ( linguagem ou plataforma) é melhor que a concorrencia.

#156

[quote=sergiotaborda]O argumento usual é que Ruby:

  1. é melhor porque se fazem aplicações web mais depressa. Ok. O meu contra-argumento é “mais depressa não significa melhor” e “é mais depressa por causa do Rails, retire o rails e vai demorar tanto ou mais” e “o mesmo é possivel com groovy - que é java based - logo migrar para ruby não tem vantagem tecnica”[/quote]

É mais depressa porque o Ruby é mais alto-nível e mais expressivo que Java, embora estas sejam características muito subjetivas. A própria natureza dinâmica da linguagem te permite automatizar coisas repetitivas na hora de escrever código com facilidade. Rails permite desenvolver tão depressa por causa das features do Ruby, não o contrário. Existem outros frameworks altamente produtivos (Ramaze, Merb, etc…) que foram construídos em cima dessas features.

Ok, mas esse argumento não é sobre o número de linhas, é sobre o quanto você precisa se focar nas regras de negócio da sua aplicação ao invés de detalhes de baixo nível como abrir arquivos, etc…

[quote]4) O projeto JRuby quer correr ruby sobre um JVM porque existem problemas de performance, gc, threads, etc… na vm padrão.
Temos noticias de sites que foram construidos em ruby e estão sendo obrigados a mudar para outra coisa porque ruby ( não jruby) não escala a contento e/ou é dificil manter a longo prazo. Coisas como scala estão substituindo o rubi e até o JRuby acaba sendo uma machadada no ambiente ruby não baseado em JVM. Portanto, sair para a “plataforma” ruby fora da JVM é asneira neste momento.[/quote]

Apesar dos seus defeitos a MRI ainda é insubstituível em alguns cenários, até porque o JRuby não é 100% compatível com muitas gems.
Esse assunto de escalabilidade é tão polêmico quanto este que estamos discutindo e existem controvérsias a respeito da substituição de partes do Twitter originalmente escritas em Ruby por Scala. Tem gente que argumenta que os problemas de escalabilidade do Twitter não foram culpa do Ruby.

Manutenibilidade de código é responsabilidade do programador, não da linguagem.

Escolha Ruby pros casos certos. Não deixa nada a desejar em relação a Java em vários aspectos.

Não existe um consenso sobre o que é uma “linguagem de script”. Ruby, Python, Perl e outras “linguagens de script” são também linguagens de propósito geral.

Podemos e devemos. Muitas vezes Python ou Java são escolhidas pra uma situação justamente por causa das bibliotecas.

Não. Entretanto, Ruby roda em cima da plataforma Java. Irônico, não?

Não acho que Ruby é melhor linguagem/plataforma que a concorrência. Python, JavaScript, Lua, Scheme, Scala, e pasme, até Java são melhores do que Ruby dependendo do contexto. Ingenuidade é acreditar em balas de prata.

#157

Dalto, sério, desiste, é pura perda de tempo :slight_smile:

#158

Desisti já. Foi a última msg. :smiley:

#159

[quote=sergiotaborda]
Você foi ingênuo ao pensar que pode convencer alguem que Ruby ( linguagem ou plataforma) é melhor que a concorrencia.[/quote]

Pra mim concorrência é ignorância.

Por mim que se matem os evangelistas, defender com unhas e dentes uma plataforma, num fórum de internet, é massagear o ego pra depois ver o tempo perdido que tiveram.

Eu já trabalhei com .NET, com Java e agora com RoR e não fico defendendo nem um nem outro, acho que cada um tem suas qualidades e defeitos, mas acho que abrir a cabeça foi a melhor coisa pra mim, vou repetir, PRA MIM!

#160

Não, Ruby não tem melhor implementação de nada. Metaprogramação é muito útil, mas vai muito além de alterar classes em tempo de execução.[/quote]

Você é novo no Java né?

Não pegou a época do XML hell, Struts, Spring, EJB, etc.

A questão não é ir além, mas consertar o problema em questão, ou pelo menos oferecer uma solução.[/quote]

E o que isso tem a ver com a implementação OO do Ruby? Já trabalho com Java faz 6 anos, e antes disso já o usava bastante.[/quote]

Ruby usa metaprogramacao baseado na manipulacao de objetos em tempo de execucao.

Você acha que o Rails usa API de reflection do Java por baixo dos panos?