Ruby: The Bad Parts [closed]

Dovresti guardare Python vs Ruby: una battaglia per la morte di Gary Bernhardt. Fa la citazione:

The very things I find ugly in Ruby are what make amazing Ruby software like RSpec possible, and that Python could never have (given the current implementation).

Mentre parla molto di Python in particolare, tocca un sacco di cose che sono davvero strane in Ruby. Uno dei grandi argomenti sovraordinati è monkey patching .

Ruby objects (unlike objects in some other object-oriented languages) can be individually modified. You can always add methods on a per object basis. In Ruby, the behavior or capabilities of an object can deviate from those supplied by its class.

Anche se questo fornisce molta flessibilità e potenzia alcune delle gemme più popolari e complicate di Ruby, può morderti nel sedere se stai cercando di eseguire il debug di un problema senza rendertene conto che alcune librerie hanno modificato un metodo core.

Alcune persone pensano solo al ruby in termini di ruby on rails ed è piuttosto fastidioso perché la lingua è abbastanza buona.

Penso che la funzione peggiore sia open classes che consente di modificare globalmente il comportamento di tutte le istanze attuali e future della classe modificata.

La parte problematica di questa funzione è che tali cambiamenti (globali) avvengono durante il runtime quando l'interprete Ruby incontra la definizione, che potrebbe essere lunga dopo aver già istanziato un paio di oggetti che ora cambiano il loro comportamento all'improvviso .

In una base di codice di grandi dimensioni questo può risultare in molto, molto difficile trovare bachi - specialmente se questo è aggravato dalla debolezza di Ruby (rispetto ad esempio alla CLR o JVM) della storia di debug e all'uso di altre caratteristiche (es. eval ) in questo contesto può rendere piuttosto difficile trovare la posizione in cui si è verificato questo cambiamento globale. cioè se hai già raggiunto il punto in cui sospetti che la classe 'giusta' abbia causato il problema! Nella mia esperienza, di solito inizi con una caccia all'oca selvaggia, poiché i problemi iniziano a emergere in un oggetto usando il vero colpevole.

Quindi la cosa migliore sarebbe, o smettere di usare classi aperte ( #extend e mettere le modifiche in una Module è IMHO molto più sicuro, più facile da capire e meglio testare) o se non può essere evitato a:

• estendono le classi solo con un nuovo comportamento (ad esempio non ignorando il comportamento esistente)
• hanno un posto definito nell'albero del codice sorgente, dove tutte le estensioni che usano le classi aperte devono essere posizionate
• non utilizzare #eval e gli amici per creare classi aperte
• metti tutti gli usi delle classi aperte su un grande grafico visibile, dove tutti gli sviluppatori possono vederli - e chiarisci che qualsiasi cambiamento su di essi sono "decisioni architetturali" che riguardano l'intero codice base (che fanno) e non il posto per veloci hack utili per la tua attività attuale

Il più grande motivo per cui non uso Ruby: è più lento di melassa a gennaio al Polo Nord durante un'era glaciale. I linguaggi di benchmarking sono una scienza inesatta, ma Ruby appare drasticamente più lento persino di JavaScript e Python.

Se può essere esteso a Ruby on Rails, allora:

1. Il fatto che la logica del database dia ad ogni singola tabella una chiave primaria auto_increment , incluse le tabelle che non ne hanno bisogno e non dovrebbero averle.

2. Il fatto che le chiavi composte non siano affatto supportate.

Per il semplice Ruby, la mia lamentela sarebbe la stessa di qualsiasi altra lingua che tradisce sicurezza per espressività; è facile fare molto con solo un piccolo codice, ma è altrettanto facile fare un gran casino con qualsiasi quantità di codice.

Ruby abbraccia metaprogrammazione (riflessione, introspezione), programmazione multi-paradigma e dinamismo a un livello non comune. È facile spararsi al piede con potenza e flessibilità.

fastidioso? Rubino ha la capacità di essere estremamente leggibile o inscrutabile. Ho visto codice che sembra appartenere a uno script Bash.

Cattive pratiche? Alcuni Rubyisti apprezzano l'intelligenza rispetto alla saggezza. Scrivono e condividono trucchi che mostrano la loro intelligenza, ma questo crea codice illeggibile e fragile.

Per inciso: Javascript è stato un disastro dal design, e il libro "The Good Parts" cerca di estrarne la bellezza nascosta. Perl, un linguaggio che ha reso popolare "C'è più di un modo per farlo" (cioè la flessibilità), ha un libro simile in "Perl, Best Practices". La storia di Perl è uno di sperimentazione e di esperienza vincente, "Best Practices" rappresenta la sua conoscenza. Perl 6 sarà, penso sia giusto dire, un riavvio del linguaggio basato su quella conoscenza e altro ancora. Ruby potrebbe soffrire di problemi simili.

@James e per loops ... Quando fai un ciclo for in ruby, chiama quindi ".each". Pertanto, "for" è zucchero sintattico per le persone più a suo agio con i loop in stile C. Ma come Rubyist, userai sempre iteratori come .map, .inject, .each_with_object. Non dovrai mai scrivere un ciclo for con qualcosa come "i = 0; i > 6; i ++" in ruby, e così finisci per abbandonare l'abitudine. @Andrea... il rubino eloquente non approva i loop.

Questo è più sui programmatori che sulla lingua, ma perché i programmatori di Ruby odiano tanto i loop?

Mi rendo conto che Ruby ha:

someCollection.each do |item|
   ...
end

ma non l'ho mai visto usato in situazioni in cui un ciclo for non avrebbe fatto esattamente la stessa cosa.

L'ho chiesto più volte e non ho mai ottenuto una buona risposta a questo.

Se è solo una cosa di stile, sono felice di accettarlo, ma ho visto che i programmatori di Ruby si sono davvero entusiasmati e sono davvero curioso.

Eviterei generalmente cose aggiunte solo per essere retrocompatibili con altre lingue. Ad esempio, Perlismi e for x in y .