Eu não publicaria isso como resposta, mas o Xeoncross me pediu, então aqui vamos nós:
(Nota: se alguém pudesse corrigir o problema de remarcação no pequeno exemplo de código, eu agradeceria.)
Erik Max Francis escreveu:
"Brandon J. Van Every" escreveu:
O que há de melhor no Ruby que no Python? Tenho certeza de que há algo. O que é isso? Não faria muito mais sentido perguntar isso às pessoas Ruby do que às pessoas Python?
Talvez, ou não, dependendo dos propósitos de alguém - por exemplo, se os propósitos de alguém incluem um "estudo sociológico" da comunidade Python, então, fazer perguntas a essa comunidade provavelmente será mais revelador de informações sobre ele do que colocá-las em outros lugares. :-). Pessoalmente, aproveitei a oportunidade para acompanhar o tutorial de um dia sobre o Ruby de Dave Thomas, finalmente no OSCON. Abaixo de um fino verniz de diferenças de sintaxe, acho Ruby e Python incrivelmente semelhantes - se eu estivesse computando a árvore de abrangência mínima entre praticamente qualquer conjunto de idiomas, tenho certeza de que Python e Ruby seriam as duas primeiras folhas a se unir um nó intermediário :-).
Certamente, em Ruby, eu me canso de digitar o "final" bobo no final de cada bloco (em vez de apenas desinteressante) - mas evito digitar o igualmente bobo :
que o Python exige no
início de cada bloco, então isso é quase uma lavagem :-). Outras diferenças de sintaxe, como @fooversus
self.foo, ou o significado mais alto de maiúsculas e minúsculas em Ruby vs Python, são realmente tão irrelevantes para mim.
Outros, sem dúvida, baseiam sua escolha de linguagens de programação nessas questões e geram os debates mais quentes - mas para mim esse é apenas um exemplo de uma das Leis de Parkinson em ação (o valor do debate sobre um assunto é inversamente proporcional ao da questão). importância real). Uma diferença de sintaxe que eu acho importante, e a favor do Python - mas outras pessoas, sem dúvida, pensarão exatamente o contrário - é "como você chama uma função que não requer parâmetros". No Python (como em C), para chamar uma função, você sempre aplica o "operador de chamada" - parênteses finais logo após o objeto que você está chamando (dentro desses parênteses finais estão os argumentos que você está passando na chamada - se você não está passando argumentos, então os parênteses estão vazios). Isso deixa a mera menção de qualquer objeto, sem operador envolvido, como significando apenas uma referência ao objeto - em qualquer contexto, sem casos especiais, exceções, regras ad-hoc e similares. Em Ruby (como em Pascal), para chamar uma função WITH argumentos, você passa os argumentos (normalmente entre parênteses, embora esse não seja sempre o caso) - MAS, se a função não aceita argumentos, basta mencionar a função que a chama implicitamente. Isso pode atender às expectativas de muitas pessoas (pelo menos, sem dúvida, aquelas cuja única experiência anterior de programação foi com Pascal, ou outras linguagens com "chamadas implícitas" semelhantes, como o Visual Basic) - mas para mim, isso significa que mera menção de um objeto pode significar uma referência ao objeto, OU uma chamada ao objeto, dependendo do tipo de objeto - e nos casos em que não consigo obter uma referência ao objeto, basta mencioná-lo, precisarei usar explícito "dê-me uma referência a isso, NÃO a chame!" operadores que não são necessários de outra forma. Eu sinto que isso afeta a "primeira classe" de funções (ou métodos ou outros objetos que podem ser chamados) e a possibilidade de trocar objetos sem problemas. Portanto, para mim, essa diferença de sintaxe específica é uma séria marca negra contra Ruby - mas eu entendo por que os outros agiriam de outra maneira, mesmo que eu mal pudesse discordar mais veementemente deles :-). Abaixo da sintaxe, encontramos algumas diferenças importantes na semântica elementar - por exemplo, as strings no Ruby são objetos mutáveis (como no C ++), enquanto em Python eles não são mutáveis (como em Java, ou eu acredito em C #). Novamente, as pessoas que julgam principalmente pelo que já estão familiarizadas podem pensar que isso é uma vantagem para o Ruby (a menos que estejam familiarizadas com Java ou C #, é claro :-). Eu, acho que seqüências imutáveis são uma excelente ideia (e não estou surpreso que o Java, de forma independente, tenha reinventado a ideia que já estava em Python), embora eu não me importe em ter um tipo de "buffer de sequência mutável" também (e, idealmente, um com melhor facilidade de uso do que os próprios "buffers de string" do Java); e não julgo por causa da familiaridade - antes de estudar Java, além das linguagens de programação funcionais em que as pessoas que julgam principalmente pelo que já estão familiarizadas podem pensar que isso é uma vantagem para o Ruby (a menos que estejam familiarizadas com Java ou C #, é claro :-). Eu, acho que seqüências imutáveis são uma excelente ideia (e não estou surpreso que o Java, de forma independente, tenha reinventado a ideia que já estava em Python), embora eu não me importe em ter um tipo de "buffer de sequência mutável" também (e, idealmente, um com melhor facilidade de uso do que os próprios "buffers de string" do Java); e não julgo por causa da familiaridade - antes de estudar Java, além das linguagens de programação funcionais em que as pessoas que julgam principalmente pelo que já estão familiarizadas podem pensar que isso é uma vantagem para o Ruby (a menos que estejam familiarizadas com Java ou C #, é claro :-). Eu, acho que seqüências imutáveis são uma excelente ideia (e não estou surpreso que o Java, de forma independente, tenha reinventado a ideia que já estava em Python), embora eu não me importe em ter um tipo de "buffer de sequência mutável" também (e, idealmente, um com melhor facilidade de uso do que os próprios "buffers de string" do Java); e não julgo por causa da familiaridade - antes de estudar Java, além das linguagens de programação funcionais em que Eu acho que strings imutáveis são uma excelente ideia (e não estou surpreso que o Java, de forma independente, tenha reinventado a ideia que já estava em Python), embora eu não me importe em ter um tipo de "buffer de string mutável" (e idealmente, com melhor facilidade de uso do que os próprios "buffers de string" do Java); e não julgo por causa da familiaridade - antes de estudar Java, além das linguagens de programação funcionais em que Eu acho que strings imutáveis são uma excelente ideia (e não estou surpreso que o Java, de forma independente, tenha reinventado a ideia que já estava em Python), embora eu não me importe em ter um tipo de "buffer de string mutável" (e idealmente, com melhor facilidade de uso do que os próprios "buffers de string" do Java); e não julgo por causa da familiaridade - antes de estudar Java, além das linguagens de programação funcionais em quetodos os dados são imutáveis, todas as linguagens que eu conhecia tinham seqüências de caracteres mutáveis - mas, quando vi pela primeira vez a idéia de sequência imutável em Java (que aprendi muito antes de aprender Python), ela imediatamente me pareceu excelente, uma boa opção para a semântica de referência de uma linguagem de programação de nível superior (em oposição à semântica de valores que se encaixa melhor com linguagens mais próximas da máquina e mais distantes dos aplicativos, como C), com strings como primeira classe, embutida (e bastante crucial) tipo de dados.
O Ruby tem algumas vantagens na semântica elementar - por exemplo, a remoção da distinção "sutil versus simples" do Python. Mas, principalmente, o placar (como eu o mantenho, com simplicidade, uma grande diferença sutil e inteligente, um notável menos) é contra Ruby (por exemplo, tendo intervalos fechados e semiabertos, com as anotações a..b e a .. .b [alguém quer afirmar que é óbvio qual é qual? -)], é bobagem - IMHO, é claro!). Mais uma vez, as pessoas que consideram ter muitas coisas semelhantes, mas sutilmente diferentes, no núcleo de uma linguagem, um PLUS, em vez de um MINUS, obviamente contará essas coisas "ao contrário" da maneira como as conto :-).
Não se deixe enganar por essas comparações, pensando que as duas línguas são
muitodiferente, lembre-se. Eles não são. Mas se me pedirem para comparar "capelli d'angelo" com "spaghettini", depois de apontar que esses dois tipos de macarrão são praticamente indistinguíveis para qualquer pessoa e intercambiáveis em qualquer prato que você queira preparar, eu inevitavelmente teria para examinar microscopicamente como os comprimentos e diâmetros diferem imperceptivelmente, como as extremidades dos fios são afuniladas em um caso e não no outro, e assim por diante - para tentar explicar por que eu, pessoalmente, preferiria capilar. «angelo como a massa em qualquer tipo de caldo, mas preferiria o espaguete à massa, com molhos adequados para formas tão longas e finas (azeite, alho picado, pimentão picado e anchovas finamente moídas, por exemplo - mas se você cortou o alho e o pimentão em vez de picá-los, deve escolher o corpo mais saudável do espaguete em vez da mais fina evanescência do espaguete, e é recomendável renunciar à achoview e adicionar um pouco de manjericão fresco [ ou até - eu sou um herege ...! - folhas de hortelã leve ...] - no último momento antes de servir o prato). Opa, desculpe, isso mostra que estou viajando para o exterior e não tenho macarrão há um tempo, eu acho. Mas a analogia ainda é muito boa! -) e seria aconselhável renunciar à achoview e adicionar um pouco de manjericão fresco da primavera [ou até mesmo - eu sou um herege ...! - folhas de hortelã leve ...] - no último momento antes de servir o prato). Opa, desculpe, isso mostra que estou viajando para o exterior e não tenho macarrão há um tempo, eu acho. Mas a analogia ainda é muito boa! -) e seria aconselhável renunciar à achoview e adicionar um pouco de manjericão fresco da primavera [ou até mesmo - eu sou um herege ...! - folhas de hortelã leve ...] - no último momento antes de servir o prato). Opa, desculpe, isso mostra que estou viajando para o exterior e não tenho macarrão há um tempo, eu acho. Mas a analogia ainda é muito boa! -)
Então, voltando ao Python e Ruby, chegamos às duas coisas mais importantes (em termos de linguagem propriamente dita - deixando as bibliotecas e outros acessórios importantes, como ferramentas e ambientes, como incorporar / estender cada linguagem etc., etc.) por enquanto - eles não se aplicariam a todas as IMPLEMENTAÇÕES de cada idioma, por exemplo, Jython vs Classic Python sendo duas implementações da linguagem Python!):
Iteradores e blocos de código do Ruby versus iteradores e geradores do Python;
TOTAL do Ruby, "dinâmica" desenfreada, incluindo a capacidade de "reabrir" qualquer classe existente, incluindo todas as incorporadas, e alterar seu comportamento em tempo de execução - versus a vasta mas limitada
dinamicidade do Python , que nunca muda o comportamento da existente classes internas e suas instâncias.
Pessoalmente, considero 1 uma lavagem (as diferenças são tão profundas que eu poderia facilmente ver as pessoas odiando qualquer abordagem e reverenciando a outra, mas no meu escalas pessoais os prós e contras apenas sobre mesmo para cima); e [2] uma questão crucial - que torna Ruby muito mais adequado para "mexer", MAS o Python é igualmente mais adequado para uso em grandes aplicações de produção. É engraçado, de certa forma, porque os dois idiomas são MUITO mais dinâmicos que a maioria dos outros, que no final a principal diferença entre eles do meu ponto de vista deve depender disso - que Ruby "chega às onze" a esse respeito (a referência aqui é para "Spinal Tap", é claro). Em Ruby,EU POSSO FAZER ISSO ! Ou seja, eu posso alterar dinamicamente a classe de string incorporada para que
a = "Olá mundo"
b = "olá mundo"
se a == b
imprima "igual! \ n"
outro
imprima "diferente! \ n"
fim
VAI imprimir "igual". Em python, não há como eu fazer isso. Para fins de metaprogramação, implementação de estruturas experimentais e similares, essa incrível capacidade dinâmica do Ruby é extremamente
atraente. MAS - se estamos falando de aplicativos grandes, desenvolvidos por muitas pessoas e mantidos por ainda mais, incluindo todos os tipos de bibliotecas de diversas fontes, e precisando entrar em produção nos sites dos clientes ... bem, eu NÃO QUERO um idioma MUITO dinâmico, muito obrigado. Eu detesto a própria idéia de uma biblioteca involuntariamente quebrar outras não relacionadas que dependem dessas seqüências de caracteres - esse é o tipo de "canal" profundo e profundamente oculto, entre pedaços de código que parecem separados e DEVEM estar separados, que significa morte em programação em larga escala. Ao permitir que qualquer módulo afete o comportamento de qualquer outro "secretamente",
Se eu tivesse que usar o Ruby para um aplicativo tão grande, tentaria confiar em restrições no estilo de codificação, em muitos testes (para ser executado novamente sempre que ALGUMA COISA mudar - mesmo o que não deve ser totalmente relacionado ...), e assim por diante, proibir o uso desse recurso de idioma. Mas NÃO ter o recurso em primeiro lugar é ainda melhor, na minha opinião - assim como o próprio Python seria uma linguagem ainda melhor para a programação de aplicativos se um certo número de built-ins pudesse ser "pregado", então eu sabia que , por exemplo,
len("ciao")é 4 (em vez de precisar se preocupar subliminarmente se alguém alterou a ligação do nome lenno __builtins__
módulo ...). Espero que, eventualmente, o Python "prenda" seus built-ins.
Mas o problema é pequeno, uma vez que a religação de embutidos é uma prática bastante obsoleta e rara em Python. Em Ruby, isso me parece importante - assim como as
facilidades macro muito poderosas de outras linguagens (como, por exemplo, Dylan), apresentam riscos semelhantes em minha opinião (espero que o Python nunca consiga um sistema macro tão poderoso, não importa o fascínio de "deixar as pessoas definirem suas próprias pequenas linguagens específicas de domínio incorporadas na própria linguagem" - isso IMHO prejudicaria a maravilhosa utilidade do Python para programação de aplicativos, apresentando um "incômodo atraente" para o aspirante a analista que espreita no coração de todo programador ...).
Alex