Apakah Pemrograman Berorientasi Bahasa praktis?

Saya membaca artikel ini tentang Pemrograman Berorientasi Bahasa. Dia menunjukkan beberapa kelemahan dalam pendekatan prosedural / OOP modern untuk pemrograman, dan menyarankan paradigma pemrograman baru yang akan menyelesaikannya.

Saya semua untuk bagian-bagian program yang kecil dan longgar: Jauh lebih baik untuk mempelajari banyak hal kecil, yang semuanya akan Anda gunakan, daripada beberapa hal besar, bahwa Anda hanya menggunakan sedikit demi sedikit.

Membaca artikel itu, saya mendapat kesan bahwa penulis mempromosikan salah satu dari dua hal:

• Banyak bahasa scripting yang mudah dibuat
• Bahasa tunggal yang mudah diperluas yang dapat menulis ulang sendiri untuk memenuhi kebutuhan programmer

Jika dia menyarankan yang kedua, saya akan menjawab dengan "Sudah selesai!" dan berikan Lisp sebagai contoh. Seperti yang disarankan Paul Graham, bahasa tampaknya terus bergerak ke arah ini .

Sejauh yang pertama menyangkut, saya pikir ini adalah ide yang baik, jika ada bahasa mendasar yang mengikat mereka semua. Bagi saya itu adalah titik lemah: komunikasi antar bahasa. Apakah Anda menggunakan panggilan, yang merupakan konsep prosedural atau pesan-lewat, yang mengingatkan saya pada komunikasi antarproses? Saya akan menyambut baik kesempatan untuk bekerja dengan bahasa spesifik domain kecil, jika mudah digunakan semuanya pada saat yang sama. Apakah pendekatan ini (LOP) praktis?

Saya telah mengadvokasi DSL untuk waktu yang lama, tetapi saya khawatir tentang apa yang terjadi pada Ide Baik ketika mereka menjadi kereta musik. Produk dibuat yang mengiklankan The Good Idea, menjanjikan semua yang harus Anda lakukan adalah mendapatkannya , dan Anda akan berada di dalam grup, tanpa harus berpikir dengan hati-hati tentang artinya.

Apa itu bahasa? Ini adalah kosakata dan sintaksis di mana makna dapat dikomunikasikan, kan? Setiap kali Anda mendeklarasikan variabel, menulis fungsi, menentukan kelas, Anda membangun bahasa baru, dengan menambahkan kata benda dan kata kerja ke bahasa yang ada. Sekarang Anda dapat mengatakan hal-hal di dalamnya yang sebelumnya tidak dapat Anda lakukan.

Saya pikir apa yang membuat bahasa Domain Specific adalah sejauh mana itu secara alami mengekspresikan konsep mental yang sedang dikomunikasikan, dan saya pikir ada ukuran sederhana dari itu. Pada dasarnya, jika ada persyaratan mandiri X sederhana yang berdiri sendiri, yang dapat dimasukkan dalam program atau tidak, implementasi yang benar memerlukan beberapa set penyisipan kode, penghapusan, dan penggantian Y. Perbedaan sederhana sebelum dan sesudah dapat menampilkan Y. Angka N dari perubahan tersebut adalah ukuran seberapa spesifik bahasa domain. Semakin kecil N, untuk persyaratan umum, semakin baik.

Itu tidak selalu tergantung pada sintaksis mewah, struktur kontrol, penyampaian pesan, atau apa yang Anda miliki. Apa itu tergantung pada bagaimana ringkas mengimplementasikan persyaratan. Banyak alat akan mengklaim untuk melakukan ini, tetapi klaim bukan aktualitas. Itu harus nyata .

Kadang-kadang sebuah teknologi yang tidak biasa adalah diperlukan. Inilah contoh favorit saya. Ketika itu, itu menggambarkan titik yang mungkin memerlukan upaya dari pihak programmer untuk memahaminya. Jadi kekhususan domain (dan rawatan) sama sekali tidak sama dengan keterbacaan .

Jadi saya setuju dengan pendekatan kedua, bahwa bahasa yang baik adalah bahasa yang mudah membuat orang membangun bahasa yang diperlukan di atasnya. (Itulah yang saya sukai tentang Lisp.) Tetapi yang lebih penting adalah programmer perlu tahu bagaimana membangun bahasa agar sesuai dengan domain tempat mereka bekerja, dan bersedia untuk memanjat kurva pembelajaran bahasa tersebut.

Saya tidak benar-benar melihat itu terjadi. Alih-alih mereka terjebak dalam "program = algoritma + struktur data", atau "kata benda menjadi kelas dan kata kerja menjadi metode" turn-the-crank mode berpikir. Mereka tidak bekerja dalam hal bagaimana mengambil domain pemikiran dan melafalkannya untuk kepastian maksimal.

Itu cukup pendekatan Ruby.

• Menjaga bahasa inti tetap sederhana dan memperluas melalui permata
• Buat dialek Ruby untuk domain tertentu melalui patch monyet. ig Ruby on Rails.

Saya tidak tahu apakah ini lebih baik, tapi saya kira sangat pragmatis.

Pendekatan LOP sangat praktis. Ingatlah bahwa Anda tidak harus menerapkan "bahasa scripting" - metodologi ini juga berlaku untuk eDSL, dan biasanya dikompilasi secara efisien. Saya menggunakan pendekatan ini dalam semua pekerjaan pengembangan saya.

Kita akan melihat lebih banyak tentang Bahasa Khusus Domain di masa depan, dihakimi oleh orang-orang yang berbicara tentang mereka sekarang - saya perhatikan Martin Fowler berbicara tentang mereka terlalu banyak dan beberapa artikel menarik melalui Lambda The Ultimate pada topik, diantara yang lain.

Itu menunjukkan kepada saya bahwa ini jelas merupakan arah di mana angin bertiup sehubungan dengan desain bahasa pemrograman dan platform pemrograman. Dalam beberapa hal sudah cukup lama - salah satu kelebihan Ruby (seperti yang telah diamati beberapa orang) adalah membuatnya mudah untuk membuat DSL tetapi sebenarnya ada banyak sekali di aplikasi dan perpustakaan pemrograman yang sudah kita gunakan.

Saya menggunakan LOP setiap kali pemrograman solo. Saya menemukan bahwa dalam beberapa proyek, tidak ada cara lain untuk memenuhi jadwal. Dalam alegori sederhana, seseorang dapat menyamakan penggunaan LOP untuk alat-alat listrik. Jika Anda bekerja sendirian di bengkel, Anda tidak dapat melakukan hal-hal secara manual dan memenuhi tenggat waktu. Jika ada orang lain bersama Anda, mengoordinasi penggunaan alat-alat listrik itu penting untuk efisiensi dan keamanan.
Dalam mode tim, LOP membutuhkan persiapan organisasi untuk menghindari bencana Tower of Babel.