14 May
Aqui na nossa série de linguagens de programação (sem posts já faz um tempo), já falamos de Ruby, mas ainda não de Python. O ideal seria falar de Python antes mas, graças a uma palestra interessante que assisti online, resolvi fazer alguns comentários e críticas a cada uma delas.
Antes de mais nada, é importante entender quais as bases e as motivações de cada uma dessas duas linguagens. Ambas as linguagens têm como metas permitir código bonito, legível e o mais simples possível. Mas o critério de bonito e legível difere para cada uma delas. De acordo com o Zen do Python (numa tradução livre):
[...]
Casos especiais não são tão especiais para quebrarmos as regras.
[...]
Quando se deparar com uma ambiguidade, não ceda à tentação de tentar adivinhar.
Deveria haver uma, e preferencialmente só uma, maneira óbvia de fazer algo.
[...]
Se a implementação é difícil de explicar, não é uma boa ideia.
[...]
Já o Ruby, de acordo com o próprio criador Yukihiro Matsumoto:
[...] é simples na aparência, mas muito complexo no interior, tal como o corpo humano.
Nota-se que isso contraria a parte da simplicidade de implementação do Zen do Python. E nota-se isso também em bibliotecas famosas escritas em Ruby, como o ActiveRecord, por exemplo. Você já tentou entender a implementação da classe ActiveRecord::Base?
Além disso, Ruby herdou de Perl, uma de suas fontes de inspiração, a ideia de ter várias formas de fazer uma mesma coisa. E também tem alguns casos especiais de sintaxe, como a invocação de um setter (que pode ser com espaço antes do igual, apesar de o nome do setter não ter esse espaço), os parênteses opcionais na invocação de um método ou as chaves opcionais num hash passado como argumento.
Agora, minha opinião
Acho que é bom ter mais de um jeito de fazer a mesma coisa, como o Ruby possibilita. Um jeito só de fazer a mesma coisa, a meu ver, tem a vantagem de facilitar um pouco a leitura do código, graças à uniformidade. Mas, por outro lado, nos comunicamos uns com os outros numa língua que permite expressar uma mesma ideia de muitas formas diferentes, e mesmo assim nos entendemos, não? É claro que às vezes com alguma dificuldade, mas na maioria das vezes por causa da ambiguidade da língua. E liberdade de expressão também é importante em programação!
Por outro lado, as peculiaridades da sintaxe de Ruby não me agradam; acho que tornam a linguagem mais difícil de compreender. Os casos especiais são muitos e, às vezes, deixam o programador confuso quanto à necessidade de chaves, por exemplo.
Uma característica muito importante que a linguagem Ruby deveria ter, mas só Python tem, são argumentos rotulados. Em Ruby, costuma-se utilizar um hash para suprir essa necessidade, o que, convenhamos, não é muito elegante.
Um ponto sobre o qual ainda não tenho uma opinião muito elaborada é sobre a modificação de classes e métodos em tempo de execução. Em Ruby, ela é implícita: se você declarar uma classe com o mesmo nome de uma que já existe, você estará modificando a existente. Em Python, ela é explícita: você só pode modificar a classe existente se você escrever código específico para isso; se você declarar uma classe com o mesmo nome de uma já existente, você está criando outra classe. Por um lado, acho bom deixar explícito que você está modificando uma classe existente. Mas, por outro lado, faz sentido ter duas classes diferentes com o mesmo nome?
E você, qual a sua opinião? Quais são suas críticas a cada uma dessas linguagens?
Posts Relacionados:
Acompanhe-nos por
RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.
Email This Post
5 Responses for "Linguagens de Programação - Python versus Ruby"
Tive uma certa experiencia com o RoR e com o próprio Ruby, de fato tanto o framework quanto a linguagem são bastante versáteis, entretanto vi que nas mãos erradas pode se tornar um verdadeiro pesadelo codificado.
Tem coisas que concordo com Python, mas tem outras que discordo completamente como por exemplo sua idéia por identação, facilita a programação, mas fica dependente a um padrão que é muito fácil de ser quebrado.
Enquanto com Ruby as vezes tenho a impressão de estar programando em uma linguagem esotérica.
O meu ponto vai a favor do Python pela uniformidade e a natureza explícita da linguagem.
Eu trabalhei por 3 anos com RoR e aprendi uma coisa, de nada adianta Ruby conseguir resolver um problema com 1 milhão de soluções sendo que cada programador tem sua lógica de racionício….
O que acaba acontecendo é que em trabalhos em equipe, cada um resolve como “achar” melhor e acaba prejudicando tudo, pois quando se precisa dar manutenção em algo que não foi escrito por você, acaba virando aquele cocha de retalho, falo isso por experiência própria…
Lógico que isso pode acontecer em Python também, mas acredito que em menor escala.
@Samir
Creio que assim como outras linguagens, quanto mais possibilidades é igual a mais bagunças, creio que o ponto chave desta questão seja mais o padrão da própria equipe que a longuagem em si, por exemplo:
Onde estou trabalhando as vezes um dos desenvolvedores me diz uma coisa x que deve ser feita e num outro instante dentro do mesmo projeto o mesmo desenvolvedor diz uma coisa y dizendo que a coisa x que fiz estava errada, de fato isso me deixou um tanto intrigado e creio que seja esse tipo de coisa que acaba gerando um código de má quailidade e possívelmente problemas futuros.
Assim nem adianta a linguagem que vai usar pois sempre vai existir aqueles que conseguem fazer guambiarra em onde ninguém imaginaria (SQL) ou códigos tão difíceis de manter que acaba gerando desistecias (python-gtk).
Meu voto vai pro Python. E uma outra característica notável do Python, além dos argumentos rotulados, é a herança múltipla.
Olá, Dirley
Discordo com você sobre a questão da herança múltipla. Só acho ela legal no caso de classes totalmente abstratas (aka interfaces). E como, em Python e em Ruby não faz muito sentido ter interfaces, não acho legal que haja herança múltipla em Python.
Agora, por que não acho legal? Porque herança significa alto acoplamento. E se você acopla muito sua classe à sua mãe com uma herança, a situação fica muito pior quando você acopla sua classe a diversas outras.
Para reaproveitar comportamento, que é a única utilidade que eu vejo de herança em linguagens como Python (duck typed), composição é melhor: você só fica acoplado à interface da classe que ela utiliza na composição.
Abraços
Leave a reply