7

Immagino che tutti abbiano già sentito la notizia di some key developers leaving the Dynamic Languages team a causa di ciò che percepiscono come il supporto calante di Dynamic Languages ​​in Microsoft.Rendere il caso per IronRuby e IronPython

Sono abbastanza appassionato di Python e cerco di usarlo spesso. Quindi, per estensione, mi interessa IronPython e mi piacerebbe vederlo continuare ad evolversi. Sono sicuro che molte persone si sentano allo stesso modo per IronRuby. Ma la cosa che ancora non riesco a capire è perché gli sviluppatori .NET dovrebbero preoccuparsi di IronRuby e IronPython?

Se si dovesse scrivere una lettera a Microsoft chiedendo loro di continuare a supportare e sviluppare il linguaggio DLR e Iron, quali argomenti utilizzeresti?

Se si dovesse convincere il proprio datore di lavoro a impegnare il tempo degli sviluppatori a contribuire alle versioni di IronPython o IronRuby supportate dalla community ancora da realizzare, come si razionalizzerebbe in termini di valore aziendale?

Qui ci sono i pochi interessanti casi di utilizzo che ho potuto venire con, ma se io dove un manager riflettendo la domanda di cui sopra, probabilmente non trovarli che convincente:

  1. scripting embedded lingue in applicazioni più grandi: Un caso d'uso valido, ma sembra uno scenario di nicchia per la maggior parte degli sviluppatori.
  2. Automazione di test e test: Ruby in particolare ha una ricca selezione di strumenti e librerie di prova e sarebbe bello averli utilizzabili in .NET tramite IronRuby. Ma sembra che le librerie .NET equivalenti stiano colmando questa lacuna, come ad esempio SpecFlow e Selenium's WebDriver.
  3. Esecuzione di framework esistenti su Microsoft Stack: Se IronRuby consente a Ruby on Rails di essere eseguito su Windows con IIS e MS SQL, ciò potrebbe incoraggiare gli negozi che sono stati standardizzati nello stack Microsoft ad adottare RoR.

Qualcuno può pensare a qualcosa di meglio?

risposta

5

Quello che hai scritto non v'è ragione e io aggiungerò alcuni più proiettili:

  • Utilizzando la console interattiva per la navigazione veloce/sperimentazione di metodi.
  • Poiché lo sviluppo in IronRuby/IronPython è più veloce, è possibile utilizzarlo per scrivere POC e successivamente implementare l'applicazione reale in C# o qualsiasi altra cosa si stia utilizzando.
  • Implementare i DSL in IronRuby e usarli dalle lingue statiche.
  • Aggiunta di funzionalità dinamiche (console REPL, ad esempio) alle applicazioni di linguaggio statico.
  • Gestalt.
  • Per Rubyists: scrittura di WPF e Silverlight (anche app WP7, potenzialmente) in IronRuby.
+0

Shay, mi è capitato sul tuo blog mentre cercavo la risposta a questa domanda prima di postarla qui, e ho notato che sei un convinto sostenitore di IronRuby. Quindi +1 per avere il tempo di rispondere qui, e un grazie. Sfortunatamente, a giudicare dalla clamorosa impopolarità di questa domanda e dal generale "meh" che sto vedendo online su questo argomento, sembra che debba ancora essere fatto un argomento forte e convincente. Sarebbe bello se qualcuno con il tuo background riuscisse ad articolare una risposta più definitiva. – Mhmmd

+0

Beh, non penso ci sia una "risposta definitiva". Ruby è un linguaggio di programmazione come C# e puoi farne tutto ciò che puoi fare con C# e anche più a volte. Tuttavia, IronRuby è un po 'problematico perché gli sviluppatori di .NET non sono disposti a smettere di usare C#, quindi devi parlare di IronRuby più come strumento che come linguaggio di programmazione completo. Come strumento, penso che i tuoi proiettili più miei abbiano molto senso. E a mio parere, rende uno strumento molto molto potente. –

2

Non sottovaluterei il valore di incorporarne uno in un'applicazione di grandi dimensioni. Ho usato le capacità di meta-programmazione di Ruby per modificare al volo gli interni di un'applicazione in cose di solito di difficile accesso (questo è particolarmente vero per gli eventi: posso facilmente aggiungere un hook esterno temporaneo per generare manualmente un evento per test invece di modificare e ricompilare effettivamente l'origine C#).Questo mi ha permesso di scovare bug e riprodurre più facilmente gli scenari più complicati. Mi ha anche permesso di prototipare vari codici che avrei poi trasformato in un unit test o in nuove classi.

Inoltre, può essere utile per i tester manuali QA. Le attività comuni possono essere incorporate in script automatici che possono essere eseguiti.

0

Lo scripting leggero È una ragione molto convincente per avere linguaggi dinamici e incorporati nel toolkit .Net.

La mia azienda produce software per strumenti scientifici. L'acquisizione e l'analisi dei dati vengono eseguite con lo scripting in un'applicazione framework. Questo ci consente di essere molto reattivi alle diverse esigenze dei nostri clienti.

Stiamo valutando le tecnologie per aggiornare il nostro software in modo da non dover mantenere il nostro linguaggio di scripting. Ho guardato Qt/PyQt ma ho avuto i piedi freddi quando è stato venduto a Nokia. Ho deciso di aspettare per vedere come maturava IronPython. Ho deciso di usare IronPython dopo che .Net4 e C# 4 sono usciti.

Penso che ora ho preso la decisione sbagliata e sto pensando di tornare a Qt/PyQt. Com'è per un motivo convincente?