Por que Ruby é mais adequado para Rails do que Python? [fechadas]


90

Python e Ruby são geralmente considerados primos próximos (embora com uma bagagem histórica bastante diferente) com expressividade e poder semelhantes. Mas alguns argumentaram que o imenso sucesso do framework Rails realmente tem muito a ver com a linguagem em que é construído: o próprio Ruby. Então, por que Ruby seria mais adequado para tal estrutura do que Python?


44
Aliteração. _
Jimmy

75
"Python on Pails" simplesmente não tem a mesma sensação ...
efêmero

105
@Ephemient: Eu acredito que seria Python on Planes.
Jimmy

37
@Jimmy: Quem precisa de aviões? import antigravity ;-) xkcd.com/353
Vinay Sajip

157
Existe um Java nas prisões?
Nosredna

Respostas:


170

Provavelmente, existem duas diferenças principais:

Ruby tem encerramentos elegantes e anônimos.

Rails os usa com bons resultados. Aqui está um exemplo:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

Fechamentos / lambdas anônimos tornam mais fácil emular novos recursos de linguagem que receberiam blocos. Em Python, os encerramentos existem, mas devem ser nomeados para serem usados. Portanto, em vez de poder usar closures para emular novos recursos de linguagem, você é forçado a ser explícito sobre o fato de que está usando uma closure.

Ruby tem uma metaprogramação mais limpa e fácil de usar.

Isso é usado extensivamente no Rails, principalmente por causa de sua facilidade de uso. Para ser específico, em Ruby, você pode executar código arbitrário no contexto da classe. Os seguintes snippets são equivalentes:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

Em ambos os casos, você pode fazer:

Bar.new.hello  

que imprimirá "OLÁ". O class_evalmétodo também recebe uma String, portanto, é possível criar métodos dinamicamente, conforme uma classe está sendo criada, que possuem semânticas diferentes com base nos parâmetros que são passados.

É, de fato, possível fazer esse tipo de metaprogramação em Python (e outras linguagens também), mas Ruby tem uma vantagem porque a metaprogramação não é um estilo especial de programação. Isso decorre do fato de que em Ruby, tudo é um objeto e todas as linhas de código são executadas diretamente. Como resultado, Classes são eles próprios objetos, corpos de classe têm um selfapontador para a classe e você pode chamar métodos na classe enquanto está criando um.

Isso é em grande parte responsável pelo grau de declaratividade possível no Rails, e pela facilidade com que somos capazes de implementar novos recursos declarativos que parecem palavras-chave ou novos recursos de linguagem de bloco.


40
Em Python, tudo são objetos e todas as linhas de código são executadas diretamente também. ;) Mas, você não tem um "self" apontando para a classe no corpo da classe, que não é criado até depois da definição da classe, então você tem que colocar esse código depois em Python, que reconhecidamente é menos elegante , mas funcionalmente equivalente.
Lennart Regebro

31
@lennart, esse é o ponto. Python permite que você faça os mesmos tipos de coisas com lambdas nomeadas, decoradores e colocar código após as classes serem criadas, mas a perda de elegância aumenta rapidamente e torna algo como Rails notavelmente mais difícil de implementar ou menos elegante para usuários finais.
Yehuda Katz

9
Eles realmente não parecem grandes diferenças para mim.
Dietrich Epp

10
@lennart estou um pouco confuso. Eu disse que você não precisava deles no Python - mas não tê-los tornava o código mais difícil de implementar ou menos elegante para os usuários finais (um ou outro). As linguagens estão se tornando completas - você pode escrever Rails em C se quiser.
Yehuda Katz

5
@lennart Agora estamos entrando em território subjetivo, mas os dois recursos dos quais falei são bastante convenientes ao produzir frameworks com uma mistura de programação declarativa e procedural. A falta de lambdas anônimos, em particular, é uma limitação da expressividade do Python. A falta de consistência (a necessidade de trabalhar com classes criadas apenas DEPOIS das classes serem criadas) também é bastante limitante.
Yehuda Katz

58

Aqueles que argumentaram que

o imenso sucesso do framework Rails realmente tem muito a ver com a linguagem em que é construído

estão (IMO) enganados. Esse sucesso provavelmente se deve mais a um marketing inteligente e sustentável do que a qualquer habilidade técnica. Django sem dúvida faz um trabalho melhor em muitas áreas (por exemplo, o administrador embutido) sem a necessidade de quaisquer recursos do Ruby. Não estou zombando do Ruby, apenas defendendo o Python!


10
Bem, estamos entrando em um território subjetivo aqui. Se você acha que o administrador é um "único", talvez seja porque você não aproveitou os benefícios de economia de tempo que ele confere. Existe alguma área que você acha que Django faz pior do que Rails, por causa de recursos que Ruby tem e Python não? A questão realmente não é qual framework é melhor - é se (como apontado em outra parte desta questão) há algo faltando no Python que o torna menos capaz de desenvolver um framework incrível. Pelas evidências, não existe tal falta.
Vinay Sajip

18
@Para os downvoters: Eu realmente não me importo, mas estou curioso para saber por que você achou que minha resposta foi inútil . Eu não percebi que um votou negativamente porque um discordou da posição de alguém - em geral, votei negativamente apenas quando achei que uma pergunta ou resposta estava de alguma forma piorando as coisas.
Vinay Sajip

5
Posso escrever minha própria seção de administração, não preciso disso no framework. Eu prefiro outras maneiras de tornar meu aplicativo mais fácil de escrever.
nitecoder

8
@railsninja: Bom para você. Eu prefiro não ter que escrever páginas padronizadas para tarefas administrativas de manutenção de que a maioria dos sistemas precisa. Recentemente, eu fiz um trabalho pro-bono para um site de caridade local, e não teria sido viável fazer esse site se o administrador do Django não fizesse parte da equação. Do jeito que estava, eu forneci um site com uma interface do usuário Ajaxified razoavelmente personalizada para os usuários finais, mas os administradores de back-end trabalharam com o administrador e foi mais do que adequada para suas necessidades.
Vinay Sajip

6
@Matt: Sua pergunta é por que Ruby é MAIS adequado que Python. E a resposta, muito correta, é que não.
Lennart Regebro

54

A comunidade python acredita que fazer as coisas da maneira mais simples e direta possível é a mais alta forma de elegância. A comunidade ruby ​​acredita que fazer as coisas de maneiras inteligentes que permitem códigos legais é a mais alta forma de elegância.

Rails é tudo sobre se você seguir certas convenções, um monte de outras coisas acontecerão magicamente para você. Isso combina muito bem com o jeito rubi de ver o mundo, mas não segue o jeito python.


4
Claro, mas há perda de pessoas Perl (bem, talvez não muitas ) que pensam que frases curtas enigmáticas são legais, e muitas pessoas Lisp que juram que é a única linguagem verdadeira. Definitivamente, estamos no território de qualquer coisa que flutue seu barco.
Vinay Sajip

4
Rails tem magia zero, está bem ali na fonte. Se você quer saber como, saia da sua bunda e descubra.
nitecoder

21
"Qualquer tecnologia suficientemente avançada é indistinguível da magia." - Arthur C. Clarke
Vinay Sajip

1
"mágica" significa que a estrutura faz muitas coisas por você sem ser solicitada diretamente. Novamente, não estou fazendo julgamentos de valor, é um estilo de fazer as coisas que tem lados bons e lados ruins. Pessoalmente, acho que funciona maravilhosamente bem em trilhos.
Matt Briggs

2
Elegância e convenções não denotam magia.
BJ Clark

26

Este debate é um novo debate "vim versus emacs"?

Sou um programador Python / Django e até agora nunca encontrei um problema nessa linguagem / framework que me levasse a mudar para Ruby / Rails.

Posso imaginar que seria o mesmo se eu tivesse experiência com Ruby / Rails.

Ambos têm filosofia semelhante e fazem o trabalho de maneira rápida e elegante. A melhor escolha é aquela que você já conhece.


25

Pessoalmente, acho que o ruby ​​é superior ao python em muitos aspectos, o que eu chamaria de 'expressividade consistente'. Por exemplo, em ruby, join é um método no objeto array que produz uma string, então você obtém algo assim:

numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"

Em python, join é um método no objeto string, mas que gera um erro se você passar algo diferente de string como o objeto a ser unido, então a mesma construção é algo como:

numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'

Existem muitos desses pequenos tipos de diferenças que se somam com o tempo.

Além disso, não consigo pensar em uma maneira melhor de introduzir erros lógicos invisíveis do que tornar os espaços em branco significativos.


29
Minha experiência é que tornar o espaço em branco significativo ajuda a eliminar os erros de lógica. É muito mais confuso ter espaçamento e sintaxe discordantes.
Nosredna

5
Em linguagens com começa e termina e em linguagens com colchetes e em assembly, eu vi código ser colado de forma errada e causar problemas posteriormente. Isso sempre é um problema. Você teve muitos problemas com pessoas que colavam mal o Python?
Nosredna

5
O espaço em branco não é significativo no Python: secnetix.de/~olli/Python/block_indentation.hawk . É quase impossível introduzir "erros invisíveis" devido ao recuo no Python (você tem que modificar as configurações do seu editor) enquanto, claro, é completamente possível introduzir erros invisíveis devido ao recuo em qualquer outra linguagem, simplesmente recuando incorretamente. @fields: Portanto, não copie o código via skype ou HTML. Nossa.
Lennart Regebro

7
É correto que o Python reclame se você tentar adicionar não strings a strings, como em um Join. Isso ocorre porque explícito é melhor do que implícito. Existem muito poucas conversões automáticas em Python, e a razão para isso é que elas tendem a causar problemas, especialmente em linguagens dinâmicas, já que as coisas acabam não sendo do tipo que você esperava. Claro que o método "" .join () parece retrógrado no início, mas esse é o motivo. Na verdade, não faz sentido na lista ...
Lennart Regebro

8
Deus todo-poderoso ... Você quer dizer digitado estaticamente, não fortemente tipado. Python é fortemente tipado, assim como Ruby: stackoverflow.com/questions/520228/… Você também não pode adicionar uma string a um inteiro em Ruby. Estou ficando cansado de corrigi-lo, verifique seus fatos antes de responder no futuro.
Lennart Regebro

15

A verdadeira resposta é que nem Python nem Ruby são candidatos melhores / piores para um framework web. Se você deseja objetividade, precisa escrever algum código em ambos e ver qual se encaixa melhor em sua preferência pessoal, incluindo a comunidade.

A maioria das pessoas que defende um ou outro nunca usou a outra língua seriamente ou está 'votando' em sua preferência pessoal.

Eu diria que a maioria das pessoas decide o que quer que eles entrem em contato primeiro porque lhes ensina algo novo (MVC, testes, geradores etc.) ou faz algo melhor (plug-ins, modelos, etc.). Eu costumava desenvolver com PHP e entrei em contato com RubyOnRails. Se eu conhecesse MVC antes de encontrar Rails, provavelmente nunca teria deixado o PHP para trás. Mas assim que comecei a usar Ruby, gostei da sintaxe, dos recursos etc.

Se eu tivesse encontrado o Python e um de seus frameworks MVC primeiro, provavelmente estaria elogiando essa linguagem!


11

Python tem uma grande variedade de estruturas semelhantes a Rails. Há tantos que dizem que durante uma palestra típica na PyCon, pelo menos um framework da web verá a luz.

O argumento de que a metaprogramação de Rubys a tornaria mais adequada é IMO incorreto. Você não precisa de metaprogramação para estruturas como esta.

Portanto, acho que podemos concluir que Ruby não é melhor (e provavelmente nem pior) do que Python nesse aspecto.


8

Porque Rails é desenvolvido para tirar vantagem do conjunto de recursos do Rubys.

Uma pergunta similarmente sem gorm seria "Por que o Python é mais adequado para Django do que Ruby?".


4

Suponho que não devemos discutir as características da linguagem em si, mas sim os acentos que as respectivas comunidades fazem nas características da linguagem. Por exemplo, em Python, reabrir uma classe é perfeitamente possível, mas não é comum; em Ruby, entretanto, reabrir uma aula é algo da prática diária. isso permite uma customização rápida e direta do framework para o requisito atual e torna o Ruby mais favorável para frameworks do tipo Rails do que qualquer outra linguagem dinâmica. Daí minha resposta: uso comum de reabertura de aulas.


1

Alguns disseram que o tipo de metaprogramação necessária para tornar o ActiveRecord (um componente-chave do rails) possível é mais fácil e mais natural de fazer em ruby ​​do que em python - eu não conheço python ainda;), então não posso confirmar pessoalmente esta afirmação.

Eu usei rails brevemente, e seu uso de catchalls / interceptores e avaliação dinâmica / injeção de código permite que você opere em um nível muito mais alto de abstração do que alguns dos outros frameworks (antes do tempo). Tenho pouca ou nenhuma experiência com o framework Python - mas ouvi dizer que é igualmente capaz - e que a comunidade python faz um ótimo trabalho apoiando e promovendo empreendimentos python.


3
Na verdade, esse tipo de "mágica" é frequentemente desaprovado em Python; por exemplo, code.djangoproject.com/wiki/RemovingTheMagic
ephemient

2
Acho que "mágica" (truques de metaprogramação) por causa de "mágica" deve ser sempre desaprovada - um código mais simples, mas igualmente poderoso e expressivo, deve sempre vencer - mas há casos em que a única maneira de fornecer a funcionalidade e sintaxe exatas que você quer requer "magia" - e nesses casos, a "magia" é indiscutível;)
Faisal Vali

1

Acho que a sintaxe é mais limpa e Ruby, pelo menos para mim, é muito mais "agradável" - por mais subjetivo que isso seja!


-1

Duas respostas:

uma. Porque rails foi escrito para ruby.

b. Pela mesma razão, C é mais adequado para Linux do que Ruby


Dado o contexto da pergunta, a resposta não faz absolutamente nenhum sentido.
lorefnon

-6

Tudo isso é TOTALMENTE "IMHO"

Em Ruby existe UMA estrutura de aplicativo da web, portanto, é a única estrutura anunciada para essa linguagem.

Python teve vários desde o início, só para citar alguns: Zope, Twisted, Django, TurboGears (ele mesmo uma mistura de outros componentes do framework), Pylons (uma espécie de clone do framework Rails), e assim por diante. Nenhum deles é suportado em toda a comunidade python como "O que deve ser usado", então todo o "impulso" está espalhado por vários projetos.

Rails tem o tamanho da comunidade somente, ou pelo menos na grande maioria, por causa do Rails.

Tanto Python quanto Ruby são perfeitamente capazes de fazer o trabalho como uma estrutura de aplicativos da web. Use aquele que VOCÊ (e sua equipe de desenvolvimento em potencial) gosta e pelo qual pode se alinhar.


7
ruby tem várias estruturas de aplicativos da web: Nitro, Merb, Camping .. para citar alguns
Corban Brook

5
Adicionar: Sinatra e até mesmo um aplicativo Rack simples para aplicativos web muito rápidos e mínimos também.
Kris

2
-1 "Em Ruby existe UM framework de aplicação web" muito categórico ... para uma declaração falsa. Nitro, Merb, Camping, Sinatra
Maximiliano Guzman

2
Opiniões desinformadas de ambos os lados são exatamente a causa da confusão para os recém-chegados que estão tentando resolver tudo isso. Também significa que alguém pode estar perdendo algo que realmente apreciaria se soubesse melhor.
Walt Jones

3
Eu acho que seu ponto é que Rails tem uma grande participação da comunidade Ruby do que Django tem da comunidade Python, o que é válido
pjb3
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.