Ruby: The Bad Parts [fechado]

Recentemente, li o livro de Crockford "Javascript: The Good Parts" e uma das premissas subjacentes era que as linguagens de programação podem ter conjuntos de recursos ruins que os programadores devem evitar.

Sou rubiista e, embora adore a linguagem, sempre há valor em obter perspectivas. Então, qual você vê como o pior recurso (por exemplo, métodos, classes, práticas) no Ruby? Minha intenção aqui não é iniciar uma discussão sobre os méritos da própria linguagem ou sua velocidade e assim por diante. Em vez disso, prefiro discutir quais recursos você considera perigosos / problemáticos / penosos de usar, com base em experiências passadas.

Você deve assistir Python vs Ruby: A Battle to the Death de Gary Bernhardt. Ele faz a citação:

As mesmas coisas que acho feias no Ruby são o que torna possível um incrível software Ruby como o RSpec, e que o Python nunca poderia ter (dada a implementação atual).

Enquanto ele fala muito sobre Python em particular, ele aborda muitas coisas estranhas em Ruby. Um dos grandes assuntos abrangentes é o remendo de macacos .

Objetos Ruby (ao contrário de outros idiomas orientados a objetos) podem ser modificados individualmente. Você sempre pode adicionar métodos por objeto. No Ruby, o comportamento ou os recursos de um objeto podem se desviar dos fornecidos por sua classe.

Embora isso ofereça muita flexibilidade e ofereça algumas das gemas mais populares e complicadas do Ruby, ele pode te incomodar se você estiver tentando depurar um problema sem perceber que alguma biblioteca em algum lugar modificou o método principal.

Algumas pessoas só pensam em rubi em termos de rubi nos trilhos e isso é meio irritante porque a linguagem se sustenta muito bem.

Acho que a pior característica é open classesque permite alterar globalmente o comportamento de todas as instâncias atuais e futuras da classe alterada.

A parte problemática desse recurso é que essas alterações (globais) acontecem durante o tempo de execução quando o intérprete Ruby se depara com a definição, o que pode levar muito tempo depois que você já instanciar alguns objetos que agora mudam seu comportamento de repente.

Em uma grande base de código, isso pode resultar em bugs muito, muito difíceis de encontrar - especialmente porque isso é agravado pela fraca história de depuração de Ruby (em comparação, por exemplo, com o CLR ou JVM) e o uso de outros recursos (por exemplo eval) nesse contexto pode tornar é muito difícil encontrar o local em que essa mudança global ocorreu. ou seja, se você já chegou ao ponto em que suspeita que a classe 'certa' está causando o problema! Na minha experiência, você geralmente começa com uma perseguição de ganso selvagem, à medida que os problemas começam a aparecer em um objeto usando o verdadeiro culpado.

Portanto, o melhor seria parar de usar as classes abertas ( #extende colocar as alterações em um ModuleIMHO é muito mais seguro, mais fácil de entender e melhor para testar) ou se não for possível evitar:

• estender apenas classes com novo comportamento (ou seja, não substituindo o comportamento existente)
• ter um local definido na árvore de códigos-fonte, onde todas as extensões que usam classes abertas devem ser colocadas
• não use #evale amigos para criar classes abertas
• coloque todos os usos de classes abertas em um grande gráfico visível, onde todos os desenvolvedores possam vê-las - e deixe claro que quaisquer alterações nelas são 'decisões arquiteturais' que afetam toda a base de código (o que elas fazem) e não o local para hacks rápidos úteis para sua tarefa atual

Maior razão para não usar Ruby: é mais lento que o melaço em janeiro no Pólo Norte durante uma era glacial. Linguagens de benchmarking são uma ciência inexata, mas Ruby parece drasticamente mais lento que o JavaScript e o Python.

Se isso puder ser estendido para Ruby on Rails, então:

1. O fato de a lógica do banco de dados atribuir a cada tabela uma auto_incrementchave primária, incluindo tabelas que não precisam delas e não devem tê-las.

2. O fato de que chaves compostas não são suportadas.

Por Ruby simples, minha queixa seria a mesma de qualquer idioma que troque segurança por expressividade; é fácil fazer muito com apenas um pouco de código, mas é igualmente fácil fazer uma grande bagunça com qualquer quantidade de código.

Ruby adota metaprogramação (reflexão, introspecção), programação multiparadigma e dinamismo em um nível incomum. É fácil dar um tiro no pé com força e flexibilidade.

Problemático? Ruby tem a capacidade de ser extremamente legível ou inescrutável. Eu vi código que parece pertencer a um script Bash.

Más práticas? Alguns rubiistas valorizam a inteligência sobre a sabedoria. Eles escrevem e compartilham truques que mostram sua inteligência, mas isso cria código ilegível e frágil.

Como um aparte: Javascript foi um desastre por design, e o livro "The Good Parts" tenta extrair sua beleza oculta. O Perl, uma linguagem que popularizou "Há mais de uma maneira de fazer" (ou seja, flexibilidade), tem um livro semelhante em "Perl, Best Practices". A história de Perl é de experimentação e experiência conquistada com dificuldade, "Melhores Práticas" representa seu conhecimento. Perl 6 será, acho justo dizer, uma reinicialização da linguagem com base nesse conhecimento e muito mais. Ruby pode sofrer de problemas semelhantes.

@ James e para loops ... Quando você faz um loop for em ruby, ele chama ".each". Portanto, "for" é um açúcar sintático para pessoas mais confortáveis ​​com loops no estilo C. Mas como Rubyist, você vai usar iteradores como .map, .inject, .each_with_object, o tempo todo. Você nunca precisará escrever um loop for com algo como "i = 0; i> 6; i ++" em ruby, e assim acabará abandonando o hábito. @andrew ... rubi eloquente não apoia loops.

Isso é mais sobre os programadores do que sobre a linguagem, mas por que os programadores Ruby odeiam tanto os loops?

Eu percebo que Ruby tem:

someCollection.each do |item|
   ...
end

mas nunca vi isso usado em situações em que um loop for não faria exatamente a mesma coisa.

Eu perguntei várias vezes e nunca recebi uma boa resposta para esta.

Se é apenas uma coisa de estilo, fico feliz em aceitar isso, mas vi os programadores Ruby realmente se preocupando com isso e estou muito curioso.

Eu geralmente evitava coisas que eram adicionadas apenas para serem compatíveis com outros idiomas. Por exemplo, Perlismos e for x in y.