2009-02-23 10 views
7

Sto dando una serie di discorsi a un team di sviluppo .NET (C#) sul linguaggio e sull'ambiente Ruby. Mi sto avvicinando come un'opportunità per evidenziare i benefici di Ruby su C#. All'inizio, voglio concentrarmi sul linguaggio stesso prima di trasferirmi nell'ambiente (RoR vs ASP MVC, ecc.). Quali caratteristiche del linguaggio Ruby vuoi coprire?Quali caratteristiche linguistiche di Ruby metteresti in evidenza rispetto a C#?

+0

La cultura di SO è tale che non ci piacciono le guerre linguistiche. "Benefici di Ruby over C#" è suscettibile di far funzionare alcune persone. Suggerisco una modifica per essere un po 'meno soggettiva e polemica. –

+0

Non sto cercando di iniziare una guerra linguistica, tuttavia voglio ottenere varie risposte su ciò che rende una lingua (ruby) diversa da un'altra (C#). – jsmorris

risposta

1

Mix-in e ereditarietà multipla.

È pericoloso nelle mani sbagliate, ma molto utile per il corretto incapsulamento delle cose, al contrario di dover ereditare molte cose di cui non è necessariamente necessario.

+2

Né C# né ruby ​​hanno un'ereditarietà multipla ... –

5

Duck Typing! Questo sarà meno un problema in C# 4.0, ma ci sono state volte in cui ho dovuto duplicare interi blocchi di codice perché due classi correlate con (per i miei scopi) API identiche non condividevano una classe base.

Inoltre, blocchi. C# ha lambda, ma la sintassi di Ruby è più carina e vengono usati in modo pervasivo in tutte le librerie standard. Sono molto più una parte del Ruby idiomatico che del c idiomatico, e ciò conta qualcosa.

Modifica
letterali Hash meritano una menzione, anche. In generale, sottolineo quanto tu possa essere conciso in Ruby, e come questo ti permetta di esprimere meglio l'intento e dedicare meno tempo a cercare di rendere felice il compilatore

+0

+1 per la digitazione di anatra statica, come nei vincoli di membro – MichaelGG

+0

+1 per i blocchi. È una potente funzionalità di Ruby. –

11

Ho parlato un gruppo di utenti .NET qualche tempo fa su IronRuby, e ha affrontato problemi simili. Le cose su cui mi sono concentrato sono:

  • Anatra digitando. Non c'è niente di più stupido di List<string> stringList = new List<string>();

  • Sintassi espressiva e concisa. Cose semplici come lasciare parentesi, letterali di array e hash, ecc. (Combinate con la digitazione anatra, si ottiene string_list = [] che è ovviamente più bello). Tutte le piccole cose che si sommano in grande stile.

  • Metaprogramming. A partire da cose semplici come attr_accessor, quindi forse qualcosa di un po 'più avanzato se non ne vedono immediatamente i benefici. Non cercare di confrontare le cose con le parole e le sciocchezze sui programmi che scrivono altri programmi ... le persone penseranno che stai fumando qualcosa. Soggiorno semplice e martello a casa il punto che non devi continuare a scrivere lo stesso codice boilerplate merda più

  • Da buon "finale", mostrare loro alcuni normali prove di stile NUnit con tutto il casino di Assert.NotEqual<string> blah che di solito hanno, quindi dicono "ecco lo stesso codice scritto in ruby" e mostrano loro scritto usando rspec (sarà la metà della lunghezza e 10 volte più facile da leggere ... se questo non li vende, niente lo farà).

+0

Non c'è niente di più stupido di List stringList = new List (); <- Non è la digitazione anatra, è un'inferenza di tipo. – MichaelGG

+0

Voglio dire, spostarsi è inferenza, cioè (var x = nuova lista ()). E +1 per più letterali e metaprogrammazione. – MichaelGG

+0

L'inferenza di tipo sicuro è ottima, ma è ancora limitata alle variabili locali. Ho molte definizioni di classe che contengono l'elenco m_strings = new List () che non sembra che stiano andando via in qualsiasi momento presto :-( –

5

mi sto avvicinando come un'opportunità per evidenziare i vantaggi di Rubino su C#.

Non sono sicuro che questa sia la cosa giusta da fare. Se il tono dei tuoi discorsi è: "Ruby è bello perché puoi fare x!" perderai il tuo pubblico C# molto rapidamente.Risponderanno, "Possiamo simulare x in C# se vogliamo, ma non abbiamo molto uso per x nei nostri progetti." o forse, "Se pensi di aver bisogno di fare x allora stai sbagliando!"

Non capiranno come Ruby può aiutarli finché non comprendono Ruby. Perché non affrontarli con problemi di giocattoli e mostrare loro come un programmatore Ruby li risolverebbe? Insegna loro la via Ruby. Una settimana dopo, quando stanno osservando un problema che stanno avendo, uno di loro dirà "Beh, beh, so come risolvere questo problema, ma se stavo usando Ruby sarebbe molto più facile ... ."

1

In aggiunta a ciò che tutti gli altri hanno detto, lezioni aperte è una caratteristica importante di Ruby che vale la pena menzionare: (esempio rubato da Ruby From Other Languages)

class Fixnum 
    def hours 
    self * 3600 # number of seconds in an hour 
    end 
    alias hour hours 
end 

# 14 hours from 00:00 January 1st 
# (aka when you finally wake up ;) 
Time.mktime(2006, 01, 01) + 14.hours # => Sun Jan 01 14:00:00 

Lo so, patching like a monkey should be avoided, ma penso che mettere in evidenza questa caratteristica per i nuovi arrivati ​​dovrebbe dare loro un'idea della filosofia alla base di Ruby. Ricordati di dire: "Bambini, non provatelo a casa!"

+0

hmmm, un po 'equivalente ai metodi di estensione di C# (ma potrebbe essere diverso nei dettagli di implementazione) – niceman

Problemi correlati