Ruby: The Bad Parts [chiuso]

Di recente ho letto il libro di Crockford "Javascript: le parti buone" e una delle premesse sottostanti era che i linguaggi di programmazione possono avere cattive serie di funzionalità che i programmatori dovrebbero evitare.

Sono un Rubyist e mentre adoro la lingua, c'è sempre valore nell'ottenere una prospettiva. Quindi, qual è la caratteristica peggiore (ad esempio metodi, classi, pratiche) in Ruby? La mia intenzione qui non è quella di iniziare una discussione sui meriti della lingua stessa o sulla sua velocità e così via. Preferirei piuttosto una discussione su quali caratteristiche consideri pericolose / problematiche / dolorose da usare, basate su esperienze passate.

Dovresti guardare Python vs Ruby: A Battle to The Death di Gary Bernhardt. Fa la citazione:

Le cose che trovo brutte in Ruby sono ciò che rende possibile un software Ruby sorprendente come RSpec e che Python non avrebbe mai potuto avere (data l'implementazione attuale).

Mentre parla molto di Python in particolare, tocca molte cose strane in Ruby. Uno dei grandi temi generali è il patching delle scimmie .

Gli oggetti Ruby (diversamente dagli oggetti in alcuni altri linguaggi orientati agli oggetti) possono essere modificati individualmente. È sempre possibile aggiungere metodi in base all'oggetto. In Ruby, il comportamento o le capacità di un oggetto possono discostarsi da quelli forniti dalla sua classe.

Mentre questo fornisce molta flessibilità e alimenta alcune delle gemme più popolari e complicate di Ruby, può morderti il ​​culo se stai cercando di eseguire il debug di un problema senza rendersi conto che alcune librerie da qualche parte hanno modificato un metodo di base.

Alcune persone pensano solo al rubino in termini di rubino su rotaie ed è un po 'fastidioso perché la lingua si distingue abbastanza bene da sola.

Penso che la caratteristica peggiore sia quella open classesche ti consente di cambiare globalmente il comportamento di tutte le istanze attuali e future della classe cambiata.

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

In una base di codice di grandi dimensioni ciò può risultare in bug molto, molto difficili da trovare, soprattutto perché questo è aggravato dalla debole storia di debug di Ruby (rispetto ad esempio al CLR o JVM) e l'uso di altre funzionalità (ad esempio eval) in questo contesto può rendere è abbastanza 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" causi il problema! Nella mia esperienza di solito inizi con una caccia all'oca selvatica, poiché i problemi iniziano a emergere su un oggetto usando il vero colpevole.

Quindi la cosa migliore sarebbe, o smettere di usare le classi aperte ( #extende mettere le modifiche in un ModuleIMHO è molto più sicuro, più facile da capire e meglio testare) o se non si può evitare di:

• estendere solo le classi con un nuovo comportamento (ovvero non sovrascrivere il comportamento esistente)
• avere un posto definito nella struttura del codice sorgente, in cui devono essere posizionate tutte le estensioni che utilizzano classi aperte
• non usare #eval e gli amici per creare classi aperte
• mettere tutti gli usi delle classi aperte su un grande grafico visibile, in cui tutti gli sviluppatori possano vederli - e chiarire che eventuali cambiamenti su di essi sono "decisioni architetturali" che interessano l'intera base di codice (cosa che fanno) e non il luogo per trucchi rapidi per il tuo compito attuale

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

Se questo può essere esteso a Ruby on Rails, quindi:

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

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

Per il semplice Ruby la mia lamentela sarebbe la stessa di qualsiasi linguaggio che scambia sicurezza per espressività; è facile fare molto con solo un po 'di codice, ma è altrettanto facile fare un casino enorme 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? Ruby ha la capacità di essere estremamente leggibile o imperscrutabile. Ho visto codice che sembra appartenere a uno script Bash.

Cattive pratiche? Alcuni rubini apprezzano l'intelligenza sulla saggezza. Scrivono e condividono trucchi che mettono in mostra la loro intelligenza, ma questo crea un codice illeggibile e fragile.

A parte questo: Javascript è stato un disastro in base alla progettazione e il libro "Le parti buone" cerca di estrarre la sua bellezza nascosta. Perl, una lingua che ha reso popolare "C'è più di un modo per farlo" (ovvero flessibilità), ha un libro simile in "Perl, Best Practices". La storia di Perl è fatta di sperimentazione ed esperienza duramente vinta, "Best Practices" rappresenta la sua conoscenza. Perl 6 sarà, credo sia giusto dire, un riavvio del linguaggio basato su quella conoscenza e altro ancora. Il rubino può soffrire di problemi simili.

@James e for loop ... Quando esegui un ciclo for in ruby, allora chiama ".each". Pertanto, "for" è lo zucchero sintattico per le persone più a proprio 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 perdere l'abitudine. @andrew ... il rubino eloquente non sostiene i loop.

Questo riguarda più i programmatori che la lingua, ma perché i programmatori di Ruby odiano così 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 farebbe esattamente la stessa cosa.

Ho chiesto più volte e non ho mai avuto una buona risposta a questo.

Se è solo una cosa di stile, sono felice di accettarlo, ma ho visto i programmatori di Ruby molto coinvolti su questo e sono davvero curioso.

Generalmente eviterei cose che sono state aggiunte solo per essere retrocompatibili con altre lingue. Ad esempio, Perlismi e for x in y.