Mengapa ada orang yang menginvestasikan waktu di Microsoft "Roslyn"?

37

Saya baru saja membaca beberapa buku putih & contoh dari Microsoft "Roslyn" dan konsepnya tampak sangat menarik. Dari apa yang saya tahu, itu membuka kotak hitam yang merupakan kompiler dan menyediakan antarmuka yang dapat kita gunakan untuk mendapatkan informasi dan metrik tentang kode yang ditulis dalam Visual Studio.

Roslyn juga tampaknya memiliki kemampuan untuk "skrip" kode dan mengkompilasi / menjalankannya dengan cepat (mirip dengan CodeDom) tetapi saya hanya menemukan penggunaan terbatas untuk jenis fungsionalitas dalam pengalaman saya.

Sementara analisis kode & elemen metrik adalah ruang yang menarik ... ini adalah sesuatu yang telah ada sejak lama dan ada banyak penyedia yang telah menginvestasikan banyak uang ke dalam analisis kode & alat refactoring (mis. ReSharper, CodeRush , nCover, dll) dan mereka melakukan pekerjaan yang cukup bagus!

Mengapa ada perusahaan yang berupaya menerapkan sesuatu yang dapat disediakan dengan biaya yang sangat murah dengan membeli lisensi untuk salah satu alat yang ada?

Mungkin saya telah melewatkan beberapa fungsi kunci dari proyek Roslyn yang menempatkannya di luar domain alat yang disebutkan ...

.net visual-studio static-analysis

— Richard Hooper
sumber

4

Poin utama Roslyn adalah lebih banyak Microsoft intern - membuat kompiler C # mudah dikelola yang dapat diperluas. Dengan cara ini tim dapat lebih mudah mengimplementasikan dan mencoba fitur bahasa baru. Juga menerapkan algoritma optimasi baru akan menjadi lebih mudah.

— JustAnotherUserYouMayKnowOrNot

1

Ya Penfold - Saya menduga Anda mungkin melewatkan beberapa hal. Pernahkah Anda menonton wawancara Dustin Campbells di Channel9? channel9.msdn.com/Events/Ch9Live/…

— James Snell

3

Ini adalah risiko pengembangan add-ons yang sukses / menguntungkan untuk produk Microsoft, mereka mungkin memasukkannya ke versi berikutnya.

— JeffO

10

Juga, Anda dapat yakin orang-orang di belakang ReSharper membasahi diri mereka sendiri di pikiran fungsionalitas tambahan yang mereka dapat tancapkan. Ya, mereka telah menulis parser / analyzer C #, tetapi biaya per fitur akan turun secara signifikan jika mereka dapat memanfaatkan mesin MS C # yang sebenarnya.

— Binary Worrier

2

Lihat skrip untuk penggunaan Roslyn yang menarik. github.com/scriptcs/scriptcs

— Ashley Davis

53

Roslyn juga tampaknya memiliki kemampuan untuk "skrip" kode dan mengkompilasi / menjalankannya dengan cepat (mirip dengan CodeDom) tetapi saya hanya menemukan penggunaan terbatas untuk jenis fungsionalitas dalam pengalaman saya.

Kompilasi dan eksekusi on-the-fly adalah manfaat utama Roslyn. Saya pikir Anda mungkin meremehkan manfaat fitur ini karena Anda belum pernah menemukan kasus penggunaan dalam pengalaman Anda di mana itu benar-benar bersinar. Dan ini masuk akal; kebutuhan akan kompilasi dinamis mungkin merupakan fitur khusus, tetapi memiliki kompilasi yang menyediakan beberapa aplikasi canggih yang akan jauh lebih sulit tanpanya.

Berikut adalah beberapa contoh dari atas kepala saya di mana kompilasi dinamis akan sangat berguna. Ada beberapa cara lain untuk mencapai semua ini, tetapi Roslyn membuatnya lebih mudah.

Memiliki file plugin yang dimuat saat runtime, dikompilasi, dan dimasukkan dalam eksekusi aplikasi "induk".
Membuat DSL yang kemudian diterjemahkan ke C # saat runtime dan dikompilasi menggunakan Roslyn.
Membuat aplikasi berorientasi programmer yang mengambil C #, menganalisisnya, menerjemahkannya, dll.
Membandingkan dua potongan kode untuk perbedaan mereka setelah kompilasi, bukan hanya perbedaan "permukaan" seperti spasi putih. Ini dikenal sebagai Semantic Diff .

Jadi, singkatnya, Anda mungkin tidak pernah menemukan penggunaan untuk Roslyn, tergantung pada perangkat lunak apa yang Anda habiskan untuk menulis. Namun, ada banyak kasus penggunaan di mana Roslyn membawa banyak hal. Tidak ada alat yang Anda sebutkan menyediakan fitur ini. Mereka juga tidak bisa berdasarkan pada arsitektur dan tujuan mereka.

— RasionalGeek
sumber

+1 untuk sematic diff. Yang menarik, di sini ada tautan ke produk komersial yang sedang dikembangkan yang menggunakan Roslyn untuk perbedaan semantik. (Pengungkapan penuh - Saya tidak memiliki koneksi dengan mereka, saya hanya melihat produk mereka disebutkan di blog Jon Skeet )

— MarkJ

@RationalGeek - Terima kasih untuk contohnya, saya belum mempertimbangkan DSL => contoh rute C # ... Saya bisa membayangkan beberapa senarios di mana itu akan sangat kuat dalam aplikasi bisnis. Banyak contoh lain yang telah saya lihat (bukan hanya milik Anda) sangat tumpang tindih dengan alat refactoring yang saya sebutkan sebelumnya. Bagian lain dari pertanyaan awal saya adalah mengapa seseorang menginvestasikan uangnya dalam mengembangkan alat untuk melakukan analisis ini ketika ada beberapa yang sangat baik yang sudah digulung sebelumnya dengan biaya yang sangat kecil ... tapi saya kira selalu ada ruang untuk yang lain (semoga ada lebih baik) set alat! :)

— Richard Hooper

@Penfold selalu ada ruang untuk alat pengembang baru ... :-)

— RationalGeek

1

Perbedaan semantik bukan hanya untuk tujuan kompilasi. Setiap Sistem Kontrol Versi membutuhkan diff, dan sebagian besar menggunakan diff bodoh. Hanya menukar 2 fungsi dan melihat kekacauan yang dibuat, ketika diff berpikir itu bisa cocok dengan beberapa (dan {.

— MSalters

Inilah yang besar: kompilasi ulang otomatis ketika menulis aplikasi ASP.NET TANPA harus membangun kembali & memindahkan kembali aplikasi web. Akhirnya diumumkan dalam ASP.NET vNext, itu benar-benar akan membuat bekerja di C # sama dengan bahasa scripting ... kecuali itu kedua typesafe DAN pemain. Saya melihat ini sebagai awal dari pendekatan umum ini, pada akhirnya akan masuk ke aplikasi klien kaya (seluler, desktop) sehingga Anda dapat mengubah kode saat runtime. Ini jauh lebih mudah dengan aplikasi web karena menurut definisi setiap permintaan tidak memiliki kewarganegaraan - tetapi pada waktunya itu akan masuk ke arsitektur aplikasi lain juga.

— Marchy

12

Saya yakin perusahaan yang menyediakan perkakas (mis., JetBrains *) sangat tertarik pada Roslyn. Microsoft ingin membuatnya mudah untuk membuat perkakas, karena perkakas yang baik mendorong penggunaan ekosistem Microsoft.

* Per blog JetBrains ( entri ini ), JetBrians telah mengumumkan bahwa mereka tidak akan menggunakan Roslyn. Namun, saya membayangkan bahwa setiap pesaing baru untuk JetBrains (yang tidak memiliki basis kode yang sudah ada untuk bekerja) akan menggunakan Roslyn; itu memberi mereka awal.

Pertanyaan 6 dalam 10 Pertanyaan, 10 Jawaban tentang Roslyn :

6: Apa kegunaan praktis untuk Roslyn? Bagaimana ini membantu saya sebagai pengembang?

Salah satu kegunaan pertama Roslyn yang muncul di benak saya adalah mesin aturan bisnis. Sebelum Roslyn, mengevaluasi makro pengguna biasanya melibatkan penerapan Visual Basic for Applications (VBA), memanggil DLR dengan ekspresi Ruby, atau keluar ke kompiler baris perintah dengan Visual Basic atau kode C # yang dihasilkan secara dinamis dan mendapatkan hasil menjalankan kode itu. Metode-metode ini kurang ideal.

Roslyn akan dengan mudah mengizinkan kompilasi dinamis dan eksekusi kode C # dan (akhirnya) Visual Basic dengan fungsi Evaluate (), seperti yang ditunjukkan artikel Eric Vogel "Menggunakan API Roslyn Scripting di C #". Makro pengguna yang ditulis dalam bahasa yang sama dengan aplikasi akan memudahkan pengembang untuk mendukung makro pengguna yang mewakili aturan bisnis.

Refactoring kode menjadi lebih mudah dengan Roslyn. Sebelum Roslyn, pengembang alat seperti DevExpress CodeRush dan Refactor Pro dan JetBrains ReSharper harus membuat ulang banyak operasi kompiler sebagai dasar untuk produk mereka. Dengan Roslyn, pengembang refactoring dapat langsung memanfaatkan kapabilitas kompiler yang ada. Saya bisa membayangkan kemunculan paket-paket NuGet untuk menginstal aturan refactoring individual begitu Roslyn tersedia secara luas.

— Brian
sumber

4

"Makro pengguna yang ditulis dalam bahasa yang sama dengan aplikasi akan memudahkan pengembang untuk mendukung makro pengguna yang mewakili aturan bisnis." - apa yang mungkin salah!

— gbjbaanb

10

Dengan penuh semangat saya menunggu hari ketika semua kompiler secara rutin menawarkan Compiler sebagai Layanan (CaaS). Kita perlu berhenti berpikir bahwa kompiler hanya memancarkan kode pra-tautan dan mulai berpikir bahwa kompiler memancarkan pohon yang dapat diubah menjadi beberapa target. Semua kompiler harus memiliki fitur untuk memancarkan pohon dan secara opsional JSON / XML. Output kemudian dapat diubah menjadi banyak jenis target seperti bahasa yang dipercantik yang sama, sumber C, IL, biner IL, Java, Javascript, LLVM, PIC dapat dieksekusi, dan bahkan kode pre-linker.

Saya menulis kompiler untuk mencari nafkah. Pelanggan saya dijual dengan CaaS karena membuka pintu bagi fleksibilitas, portabilitas, dan analisis yang fantastis.

Saya benar-benar kecewa bahwa Microsoft belum mengimplementasikan CaaS sejak lama. Misalnya, itu bisa digunakan sebagai jalur migrasi untuk VB6 ke sesuatu yang lain, atau .Net ke C ++.

— BSalita
sumber

1

Jawaban sederhana mengapa MSFT berinvestasi di Roslyn adalah bahwa basis kode yang ada untuk kompiler C # sekarang 5 versi lama - 11 tahun sekarang. Itu waktu yang lama untuk basis kode apa pun untuk tetap dapat dikelola. Plus, karena mereka menulis ulang, mereka memutuskan untuk berinvestasi dalam melakukannya sehingga semua internalnya terekspos sebagai milik API.

— John Tasler
sumber