Ruby on Rails?

Em primeiro lugar, desculpem-me pela mensagem imensa. :smiley:

Isso demonstra bem que você tem muito pouco conhecimento do que está criticando. A linguagem Ruby foi desenvolvida no início da década de 90, muito próximo ao Java inclusive. E naquela época não existiam IDEs com metade do poder que existem hoje.

VIm possui highlighting e auto-completion. Sinto muito que você não saiba utiliza-lo. Java ao ser criada nem ao menos tentou resolver a falta de ferramentas, correto?
Outro ponto, mais importante, é que é fato empírico que existe um nível saudável de simbolismos que aumentam a legibilidade do programa.

Esse tipo de argumentação mostra que você desconhece bem as implicações de tipagem dinâmica. Sei que ela tem seus prós e contras, mas dizer que o programa se torna menos seguro é atestar o desconhecimentoa respeito do assunto.
Só por curiosidade, quantas vezes na vida você ja chamou funções que não pertecem a um determinado objeto? Esse tipo de erro praticamente nunca ocorre. E você ainda possui mecanismos para verificação de tipo caso seja necessário.

Minha IDE chama-se VIm e um conjunto extenso de programas UNIX que atuam bem, e rápido, em um escopo reduzido.

E o que isso significa? Que não existe outra forma de debugger, profiler, testadores em Ruby?! Que a única forma de ter acesso a essas ferramentas são IDEs?!
Antes de criticar, por favor, se informe. Ruby possui um framework de testes integrado a biblioteca básica da linguagem. Ruby possui um utilitário de instalação e remoção de pacotes, gems em ruby, que já instala a documentação necessária. Ruby possui console interativo para você experimentar construções ou que você desejar fazer. Ruby possui um utilitário de consulta a documentação on-line.
Existem outras formas de se obter os resultados que para você só podem ser obtidos através de poderosas IDEs.

Para mim esse parece ser o SEU comportamento. Quem veio fazer críticas e falar que Ruby não possui boas IDEs foi você. Eu apenas argumentei que a linguagem não é tão dependente de um IDE específica e disse que a importância de uma boa IDE é outra. E que em Ruby a realidade do ambiente de desenvolvimento é outra. E existem boas IDEs ou ferramentas que não deixam o programador Ruby na mão, você apenas as desconhece.

Concordo. Eu me limitei ao aspecto sintático porque era esse o meu foco na discussão.

Em Ruby, um operador nada mais é que uma chamada a uma função. Você pode criar funções em Java?! Isso torna seu código mais complicado?
Concordaria com você caso me dissese que eles, os operadores, podem levar o programador a conclusões errôneas. Porém, em última instância, quem programa é o programador, e se o programador não sabe o que está fazendo então ele não deveria estar programando. Sobrecarga de operador não é uma tarefa proponsa a erros que necessita ser evitada.
Ruby, diferente de Java, não é uma linguagem que tenta proteger o programador de si mesmo. Ruby oferece soluções elegantes a bons programadores. Isso é uma faca de dois gumes, pois dá a liberdade de mals programadores fazerem coisas bizarras…

Sem querer ser agressivo. Mas comporte-se como se eu estivesse falando de uma linguagem, ferramenta, e não como de um parente seu.
Caso você não tenha lido, eu vou colocar em negrito para não passar em branco dessa vez:

Java, pelo menos sintaticamente, é arcaica.

Eu fui claro o suficiente quando estou me referindo apenas ao aspecto sintático da linguagem? Falei que Java é uma porcaria como um todo ou apenas disse que sintaticamente é arcaica? Por favor, não coloque palavras na minha boca, pois em nenhum momento eu disse que Java é uma porcaria.

Em nenhum momento eu disse o contrário. Mas acho que para alguns casos específicos, Java já está perdendo espaço para outras alternativas. Isso é bom, até para vocês, que vão se ver obrigados a se modernizar e correr atrás do tempo perdido em alguns aspectos.

Falta muito para você ser pragmático.

Nossa… esse tipo de mensagem acaba com o meu dia. Só esse post representa uns 5 anos de desatualização em novas abordagens de desenvolvimento.

[quote=daniellibanori][quote=Thiagosc]
O fato de não ser obrigado especificar tipos e se procupar com diagrama de classes e arquiteturas ou com trabalho braçal como no caso do C dá a impressão de que é mais rápido, é muito fácil escrever qualquer coisinha que cuspa algum resultado na tela.

Mas é só impressão mesmo. Isso não significa que o resultado será melhor.
[/quote]

Nossa… esse tipo de mensagem acaba com o meu dia. Só esse post representa uns 5 anos de desatualização em novas abordagens de desenvolvimento.[/quote]

Não esqueça que para o Thiago IDE boa é o RAD da IBM…

Já já chegarão ao ponto de dizer: “Java é uma linguagem melhor por que seus programadores usam Eclipse, que é bonitinho e cheio de recursos, e Ruby é uma linguagem pior por que seus programadores usam Vi, que não não tem menus e janelinhas pipocando a todo momento”.

Eu programo Ruby no Eclipse. E aí? A linguagem ficou melhor por que eu tou usando o Eclipse? Pra mim, fica a mesma coisa, só que vou ter um custo bem menor pra executar determinadas tarefas.

Discussão mais sem sentido.

E até 2001 não existiam IDEs Java dignas de boas lembranças também. Será que não está demorando um pouquinho para criarem alguma coisa na linha para Ruby também (além do Eclipse RDT, é claro)?

Pessoalmente, acho $ e @ bem ruins, e acho coisas como blocos try/catch bem malas também. Os primeiros aumentam muito a minha “developer memory load”, pois eu preciso sempre ficar lembrando e associando que $=public. Ambos tornam meus códigos bem chatos de serem lidos.

Contudo, dificilmente alguém vai alterar a linguagem Java para oferecer um suporte a tratamento de exceções semelhante ao do IO nem alterar a linguagem Ruby para introduzir palavras-reservadas private/static/public/whatever pois isso leva a um risco de projeto que certamente não vale a pena correr. Então, acostumem-se com estas características, tentem achar um jeito de driblá-las e parem de achar que só por estes motivos fúteis uma linguagem é melhor/pior do que a outra.

Sabem uma coisa bem interessante que existe no Ruby e que ninguém aponta como um defeito do Java? Um sistema de tipos numéricos tão flexível quanto o Fixnum/Bignum. Isso é muito útil em Ruby e faz uma real diferença no dia-a-dia, principalmente se seu dia-a-dia for recheado por sistemas financeiros/científicos em que é preciso lidar o tempo todo com números que muitas vezes podem escapar da faixa de valores de um determinado tipo e dar um overflow sem você notar.

Contudo, Ruby poderia ter um sistema de threads decente, sem aquela implementação amadora de green threads que permite que implementemos sistemas multi-thread sobre o DOS (yupi! \0/ ).

Uma coisa que estressa no RoR é que algumas coisas realmente são bem mais simples porém tem outras que para funcionar tem que se fazer umas gambis violentas (não que Java não tenha disso)…

Exemplo, vai brincar de Class Table Inheritance no Rails,vai … :slight_smile:

Isso é verdade.

Uma vez, em um pet project, eu precisei fazer um relacionamento duplo - algo do tipo um jogo tem o time da casa e o visitante - e não teve documentação, comunidade ou fórum que me respondesse como fazer isso. Tentei de tudo que tinha na documentação do Rails. Resultado: deixei a brincadeira pra lá.

Às vezes, o excesso de convenção no rails me deixa um pouco irritado.

Eu acho que vcs deviam voltar ao ANSI C.

Querem orientação à objetos?? Criem estruturas com ponteiros para funções :wink:

Demonstra como? O que uma coisa tem a ver com outra? É fato que as nossas expectativas aumentam conforme o tempo passa.

Um exemplo: qualquer coisa menos completa que o javadoc hoje em dia seria encarada como uma falha terrível.

Outro exemplo: um browser com o nível de funcionalidade do IE 1.0 faria sucesso hoje em dia? Nós esperamos mais de um browser, apesar de ainda estarmos falando de “browsers”, o tempo passou e a nossa expectativa aumentou.

[quote=daniellibanori]VIm possui highlighting e auto-completion. Sinto muito que você não saiba utiliza-lo. Java ao ser criada nem ao menos tentou resolver a falta de ferramentas, correto?
Outro ponto, mais importante, é que é fato empírico que existe um nível saudável de simbolismos que aumentam a legibilidade do programa.[/quote]

haha. Sério, acho que essa atitude sua é coisa de fã. Dá uma olhada em C++ e diga se aqueles símbolos são realmente mais “fáceis” principalmente para um iniciante. Uma linguagem mais limpa é o ideal, mas essa é só a minha opinião.

Já trabalhei bastante com linguagens script para saber que somos obrigados a nos preocupar com muita coisa que não precisamos em Java por causa da tipagem.

Um dia na Discovery Channel eu vi um programa onde mostrava um pessoal construindo um prédio moderno ou coisa do gênero.

O cara tinha o modelo no computador e com uma impressora 3D (!) esculpiu o prédio num material lá. Logo eles tinham um modelo 3D do prédio.

Porque em TI temos tantos luditas? Por que a tecnologia não pode nos ajudar assim como ajuda várias outras áreas?

Cara, sabe o que significa um “I” no IDE, é de “integrated”. O intuito é agrupar um conjunto de funcionalidades, numa interface padrão, numa GUI.

Eu espero que não esteja advogando “a volta da linha de comando”, pois isso seria o cúmulo do sem noção.

[quote=daniellibanori]E o que isso significa? Que não existe outra forma de debugger, profiler, testadores em Ruby?! Que a única forma de ter acesso a essas ferramentas são IDEs?!
[/quote]

Não coloque palavras que eu não escrevi. Isso singifica que uma ferramenta integrada com tudo isso é muito melhor.

[quote=daniellibanori]E
Antes de criticar, por favor, se informe. Ruby possui um framework de testes integrado a biblioteca básica da linguagem. Ruby possui um utilitário de instalação e remoção de pacotes, gems em ruby, que já instala a documentação necessária. Ruby possui console interativo para você experimentar construções ou que você desejar fazer. Ruby possui um utilitário de consulta a documentação on-line.
Existem outras formas de se obter os resultados que para você só podem ser obtidos através de poderosas IDEs.
[/quote]

Desculpa, mas isso não passa nem perto do tanto que uma IDE provê.

E eu mostrei acima que isso é puro non-sense. Querer que profissionais larguem as suas ferramentas para trabalhar no “vi” é como pedir para escritores usarem pena, tinteiro e pergaminhos, ou então pedir que médicos troquem a ciência moderna por sangrias.

Imagina um Rubyista da engenharia: CAD, para quê? Tudo o que você precisa é de lápis, borracha e papel. Calculadora!? Que espécie de burro precisa de calculadores, eles não ensinam mais matemática hoje em dia?

Menos, menos. Você está cegamente tentando defender um ponto que é impossível de estar correto.

Operadores tem outros significado no nosso dia a dia. Nós pensamos naturalmente neles como relacionados a números e matemática apenas. Estou errado?

Se o propósito é apenas para “facilitar a matemática” porque eles não incluem isso na linguagem, ao invés de usar “sobrecarga de operadores”?

Operadores não são como funções, nem adianta comparar.

[quote=daniellibanori]
Concordaria com você caso me dissese que eles, os operadores, podem levar o programador a conclusões errôneas. Porém, em última instância, quem programa é o programador, e se o programador não sabe o que está fazendo então ele não deveria estar programando.[/quote]

Você já trabalhou em projetos maiores que 1 programador? Se sim, então sabe que não apenas precisamos saber o que fazemos, mas também entender o que outros escrevem.

Com sobrecarga de operadores não é possível fazer afirmação nenhuma a respeito de nenhum operador pois nunca se sabe o que acontecerá. Uma função é mais descritiva do que executa.

Já disse, se o problema é matemática então que incluam o uso de operadores para BigInteger ou coisa do gênero.

Acredito que eu e vários aqui pensam o contrário.

Eu discordo. E acho Ruby muito feio.

[quote=daniellibanori]
Sem querer ser agressivo. Mas comporte-se como se eu estivesse falando de uma linguagem, ferramenta, e não como de um parente seu.[/quote]

Não, estou falando de fatos. Não se analisa uma linguagem pela sua sintaxe apenas.

Isso não quer dizer absolutamente nada. A menos que esteja avaliando o Java como um todo, mas aí cai no que dissera antes.

1- Isso é sonho. Sempre existiram e existirão linguagens ocupando certos nichos, hoje não é diferente. Veja Perl, PHP e outras.

2 - Não há nada de errado em atualizar, fazemos isso o tempo todo (pelo menos quem quer sobreviver) o errado é um bando de bullies pela internet atacar outros e ameaça-los como crianças

Existe uma diferença entre genuínamente aprender algo melhor, ou largar o melhor para trabalhar no vi assim como faziam nos anos 80.

[quote=daniellibanori]
Falta muito para você ser pragmático.[/quote]

Será?

Eu espero que não esteja advogando “a volta da linha de comando”, pois isso seria o cúmulo do sem noção.

Deus te ouça. Os verdadeiros programadores vão prosperar, nesse dia. }-)

Operadores tem outros significado no nosso dia a dia. Nós pensamos naturalmente neles como relacionados a números e matemática apenas. Estou errado?
Se o propósito é apenas para “facilitar a matemática” porque eles não incluem isso na linguagem, ao invés de usar “sobrecarga de operadores”?
Operadores não são como funções, nem adianta comparar.

[code]
int x = 2 + 3; // isso pode
String x = “oi” + “boi”; // isso tambem

public class Complex{
double real;
double imaginary
public Complex(double r, double i){
this.real = r; this.imaginary = i;
}
// nao seria mais facil sobrecarregar +
public Complex add(Complex X){
return …;
}
}[/code]

“Operadores não são como funções” :shock:

a unica diferença, ao meu ver, é que quando usamos operadores podemos lidar com procedência.

[quote=peczenyj]“Operadores não são como funções” :shock:

a unica diferença, ao meu ver, é que quando usamos operadores podemos lidar com procedência.[/quote]

Acho que já disse bastante do que poderia ser dito sobre problemas com manutenção e entendimento de código, mais que isso talvez você devesse procurar no Google tópicos a respeito. Tenho a impressão que tem um pessoal aqui que responde apenas pelo prazer de contrariar, se fazendo de desentendidos.

Se você acha que sobrecarga de operadores é “o que há” em termos de linguagem, vai que é sua Taffarel! :slight_smile:

Você não sabe o que fala.
Vou parar por aqui essa discussão com você.
Estou contente com a performance do meu desenvolvimento e não preciso convencer ninguém de que minhas ferramentas e metodologias são boas.
Boa sorte

As caracteristicas da linguagens influenciam na sua manutenção? talvez as caracteristicas de quem programou influencie.

alem do mais, sobrecarga de operadores tem no C++, D, C#, VB e não vejo os programadores reclamando. perigoso mesmo é herança, no java e outras linguagens orientadas à objetos.

class Stack extends Vector
class Properties extends Hashtable

entende o que eu digo?

Não estou apenas falando de sobrecarga de operador, estou falando de:

  • sobrecarga de operadores
  • code blocks
  • mixins
  • classes abertas
  • introspecção decente

Isso são features, mas vou um pouco além disso. Estou falando principalmente de filosofia da linguagem.

eu prefiro comprar pão por unidade e não por peso… :lol:

É uma forma mais dinamica e tranparente!!!
Quer dizer que é bem mais fácil de trabalhar com ela!!!

e outras frameworks
Active Record;
Action Pack;
Action Mailer;
Active Support;
Active WebServices.
naum esquecendo delas!!!

rsrsrsrs

Posso saber quais, na sua opnião? Eu sei que existem algumas coisas que estão bem longes da perfeição, como internacionalização, por exemplo. Mas gostaria de saber na sua opnião o que precisa de gambis.

Vamos lá então.
Partindo do pressuposto que você já tem um banco de dados funcionando.

$rails pet_project
$cd pet_project

Crie o model Team

$script/generate model Team

Edite db/migrate/001_create_teams.rb

class CreateTeams &lt ActiveRecord::Migration
  def self.up
    create_table :teams do |t|
      t.column :name, :string
    end
  end

  def self.down
    drop_table :teams
  end
end

Crio o model Game

$script/generate model Game

Edite db/migrate/002_create_games.rb

class CreateGames &lt ActiveRecord::Migration
  def self.up
    create_table :games do |t|
      t.column :home_id, :integer
      t.column :visitor_id, :integer
      t.column :home_gols, :integer
      t.column :visitor_gols, :integer
      t.column :date, :date
    end
  end

  def self.down
    drop_table :games
  end
end

Execute as migrations

$rake migrate

Crie o relacionamento dos times com os jogos, edite app/models/team.rb

class Team &lt ActiveRecord::Base
  has_many :games, :finder_sql =&gt 'SELECT * FROM games WHERE home_id = #{self.id} OR visitor_id = #{self.id}'
end

Crie o relacionamento dos jogos com os times edite app/models/game.rb

class Game &lt ActiveRecord::Base
  belongs_to :home, :class_name =&gt 'Team', :foreign_key =&gt 'home_id'
  belongs_to :visitor, :class_name =&gt 'Team', :foreign_key =&gt 'visitor_id'
end

Brinque no console

$script/console
palmeiras = Team.create( :name =&gt 'Palmeiras' )
saopaulo = Team.create( :name =&gt 'São Paulo' )
classico = Game.create( :home =&gt palmeiras, :visitor =&gt saopaulo, :home_gols =&gt 3, :visitor_gols =&gt 0, :date =&gt Time.now )
classico.home == palmeiras
classico.visitor == saopaulo
palmeiras.games
saopaulo.games

Saia do console (CTRL + D)

Veja seu banco de dados:
SELECT * FROM teams;
SELECT * FROM games;

Difícil?

Não tenho nada a ver com a discussão de vocês, mas… você acha que não?

Posso saber quais, na sua opnião? Eu sei que existem algumas coisas que estão bem longes da perfeição, como internacionalização, por exemplo. Mas gostaria de saber na sua opnião o que precisa de gambis.
[/quote]

Uma coisa que tem que fazer uma gambi violenta é a questão do Class Table Inheritance, ie, montar uma herança com uma tabela para cada classe. O RoR suporta apenas Single Table Inheritance e para fazer funcionar tem que fazer algumas gambis que com tabelas e views. Antes ainda era preciso colocar alguns patches no ActiveRecord mas atualmente isso não é mais necessário.

Tem coisas que só o GUJ faz por você. Uma comunidade Java foi o único lugar onde solucionaram minha dúvida de Ruby on Rails. :mrgreen:

Valeu, daniel!