Ci sono attività che richiedono molto meno lavoro con Ruby rispetto a C # 4.0?

Question

Ci sono attività che richiedono molto meno lavoro con Ruby rispetto a C # 4.0?

#1 da (7 voti)

8

Ho appena finito di leggere il capitolo Ruby del libro 7 lingue in 7 settimane . A parte qualche zucchero sintattico qua e là, non riesco davvero a vedere nulla che non possa essere fatto con C # con una sintassi simile. Capisco che entrambe le lingue sono intrinsecamente diverse, ma la mia domanda si riferisce al suo utilizzo piuttosto che al design.

Domande pertinenti mi fanno credere che Ruby offra poco più di C #:

Ho lavorato duramente con Ruby e la mia comprensione della lingua è ancora molto limitata, quindi forse qualcuno che ha sperimentato sia con .NET 4.0 che con Ruby può rispondere con esempi concreti.

Quali attività richiedono molto meno lavoro con Ruby rispetto a C # 4.0?

P.s .: questa domanda è stata chiusa su StackOverflow come troppo soggettiva e argomentativa, sebbene abbia attirato l'attenzione. Speravo che sarebbe stato unito a qui, ma invece dovrò semplicemente ripubblicarlo.

programming-languages c# .net ruby

posta Steven Jeuris 27.04.2011 - 23:50

fonte

1 risposta

Leggi altre domande sui tag programming-languages c# .net ruby

Come progettare al meglio una coda di lavoro con vincoli? Come funzionano le interfacce utente di testo (TUI)?

score 7 · Accepted Answer

Ruby ha letterali per le espressioni regolari e una serie di utili scorciatoie sintattiche per la creazione / interpolazione delle stringhe. Quindi, quando i tuoi compiti sono principalmente legati alla combinazione di bit e pezzi di stringhe corrispondenti, Ruby potrebbe richiedere un lavoro molto meno significativo (ma al di fuori di brevi script di supporto devo ammettere che ho trovato che si tratta di una situazione molto rara).

Più rilevanti sono i servizi di meta-programmazione di Ruby. vale a dire #eval , #define_method e amici, che combinati con open classes , #include e #extend consentono di creare tonnellate di codice boilerplate in fase di esecuzione - si può obiettare che i generatori / maghi di codice forniscono alcuni dei stessi vantaggi, ma devi convivere con le quantità, possibilmente molto elevate, del codice della piastra caldaia generato, rispetto a una quantità relativamente piccola di codice di meta-programmazione che dovresti leggere e capire.

Un tipico caso d'uso per questo è, dovendo interfacciarsi con un qualche tipo di fornitore di dati dinamici al di fuori dell'applicazione. Rails ActiveRecord ne è un buon esempio.

In futuro questo potrebbe essere molto utile per lo sviluppo di GUI, poiché è possibile generare metodi per gestire gli eventi dagli elementi dell'interfaccia utente creando metodi durante il runtime sulla base dell'ID dell'interfaccia utente, del tipo, dei valori di input ecc. (come Objective-C su steroidi, forse vedremo un po 'di questo potere quando MacRuby matura).

Il confine tra il buon uso e l'orribile abuso di questa funzione è molto sottile e tende, dalla mia esperienza, a essere una delle principali cause di mal di testa nei grandi progetti di Ruby (su Rails). Quindi fai attenzione quando decidi di rilasciare il Djinn dalla sua bottiglia:)