Saya telah diberi tugas untuk mengimplementasikan Bahasa Spesifik Domain untuk alat yang mungkin menjadi sangat penting bagi perusahaan. Bahasa ini sederhana tetapi tidak sepele, itu sudah memungkinkan loop bersarang, penggabungan string, dll. Dan secara praktis yakin bahwa konstruksi lain akan ditambahkan seiring kemajuan proyek.
Saya tahu dari pengalaman bahwa menulis lexer / parser dengan tangan -kecuali tata bahasanya sepele- adalah proses yang memakan waktu dan rawan kesalahan. Jadi saya dibiarkan dengan dua opsi: generator parser à la yacc atau perpustakaan kombinator seperti Parsec. Yang pertama juga bagus tetapi saya memilih yang kedua karena berbagai alasan, dan mengimplementasikan solusi dalam bahasa fungsional.
Hasilnya cukup spektakuler di mata saya, kodenya sangat ringkas, elegan dan mudah dibaca / lancar. Saya akui itu mungkin terlihat agak aneh jika Anda tidak pernah memprogram apa pun selain java / c #, tapi kemudian ini akan berlaku untuk apa pun yang tidak ditulis dalam java / c #.
Namun pada beberapa titik, saya benar-benar diserang oleh seorang rekan kerja. Setelah melihat sekilas layar saya, dia menyatakan bahwa kodenya tidak bisa dipahami dan saya tidak harus menemukan parsing tetapi cukup gunakan stack dan String. Letakkan seperti yang dilakukan semua orang. Dia membuat banyak suara, dan saya tidak bisa meyakinkan dia, sebagian karena saya terkejut dan tidak memiliki penjelasan yang jelas, sebagian karena pendapatnya tidak berubah (tidak ada kata pun dimaksudkan). Saya bahkan menawarkan untuk menjelaskan bahasanya, tetapi tidak berhasil.
Saya yakin diskusi akan muncul kembali di depan manajemen, jadi saya menyiapkan beberapa argumen yang solid.
Ini adalah beberapa alasan pertama yang muncul di benak saya untuk menghindari solusi berbasis String.Split:
- Anda perlu banyak jika untuk menangani kasus-kasus khusus dan hal-hal dengan cepat lepas kendali
- banyak indeks array hardcoded membuat pemeliharaan menyakitkan
- sangat sulit untuk menangani hal-hal seperti pemanggilan fungsi sebagai argumen metode (mis. add ((tambahkan a, b), c)
- sangat sulit untuk memberikan pesan kesalahan yang bermakna jika terjadi kesalahan sintaks (sangat mungkin terjadi)
- Saya semua untuk kesederhanaan, kejelasan dan menghindari hal-hal smart-cryptic yang tidak perlu, tetapi saya juga percaya itu adalah kesalahan untuk merobohkan setiap bagian dari basis kode sehingga bahkan sirip burger pun dapat memahaminya. Itu argumen yang sama yang saya dengar untuk tidak menggunakan antarmuka, tidak mengadopsi pemisahan masalah, menyalin-menempel kode sekitar, dll. Minimal kompetensi teknis dan kemauan untuk belajar diperlukan untuk bekerja pada proyek perangkat lunak. (Saya tidak akan menggunakan argumen ini karena mungkin akan terdengar ofensif, dan memulai perang tidak akan membantu siapa pun)
Apa argumen favorit Anda yang menentang penguraian cara Cthulhu ? *
* tentu saja jika Anda dapat meyakinkan saya dia benar saya akan sangat bahagia juga