Seberapa mudah seharusnya kerangka pengembangan bahasa digunakan?


11

Ini adalah bagian dari serangkaian pertanyaan yang berfokus pada proyek yang disebut Proyek Abstraksi, yang bertujuan untuk abstrak konsep-konsep yang digunakan dalam desain bahasa dalam bentuk kerangka kerja.

Halaman lain yang terkait dengan itu terkait dengan pengetikan struktural dapat dilihat di sini . Meta-topik yang terkait dengan penyelidikan tentang kerangka kerja dan tempat yang tepat untuk memposting dapat ditemukan di sini .

Seberapa mudah seharusnya menggunakan Kerangka Pengembangan Bahasa?

Saya telah menulis kerangka kerja pembuatan kode skala besar yang juga mencakup kemampuan untuk mengirim hasilnya ke kompiler khusus bahasa. Topik kemudahan penggunaan muncul dari satu contoh kerangka kerja seperti: CodeDOM, atau Model Obyek Dokumen Kode.

Ini adalah kerangka kerja yang ditulis oleh Microsoft yang menggambarkan struktur kode umum, tetapi umumnya meninggalkan banyak (pemaksaan ekspresi) dan cenderung agak abstrak dalam representasi konstruk tertentu, untuk benar-benar memancarkan kode buruk berdasarkan pada apa yang Anda lakukan: sebelumnya CodeDOM buruk ditangani memancarkan PrivateImplementationTypepada CodeMemberMethod, ketika jenis yang digunakan adalah antarmuka generik. CodeDOM adalah alasan asli saya untuk menulis generator kode pertama saya.

Satu hal yang saya coba lakukan, untuk menyederhanakan kerangka kerja, adalah mengurangi jumlah pekerjaan yang perlu Anda lakukan sesuatu, dan fokus pada tindakan versus jenis spesifik yang membentuk tindakan itu.

Inilah perbandingan berdampingan tentang cara kerja kerangka yang saya tulis:

//Truncated...
/* *
 * From a project that generates a lexer, this is the 
 * state->state transition character range selection logic.
 * */
var nextChar = nextMethod.Parameters.Add(new TypedName("currentChar", typeof(char).GetTypeReference()));
//...
char start = rangeElement.B.Value.Start;
char end = rangeElement.B.Value.End;
/* *
 * 'start' <= nextChar && nextChar <= 'end'
 * */
currentExpression = start.LessThanOrEqualTo(nextChar).LogicalAnd(nextChar.LessThanOrEqualTo(end));

Versus CodeDOM:

//Truncated...
var nextChar = new CodeVariableReferenceExpression("nextChar");
//...
var start = new CodePrimitiveExpression(rangeElement.B.Value.Start);
var end = new CodePrimitiveExpression(rangeElement.B.Value.End);
currentExpression = new CodeBinaryOperatorExpression(new CodeBinaryOperatorExpression(start, CodeBinaryOperatorType.LessThanOrEqual, nextChar), CodeBinaryOperatorType.BooleanAnd, new CodeBinaryOperatorExpression(nextChar, CodeBinaryOperatorType.LessThanOrEqual, end));

Fokus kerangka kerja ini adalah penggemar bahasa, serta mereka yang tertarik untuk menghasilkan kode atau aplikasi. Mengingat fokusnya pada kompilasi, pembuatan kode, dan pengembangan bahasa, haruskah kerangka kerja fokus pada kemudahan penggunaan atau daya mentah?

Tujuan utama saya adalah untuk meningkatkan ketersediaan alat-alat seperti itu, sehingga mereka yang tertarik pada domain tidak memerlukan banyak pengalaman dalam domain teori bahasa sebelum mereka dapat mulai bekerja pada proyek-proyek yang berfokus pada bahasa mereka sendiri.

Mengingat bahwa saya penulis kerangka kerja, pandangan saya tentang "kegunaan" bias. Jadi, saya harus bertanya kepada yang lain apakah fokus dan tujuan masuk akal bagi orang lain yang tidak terkait dengan proyek.


1
Anda harus mengajukan pertanyaan ini di codereview.stackexchange.com .
Robert Harvey

6
Pertanyaannya, apakah kerangka kerja harus mudah digunakan dengan mengorbankan daya mentah, sama sekali tidak cocok untuk Code Review.SE, di mana "Arsitektur tingkat tinggi dan desain sistem perangkat lunak" tidak topik di sana, dan topik di sini. Peninjauan Kode adalah ketika Anda memiliki kode kerja dan Anda ingin kritik.

Input ke pembuat kode hanyalah bahasa pemrograman lain. Keinginan untuk menghasilkan kode berarti bahwa bahasa yang Anda hasilkan tidak cukup kuat. Bahasa yang lebih baik memiliki generator kode bawaan.
kevin cline

@ kevincline Kasus penggunaan umum untuk pembuat kode adalah bahasa khusus domain yang menggunakan kerangka kerja pembuatan kode tujuan umum. Ini sebenarnya bukan pilihan, alternatifnya adalah mengkompilasi ke bahasa perantara internal Anda sendiri dan menafsirkannya melalui VM, atau menerjemahkannya sendiri ke dalam konstruksi tingkat yang lebih rendah, tetapi pada akhirnya Anda melakukan hal yang sama . Itulah yang ingin dilakukan oleh kerangka kerja ini, ketika Anda perlu melakukan pekerjaan untuk menghasilkan kode secara dinamis, Anda akan menggunakan ini versus menyayangi implementasi Anda sendiri untuk hal yang sama.
Allen Clark Copeland Jr

Bukan karena bahasa sumber tidak mencukupi, tetapi tata bahasa hanya berupa teks sampai perangkat lunak perantara ditulis untuk menerjemahkan dari teks sumber ke platform target. Dalam hal ini adalah Infrastruktur Bahasa Umum (CLI), atau kode dalam bahasa tujuan umum yang menargetkan CLI. Kerangka kerja ini bertujuan untuk menangani pekerjaan kasar dengan mengambil representasi tingkat tinggi dan menerjemahkannya ke dalam konstruksi tingkat rendah yang cukup untuk generasi IL. yaitu kompiler, hanya karena Anda memerlukan kompiler tidak berarti bahasa Anda tidak cukup kuat. Itu wajib.
Allen Clark Copeland Jr

Jawaban:


2

Sulit membangun kerangka pengembangan bahasa. Anda harus memutuskan hal-hal apa yang Anda ingin dukung, maka Anda harus memutuskan mana yang Anda tahu cara melakukannya, dan bagaimana memadukannya menjadi satu kesatuan yang koheren. Akhirnya, Anda telah melakukan investasi yang cukup sehingga bekerja dengan bahasa nyata (mis., Bahasa komputer khas serta DSL), dan benar-benar melakukan sesuatu yang bermanfaat. Topi saya untuk Anda untuk mencoba.

Anda dapat membandingkan usaha Anda dengan yang saya mulai 15 tahun yang lalu, DMS Software Reengineering Toolkit . DMS dimaksudkan untuk memberikan parsing tujuan umum, analisis, dan transformasi kode. Diberikan spesifikasi langauge eksplisit, itu akan mengurai kode, membangun AST, membuat ulang kode dari AST (prettyprint), mengubah kode menggunakan pola yang ditulis dalam bahasa pemrograman yang ditargetkan, membangun tabel simbol, kontrol komputasi dan aliran data, dll. Dengan menambahkan kode khusus, satu membuat DMS membawa berbagai efek. (Lihat alat di situs; semuanya DMS dalam satu atau lain bentuk).

Berikut ini makalah teknis tentang DMS seperti beberapa tahun yang lalu. (Kami terus meningkatkannya)

Walaupun DMS sendiri sulit dibangun, kami menemukan bahwa dibutuhkan sejumlah besar teknik yang sesuai untuk mendefinisikan bahasa nyata ke DMS, termasuk IBM COBOL, C # 4.0, Java 1.7, C ++ 11 (dan banyak lainnya).

Apa yang kami pikirkan (cukup baik): menurunkan biaya alat bangunan sebesar 1-2 kali lipat. Artinya, tugas-tugas yang mungkin memakan waktu 1-10 tahun dapat direnungkan oleh manusia biasa sebagai proyek 1 bulan-1 tahun. Yang masih tidak mudah:

  • Menentukan bahasa baru
  • Menangani semua kebodohan bahasa saat ini
  • Mempermudah untuk menulis kode khusus untuk tugas Anda
  • Menentukan analisis baru dan kompleks
  • Menangani sebagian program, atau program yang mengandung kesalahan
  • (Ke titik awal Anda) Permudah buat nonexperts untuk menggunakan alat ini

Jadi, ada banyak ruang untuk perbaikan. Biarkan banyak bunga mekar.


0

Pertanyaan ini mungkin telah dijawab di The Mythical Man Month, bagian "Integritas Konseptual". Jika tidak, itu setidaknya sangat relevan dengan pertanyaan Anda. Meskipun Brooks mendeskripsikan merancang seluruh sistem komputasi, esai ini berlaku dengan sangat baik untuk kerangka kerja dan bahasa baru.

Saya percaya ada korelasi positif antara tingkat adopsi teknologi apa pun dengan integritas konseptual dan kemudahan penggunaannya. Seharusnya ada studi kasus teknologi terbaru seperti bahasa, kerangka kerja, dan OS, untuk membuktikan korelasi ini, tetapi belum ada yang tahu.


Satu-satunya masalah saya dengan jawaban ini adalah, tidak memberikan nilai nyata. Apakah rujukan bagian dari buku dan dari deskripsi Anda hanya akan berlaku setelah paket perangkat lunak telah dirilis. Itu tidak memberi saya jawaban sebelum rilis, karena pada dasarnya mengatakan 'itu akan baik jika mudah digunakan dan relevan dengan domain.' Saya tidak bisa mengatakan seberapa baik itu akan dilakukan karena itu belum sampai di titik di mana Anda dapat menggunakannya. Masalahnya dengan kompiler adalah, Anda melakukan banyak pekerjaan, hanya untuk menyadari bahwa Anda hanya setengah jalan mendaki gunung, dan itu adalah bagian yang mudah.
Allen Clark Copeland Jr
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.