
A meno di ripensamenti in extremis sembra che il sipario stia per calare su Ruby.NET: dopo aver visto i risultati raggiunti dal “concorrente” IronRuby ( anche grazie all’impiego di DLR ), il principale sviluppatore del progetto avrebbe infatti deciso di unire i suoi sforzi con quelli delle persone che ne seguono lo sviluppo.
L’unico dettaglio che potrebbe far storcere il naso a molti osservatori è il fatto che IronRuby sia, come IronPython, un progetto portato avanti da Microsoft per ampliare il numero di linguaggi supportati dalla sua piattaforma .NET; i sorgenti di IronRuby sono distribuiti con licenza MS-PL.
via | Punto-Informatico
.net, ironruby, linguaggi, microsoft, ruby, ruby.net
Iscriviti alla newsletter gratuita di ossblog.
Sei interessato a promuovere la tua attività su ossblog?
Pubblicità su Blogo.it.
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967
© 2004-2010 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su ossblog contattare la concessionaria esclusiva DadaAd. Il performance advertising è gestito da Simply.com.
Musica in mp3 su Dada, hosting e domini su Register.it, aziende.it



sirus
12 feb 2008 - 15:12 - #1L’ex. project leader di Ruby.NET ha affermato che sarebbe stata necessaria l’introduzione di DLR anche nel suo progetto per poter continuare uno sviluppo agevole.
Ha pensato che fare del lavoro aggiuntivo che qualcuno aveva già fatto (con ottimi risultati considerando che IronRuby è più completo di Ruby.NET) non fosse utile (giustamente) ed ha pensato di unirsi al progetto “concorrente”.
Per il momento IronRuby ha fatto suo il parser di Ruby.NET che a quanto pare era superiore, immagino che ci sarà dell’altro scambio di codice.
iosononessuno
13 feb 2008 - 07:36 - #2certo che .NET ne sta facendo dei danni…
sirus
13 feb 2008 - 08:58 - #3@ iosononessuno
danni?! Ma hai mai provato a programmare utilizzando la piattaforma .NET?!
mr.taki
13 feb 2008 - 10:01 - #4IMHO è meglio così, era inutile disperdere risorse tra due progetti simili e entrambi open source