Perché qualcuno dovrebbe investire tempo in Microsoft "Roslyn"?

37

Ho appena letto alcuni dei white paper e degli esempi di Microsoft "Roslyn" e il concetto sembra molto interessante. Da quello che posso dire, apre la scatola nera che è il compilatore e fornisce un'interfaccia che possiamo usare per ottenere informazioni e metriche sul codice scritto in Visual Studio.

Sembra che Roslyn abbia anche la possibilità di "scrivere" il codice e compilarlo / eseguirlo al volo (simile a CodeDom), ma nella mia esperienza ho riscontrato solo usi limitati per quel tipo di funzionalità.

Mentre l'elemento di analisi del codice e metriche è uno spazio interessante ... è qualcosa che esiste da molto tempo e ci sono numerosi fornitori che hanno già investito molti soldi in strumenti di analisi del codice e refactoring (ad esempio ReSharper, CodeRush , nCover, ecc.) e fanno un ottimo lavoro!

Perché un'azienda dovrebbe fare di tutto per implementare qualcosa che può essere fornito a una frazione del costo acquistando una licenza per uno degli strumenti esistenti?

Forse ho perso alcune funzionalità chiave del progetto Roslyn che lo colloca al di fuori del dominio degli strumenti citati ...

.net visual-studio static-analysis

— Richard Hooper
fonte

4

Il punto principale di Roslyn è il più internato di Microsoft, che rende un compilatore C # gestito facilmente estensibile. In questo modo il team può implementare e provare più facilmente nuove funzionalità linguistiche. Anche l'implementazione di nuovi algoritmi di ottimizzazione diventerà più semplice.

— JustAnotherUserYouMayKnowOrNon

1

Sì Penfold - Sospetto che potresti aver perso alcune cose. Hai visto l'intervista a Dustin Campbells su Channel9? channel9.msdn.com/Events/Ch9Live/…

— James Snell l'

3

Questo è il rischio di sviluppare componenti aggiuntivi di successo / redditizi per i prodotti Microsoft, che potrebbero essere inseriti nella versione successiva.

— JeffO,

10

Inoltre, puoi essere sicuro che i ragazzi dietro ReSharper si stanno bagnando i pensieri della funzionalità aggiuntiva che possono collegare. Sì, hanno scritto un parser / analizzatore C #, ma il costo per funzione diminuirà in modo significativo se possono sfruttare il vero motore MS C #.

— Binary Worrier,

2

Dai un'occhiata agli scriptcs per un uso interessante di Roslyn. github.com/scriptcs/scriptcs

— Ashley Davis,

53

Sembra che Roslyn abbia anche la possibilità di "scrivere" il codice e compilarlo / eseguirlo al volo (simile a CodeDom), ma nella mia esperienza ho riscontrato solo usi limitati per quel tipo di funzionalità.

Compilazione ed esecuzione al volo sono il vantaggio principale di Roslyn. Penso che potresti sottovalutare il vantaggio di questa funzione perché non hai mai riscontrato un caso d'uso nella tua esperienza in cui brilla davvero. E questo ha senso; la necessità di compilazione dinamica è probabilmente una funzionalità di nicchia, ma la sua disponibilità prevede alcune potenti applicazioni che sarebbero molto più difficili senza di essa.

Ecco un paio di esempi in cima alla mia testa in cui la compilazione dinamica sarebbe abbastanza utile. Esistono altri modi per realizzare tutte queste cose, ma Roslyn le rende più facili.

Avere file plug-in che vengono caricati in fase di esecuzione, compilati e inclusi nell'esecuzione dell'applicazione "padre".
Creazione di un DSL che viene quindi tradotto in C # in fase di esecuzione e compilato utilizzando Roslyn.
Creare un'applicazione orientata al programmatore che prende C #, lo analizza, lo traduce, ecc.
Confronto tra due blocchi di codice per le loro differenze dopo la compilazione, al contrario di differenze "di superficie" come lo spazio bianco. Questo è noto come Semantic Diff .

Quindi, per riassumere, potresti non trovare mai un uso per Roslyn, a seconda del software che impieghi a scrivere. Tuttavia, ci sono molti casi d'uso in cui Roslyn porta molto sul tavolo. Nessuno degli strumenti menzionati fornisce questa funzione. Né potevano basarsi sulla loro architettura e scopo.

— RationalGeek
fonte

+1 per diff. Per interesse ecco un link a un prodotto commerciale in fase di sviluppo che utilizza Roslyn per diff semantico. (Divulgazione completa - Non ho alcun legame con loro, ho appena visto il loro prodotto menzionato sul blog di Jon Skeet )

— MarkJ

@RationalGeek - Grazie per gli esempi, non avevo preso in considerazione l'esempio di route DSL => C # ... Posso immaginare alcuni senari in cui ciò sarebbe molto potente nelle applicazioni aziendali. Molti degli altri esempi che ho visto (non solo i tuoi) si sovrappongono moltissimo con gli strumenti di refactoring di cui ho parlato prima. L'altra parte della mia domanda originale era perché qualcuno dovrebbe investire i soldi nello sviluppo di strumenti per eseguire questa analisi quando ce ne sono alcuni eccellenti pre-rollati a una frazione del costo ... ma suppongo che ci sia sempre spazio per un altro (speriamo meglio) set di strumenti! :)

— Richard Hooper,

@Penfold c'è sempre spazio per i nuovi strumenti di sviluppo ... :-)

— RationalGeek,

1

La diff semantica non è solo a scopo di compilazione. Ogni sistema di controllo versione ha bisogno di un diff e la maggior parte usa uno stupido diff. Basta scambiare 2 funzioni e vedere il pasticcio fatto, quando il diff pensa che possa corrispondere ad alcuni (e {.

— MSalters

Eccone uno grande: ricompilazione automatica durante la scrittura di app ASP.NET SENZA dover ricostruire e ridistribuire l'app Web. Annunciato finalmente in ASP.NET vNext, farà letteralmente funzionare in C # lo stesso di un linguaggio di scripting ... tranne per il fatto che è sia dattiloscritto che performante. Vedo questo come l'inizio di questo approccio generale, alla fine si farà strada nelle app rich-client (mobile, desktop) in modo che tu possa cambiare il tuo codice in fase di esecuzione. È molto più facile con le app Web poiché per definizione ogni richiesta è apolide, ma col tempo si farà strada anche in altre architetture di app.

— Marzo

12

Sono sicuro che le aziende che forniscono strumenti (ad es. JetBrains *) sono molto interessate a Roslyn. Microsoft vuole semplificare la realizzazione di strumenti, poiché i buoni strumenti incoraggiano l'uso dell'ecosistema Microsoft.

* Secondo il blog JetBrains ( questa voce ), JetBrians ha annunciato che non utilizzerà Roslyn. Tuttavia, immagino che qualsiasi nuovo concorrente di JetBrains (che non ha una base di codice preesistente su cui lavorare) utilizzerà Roslyn; dà loro un vantaggio.

Domanda 6 in 10 domande, 10 risposte su Roslyn :

6: Quali sono alcuni degli usi pratici di Roslyn? Come mi aiuterà come sviluppatore?

Uno dei primi usi di Roslyn che viene in mente è quello di un motore di regole aziendali. Prima di Roslyn, la valutazione delle macro utente in genere comportava l'implementazione di Visual Basic, Applications Edition (VBA), la chiamata al DLR con espressioni Ruby o il bombardamento al compilatore della riga di comando con codice Visual Basic o C # generato dinamicamente e ottenere il risultato dell'esecuzione quel codice. Questi metodi erano meno che ideali.

Roslyn consentirà facilmente la compilazione dinamica e l'esecuzione di codice C # e (eventualmente) Visual Basic con la funzione Evaluate (), come ha dimostrato l'articolo di Eric Vogel "Utilizzo dell'API di scripting Roslyn in C #". Le macro utente scritte nella stessa lingua dell'applicazione faciliteranno gli sviluppatori nel supportare le macro utente che rappresentano le regole aziendali.

Il refactoring del codice diventa molto più semplice con Roslyn. Prima di Roslyn, gli sviluppatori di strumenti come DevExpress CodeRush e Refactor Pro e JetBrains ReSharper hanno dovuto ricreare gran parte delle operazioni del compilatore come base per i loro prodotti. Con Roslyn, gli sviluppatori di refactoring possono sfruttare direttamente le funzionalità del compilatore esistenti. Posso immaginare l'aspetto dei pacchetti NuGet per installare le singole regole di refactoring quando Roslyn sarà ampiamente disponibile.

— Brian
fonte

4

"Le macro utente scritte nella stessa lingua dell'applicazione faciliteranno gli sviluppatori nel supportare le macro utente che rappresentano le regole aziendali." - Che cosa potrebbe andare storto!

— gbjbaanb,

10

Attendo con impazienza il giorno in cui tutti i compilatori offrono regolarmente Compiler as a Service (CaaS). Dobbiamo smettere di pensare che i compilatori emettono solo codice pre-linker e iniziare a pensare che i compilatori emettono alberi che possono essere trasformati in più destinazioni. Tutti i compilatori dovrebbero avere una funzione per emettere alberi e facoltativamente JSON / XML. L'output può quindi essere trasformato in molti tipi di target come lo stesso linguaggio abbellito, sorgente C, IL, binario IL, Java, Javascript, LLVM, eseguibile PIC e persino codice pre-linker.

Scrivo compilatori per vivere. I miei clienti sono venduti su CaaS perché apre le porte a fantastiche flessibilità, portabilità e analisi.

Sono davvero deluso dal fatto che Microsoft non abbia implementato CaaS molto tempo fa. Ad esempio, avrebbe potuto essere utilizzato come percorso di migrazione da VB6 a qualcos'altro o da .Net a C ++.

— BSalita
fonte

1

La semplice risposta al motivo per cui MSFT sta investendo in Roslyn è che la loro base di codice esistente per il compilatore C # è ora 5 versioni precedenti - 11 anni ormai. È molto tempo che qualsiasi base di codice rimanga gestibile. Inoltre, dal momento che stanno riscrivendo, hanno deciso di investire nel farlo in modo che tutti i suoi interni siano esposti come API.

— John Tasler
fonte