Sebuah interpreter Lisp yang ditulis dalam bahasa C hanya dalam 99 baris telah memicu diskusi sengit di komunitas pemrograman tentang apakah kompresi kode yang ekstrem memiliki biaya yang terlalu tinggi. Proyek yang disebut tinyLisp ini mencoba mengemas interpreter Lisp fungsional dengan 21 primitif bawaan, garbage collection, dan REPL ke dalam kurang dari 100 baris kode C.
Fitur TinyLisp:
- 99 baris kode C (rata-rata 55 baris sumber)
- 21 primitif Lisp bawaan
- Garbage collection sederhana
- REPL (Read-Eval-Print Loop)
- Dukungan static scoping
- Aritmatika floating-point presisi ganda
- Lebar maksimum 120 kolom untuk editing
 |
|---|
| Contoh sesi dalam interpreter mirip Lisp, menampilkan penggunaan fungsi lambda dan currying, yang mencerminkan fungsionalitas tinyLisp |
Kekhawatiran Kualitas Kode Mendominasi Diskusi
Implementasi ini telah menuai kritik tajam dari para developer yang berargumen bahwa mengejar singkatnya kode telah menghasilkan praktik kode yang bermasalah. Para kritikus menunjuk pada beberapa masalah teknis termasuk penyalahgunaan tipe data double, masalah ketergantungan endian, dan pelanggaran strict aliasing yang mungkin mencegah kode bekerja pada compiler modern. Beberapa developer bahkan telah menemukan kesalahan sintaks dalam versi saat ini, dengan tanda kurung tutup tambahan pada baris 81 yang mencegah kompilasi.
Penulis menggunakan teknik yang disebut NaN-boxing, di mana informasi tipe disimpan dalam byte pertama dari angka floating-point presisi ganda. Meskipun pendekatan ini digunakan dalam sistem produksi seperti mesin JavaScript dan Ruby, implementasinya dalam tinyLisp telah dikritik karena memprioritaskan ukuran daripada kejelasan.
Masalah Teknis yang Teridentifikasi:
- Kesalahan sintaks pada baris 81 (kelebihan tanda kurung tutup)
- Penyalahgunaan tipe data double untuk penandaan tipe
- Masalah ketergantungan endian
- Pelanggaran strict aliasing
- Kurangnya optimisasi tail call (TCO)
- Masalah kompatibilitas dengan kompiler modern
Trade-off Keterbacaan vs Singkatnya Kode
Banyak anggota komunitas telah menyatakan preferensi untuk kode yang lebih panjang dan lebih mudah dibaca daripada pendekatan yang dikompresi. Implementasi alternatif telah disorot, termasuk versi 700 baris yang disebut fe yang memprioritaskan kejelasan dan struktur dokumentasi yang tepat. Konsensus di antara para kritikus tampaknya adalah bahwa menggandakan atau melipattigakan jumlah baris akan bermanfaat jika menghasilkan kode yang dapat dipelihara dan dipahami.
Saya sangat lebih suka 200 baris kode yang benar-benar dapat dibaca dengan baik.
Implementasi Alternatif:
- fe: Implementasi C yang jelas dengan 700 baris kode dan dokumentasi yang lebih baik
- Versi Python: ~100 baris dengan implementasi lispy.html dari Norvig
- tinylisp-extras.c: Versi yang diperluas dengan dukungan TCO
Kemampuan Teknis dan Keterbatasan
Meskipun mendapat kritik, tinyLisp memang menawarkan fungsionalitas yang substansial untuk ukurannya. Interpreter ini mendukung static scoping, aritmatika floating-point presisi ganda, dan mencakup operasi Lisp yang esensial. Namun, implementasi ini tampaknya tidak memiliki tail call optimization (TCO), yang membatasi kemampuannya untuk mengeksekusi fungsi rekursif seperti Y-combinator tanpa risiko stack overflow.
Proyek ini mencakup versi yang dioptimalkan untuk peningkatan kecepatan dan pengurangan penggunaan memori, dan penulis telah menyediakan contoh ekstensi untuk menambahkan fitur Lisp tambahan.
Kesimpulan
Proyek tinyLisp berfungsi sebagai studi kasus yang menarik dalam perdebatan yang sedang berlangsung antara pencapaian code golf dan pengembangan perangkat lunak praktis. Meskipun prestasi teknis mengimplementasikan interpreter Lisp fungsional dalam 99 baris sangat mengesankan, respons komunitas menunjukkan bahwa kompresi yang ekstrem seperti itu mungkin tidak sebanding dengan tantangan pemeliharaan dan keandalan yang dihasilkan. Diskusi ini menyoroti pentingnya menyeimbangkan inovasi dengan kualitas kode dalam proyek pemrograman dunia nyata.
Referensi: Lisp in 99 lines of C and how to write one yourself