Non avrei pubblicato questo come risposta, ma Xeoncross mi ha chiesto di farlo, quindi eccoci qui:
(Sidenote: se qualcuno potesse risolvere il problema del markdown nel piccolo esempio di codice, lo apprezzerei.)
Erik Max Francis ha scritto:
"Brandon J. Van Every" ha scritto:
Cosa c'è di meglio di Ruby di Python? Sono sicuro che c'è qualcosa. Che cos'è? Non avrebbe molto più senso chiedere alla gente di Ruby questo, piuttosto che alla gente di Python?
Potrebbe, o no, a seconda dei propri scopi - ad esempio, se i propri scopi includono uno "studio sociologico" della comunità Python, allora porre domande a quella comunità rischia di rivelarsi più rivelatore di informazioni al riguardo, piuttosto che metterle altrove :-). Personalmente, ho colto volentieri l'occasione di seguire il tutorial di un giorno sul Ruby di Dave Thomas nell'ultimo OSCON. Sotto una sottile patina di differenze di sintassi, trovo Ruby e Python sorprendentemente simili - se stavo calcolando l'albero di spanning minimo tra quasi tutte le lingue, sono abbastanza sicuro che Python e Ruby sarebbero le prime due foglie in cui fondersi un nodo intermedio :-).
Certo, mi stanco, in Ruby, di digitare la "fine" sciocca alla fine di ogni blocco (piuttosto che solo unindenting) - ma poi riesco a evitare di digitare la stessa stupidaggine :
che Python richiede
all'inizio di ogni blocco, quindi è quasi un lavaggio :-). Altre differenze di sintassi come @fooversus
self.foo, o il significato più elevato del caso in Ruby vs Python, sono davvero altrettanto irrilevanti per me.
Altri senza dubbio basano la loro scelta di linguaggi di programmazione proprio su tali questioni e generano i dibattiti più importanti - ma per me questo è solo un esempio di una delle leggi del Parkinson in azione (l'ammontare del dibattito su una questione è inversamente proporzionale alla questione importanza reale). Una differenza di sintassi che trovo importante, e a favore di Python - ma altre persone penseranno senza dubbio al contrario - è "come si chiama una funzione che non accetta parametri". In Python (come in C), per chiamare una funzione applichi sempre l '"operatore di chiamata" - parentesi finali subito dopo l'oggetto che stai chiamando (all'interno di quelle parentesi finali vanno gli argomenti che stai passando nella chiamata - se non passi argomenti, quindi le parentesi sono vuote). Questo lascia la semplice menzione di qualsiasi oggetto, senza operatore coinvolto, poiché significa solo un riferimento all'oggetto - in qualsiasi contesto, senza casi speciali, eccezioni, regole ad hoc e simili. In Ruby (come in Pascal), per chiamare una funzione CON argomenti si passa l'args (normalmente tra parentesi, anche se non è invariabilmente il caso) - MA se la funzione non prende argomenti, semplicemente menzionando implicitamente la funzione la chiama. Questo può soddisfare le aspettative di molte persone (almeno, senza dubbio, quelle la cui unica precedente esperienza di programmazione è stata con Pascal, o altri linguaggi con "chiamate implcit" simili, come Visual Basic) - ma per me significa che il la semplice menzione di un oggetto può ORE significare un riferimento all'oggetto, O una chiamata all'oggetto, a seconda del tipo di oggetto - e nei casi in cui non riesco a ottenere un riferimento all'oggetto semplicemente citandolo, dovrò usare esplicito "dammi un riferimento a questo, NON chiamarlo!" operatori che non sono necessari altrimenti. Sento che ciò influisce sulla "prima classe" di funzioni (o metodi, o altri oggetti richiamabili) e sulla possibilità di scambiare oggetti senza problemi. Pertanto, per me, questa specifica differenza di sintassi è un grave segno nero contro Ruby - ma capisco perché gli altri farebbero diversamente, anche se difficilmente potrei essere in disaccordo con più veemente :-). Sotto la sintassi, entriamo in alcune importanti differenze nella semantica elementare - ad esempio, le stringhe in Ruby sono oggetti mutabili (come in C ++), mentre in Python non sono mutabili (come in Java, o credo C #). Ancora una volta, le persone che giudicano principalmente per ciò che hanno già familiarità possono pensare che questo sia un vantaggio per Ruby (a meno che non abbiano familiarità con Java o C #, ovviamente :-). Io penso che le stringhe immutabili siano un'ottima idea (e non mi sorprende che Java, indipendentemente da me, abbia reinventato quell'idea che era già in Python), anche se non mi dispiacerebbe avere un tipo di "buffer di stringa mutabile" (e idealmente uno con una migliore facilità d'uso rispetto ai "buffer di stringhe" di Java); e non do questo giudizio a causa della familiarità - prima di studiare Java, a parte i linguaggi di programmazione funzionale dove le persone che giudicano principalmente per ciò che hanno già familiarità possono pensare che questo sia un vantaggio per Ruby (a meno che non abbiano familiarità con Java o C #, ovviamente :-). Io penso che le stringhe immutabili siano un'ottima idea (e non mi sorprende che Java, indipendentemente da me, abbia reinventato quell'idea che era già in Python), anche se non mi dispiacerebbe avere un tipo di "buffer di stringa mutabile" (e idealmente uno con una migliore facilità d'uso rispetto ai "buffer di stringhe" di Java); e non do questo giudizio a causa della familiarità - prima di studiare Java, a parte i linguaggi di programmazione funzionale dove le persone che giudicano principalmente per ciò che hanno già familiarità possono pensare che questo sia un vantaggio per Ruby (a meno che non abbiano familiarità con Java o C #, ovviamente :-). Io penso che le stringhe immutabili siano un'ottima idea (e non mi sorprende che Java, indipendentemente da me, abbia reinventato quell'idea che era già in Python), anche se non mi dispiacerebbe avere un tipo di "buffer di stringa mutabile" (e idealmente uno con una migliore facilità d'uso rispetto ai "buffer di stringhe" di Java); e non do questo giudizio a causa della familiarità - prima di studiare Java, a parte i linguaggi di programmazione funzionale dove Penso che le stringhe immutabili siano un'ottima idea (e non mi sorprende che Java, indipendentemente da me, abbia reinventato quell'idea che era già in Python), anche se non mi dispiacerebbe avere un tipo di "buffer di stringa mutabile" (e idealmente uno con una migliore facilità d'uso rispetto ai propri "buffer di stringhe" di Java); e non do questo giudizio a causa della familiarità - prima di studiare Java, a parte i linguaggi di programmazione funzionale dove Penso che le stringhe immutabili siano un'ottima idea (e non mi sorprende che Java, indipendentemente da me, abbia reinventato quell'idea che era già in Python), anche se non mi dispiacerebbe avere un tipo di "buffer di stringa mutabile" (e idealmente uno con una migliore facilità d'uso rispetto ai propri "buffer di stringhe" di Java); e non do questo giudizio a causa della familiarità - prima di studiare Java, a parte i linguaggi di programmazione funzionale dovetutti i dati sono immutabili, tutte le lingue che conoscevo avevano stringhe mutabili - eppure quando ho visto per la prima volta l'idea di stringa immutabile in Java (che ho imparato molto prima di apprendere Python), mi è sembrato subito eccellente, un'ottima soluzione per la semantica di riferimento di un linguaggio di programmazione di livello superiore (al contrario della semantica di valore che si adatta meglio ai linguaggi più vicini alla macchina e più lontani dalle applicazioni, come C) con stringhe come di prima classe, integrate (e piuttosto cruciale) tipo di dati.
Ruby presenta alcuni vantaggi nella semantica elementare, ad esempio la rimozione delle "liste contro le tuple" di Python in modo estremamente sottile. Ma soprattutto il punteggio (come lo conservo, con semplicità un grande vantaggio e sottili, intelligenti distinzioni un notevole meno) è contro Ruby (ad esempio, con intervalli sia chiusi che semiaperti, con le notazioni a..b e a .. .b [qualcuno vuole affermare che è ovvio quale è quale? -)], è sciocco - IMHO, ovviamente!). Ancora una volta, le persone che considerano di avere un sacco di cose simili ma sottilmente diverse nel cuore di una lingua un PLUS, piuttosto che un MINUS, contano ovviamente questi "viceversa" da come li conto :-).
Non farti ingannare da questi confronti nel pensare che le due lingue siano
moltodiverso, intendiamoci. Non lo sono. Ma se mi viene chiesto di confrontare i "capelli d'angelo" con gli "spaghettini", dopo aver sottolineato che questi due tipi di pasta sono praticamente indistinguibili per chiunque e intercambiabili in qualsiasi piatto che potresti voler preparare, avrei inevitabilmente passare all'esame microscopico di come le lunghezze e i diametri differiscano impercettibilmente, come le estremità dei fili siano rastremate in un caso e non nell'altro, e così via - per cercare di spiegare perché io, personalmente, preferirei avere capelli d 'angelo come la pasta in qualsiasi tipo di brodo, ma preferirei gli spaghettini come la pastasciutta per accompagnare salse adatte a forme di pasta così lunghe e sottili (olio d'oliva, aglio tritato, peperoni rossi tritati e acciughe macinate finemente, per esempio - ma se hai affettato aglio e peperoni invece di tritarli, allora dovresti scegliere il corpo più sano degli spaghetti piuttosto che la più sottile evanescenza degli spaghettini, e ti consigliamo di rinunciare all'achoview e aggiungere invece un po 'di basilico fresco di primavera [ o anche - sono un eretico ...! - foglie di menta leggera ...] - all'ultimo momento prima di servire il piatto). Ops, scusa, dimostra che sto viaggiando all'estero e non ho mangiato pasta per un po ', immagino. Ma l'analogia è ancora abbastanza buona! -) e sarebbe bene consigliato di rinunciare alla vista panoramica e aggiungere invece un po 'di basilico fresco di primavera [o anche - sono un eretico ...! - foglie di menta leggera ...] - all'ultimo momento prima di servire il piatto). Ops, scusa, dimostra che sto viaggiando all'estero e non ho mangiato pasta per un po ', immagino. Ma l'analogia è ancora abbastanza buona! -) e sarebbe bene consigliato di rinunciare alla vista panoramica e aggiungere invece un po 'di basilico fresco di primavera [o anche - sono un eretico ...! - foglie di menta leggera ...] - all'ultimo momento prima di servire il piatto). Ops, scusa, dimostra che sto viaggiando all'estero e non ho mangiato pasta per un po ', immagino. Ma l'analogia è ancora abbastanza buona! -)
Quindi, tornando a Python e Ruby, arriviamo ai due biggies (in termini di linguaggio proprio - lasciando le biblioteche e altri importanti accessori come strumenti e ambienti, come incorporare / estendere ogni lingua, ecc., Ecc. Da per ora - non si applicherebbero comunque a tutte le IMPLEMENTAZIONI di ogni lingua, ad esempio, Jython vs Classic Python essendo due implementazioni del linguaggio Python!):
Iteratori e blocchi di codice di Ruby vs iteratori e generatori di Python;
La "dinamica" TOTALE e sfrenata di Ruby, inclusa la possibilità di "riaprire" qualsiasi classe esistente, comprese quelle incorporate, e di modificarne il comportamento in fase di esecuzione - rispetto alla vasta ma limitata
dinamicità di Python , che non cambia mai il comportamento dell'esistente classi integrate e loro istanze.
Personalmente, considero 1 un lavaggio (le differenze sono così profonde che potrei facilmente vedere le persone odiare l'uno o l'altro approccio e riverire l'altro, ma sulla MIA scala personale i vantaggi e gli svantaggi sono quasi pari); e [2] un problema cruciale - uno che rende Ruby molto più adatto per "armeggiare", MA Python è anche più adatto per l'uso in grandi applicazioni di produzione. È divertente, in un certo senso, perché entrambe le lingue sono così MOLTO più dinamiche della maggior parte delle altre, che alla fine la differenza chiave tra loro dal mio POV dovrebbe dipendere da questo - che Ruby "va a undici" a questo proposito (il riferimento ecco "Spinal Tap", ovviamente). In Ruby,POSSO FARLO ! Cioè, posso modificare dinamicamente la classe di stringhe incorporata in modo che
a = "Hello World"
b = "ciao mondo"
se a == b
stampa "uguale! \ n"
altro
stampa "diverso! \ n"
fine
STAMPA "uguale". In Python, NON c'è modo di farlo. Ai fini della metaprogrammazione, dell'implementazione di quadri sperimentali e simili, questa straordinaria abilità dinamica di Ruby è estremamente
attraente. MA - se stiamo parlando di applicazioni di grandi dimensioni, sviluppate da molte persone e gestite da ancora di più, inclusi tutti i tipi di librerie da diverse fonti, e che devono andare in produzione nei siti dei clienti ... beh, non VOGLIO un linguaggio che è abbastanza dinamico, grazie mille. Detesto l'idea stessa di una biblioteca che rompe inconsapevolmente altre non correlate che si basano sul fatto che quelle stringhe sono diverse - è il tipo di "canale" profondo e profondamente nascosto, tra pezzi di codice che GUARDANO separati e DOVREBBERO ESSERE separati, che compongono la morte in programmazione su larga scala. Lasciando che qualsiasi modulo influisca sul comportamento di qualsiasi altro "di nascosto",
Se dovessi usare Ruby per un'applicazione così grande, proverei a fare affidamento su restrizioni in stile codifica, molti test (da ripetere ogni volta che cambia QUALCOSA - anche ciò che dovrebbe essere totalmente indipendente ...), e simili, per vietare l'uso di questa funzione linguistica. Ma NON avere la funzionalità in primo luogo è ancora meglio, secondo me - proprio come Python stesso sarebbe un linguaggio ancora migliore per la programmazione dell'applicazione se un certo numero di built-in potesse essere "inchiodato", quindi SAPEVO che , ad esempio,
len("ciao")è 4 (piuttosto che doversi preoccupare in modo subliminale se qualcuno ha cambiato il legame di nome lennel __builtins__
modulo ...). Spero che alla fine Python "inchioda" i suoi built-in.
Ma il problema è minore, dal momento che il rebinding degli built-in è piuttosto deprecato e una pratica rara in Python. In Ruby, mi sembra importante - proprio come le
macro strutture troppo potenti di altre lingue (come, diciamo, Dylan) presentano rischi simili secondo me (spero che Python non ottenga mai un sistema macro così potente, no importa il fascino di "lasciare che le persone definiscano le loro piccole lingue specifiche del dominio incorporate nella lingua stessa" - IMHO, comprometterebbe la meravigliosa utilità di Python per la programmazione delle applicazioni, presentando un "fastidio attraente" al potenziale armeggiatore che si nasconde nel cuore di ogni programmatore ...).
alex