Masalah Implementasi Alternatif (Alternative Implementation Problem)

Masalah implementasi alternatif

Penulis membahas masalah implementasi alternatif yang berulang kali muncul di dunia perangkat lunak. Pengalaman penulis terutama berkaitan dengan mengoptimalkan bahasa pemrograman bertipe dinamis.

• Proyek PyPy mengembangkan compiler JIT canggih untuk Python, tetapi dalam praktiknya hampir tidak digunakan. Karena Python terus berubah dengan menambahkan fitur-fitur baru, PyPy kesulitan untuk mengimbanginya.
• LuaJIT sangat dihargai, tetapi karena bahasa Lua terus menambahkan fitur baru, LuaJIT tertinggal beberapa versi.
• TruffleRuby JIT menunjukkan performa yang paling mengesankan, tetapi karena kompatibilitas fiturnya kurang dibandingkan CRuby, penyebarannya hanya terbatas.

Pelajaran: implementasi alternatif adalah pilihan yang nyaris pasti gagal

• Jika membuat implementasi alternatif, kita tak bisa lepas dari ketergantungan pada perubahan implementasi resmi.
• Implementasi resmi mengendalikan arah proyek, dan implementasi alternatif pada akhirnya hanya bisa mengikuti.
• Secara tradisional, saat membuat implementasi JIT untuk bahasa interpreter, implementasi resmi bisa melampaui JIT karena jauh lebih cepat menambahkan fitur baru ke interpreter.

YJIT: mengimplementasikan compiler JIT Ruby di dalam CRuby

• YJIT adalah JIT Ruby lain, tetapi memilih untuk diimplementasikan langsung di dalam CRuby sendiri.
• Dengan begitu, YJIT bisa 100% kompatibel dengan semua fitur CRuby sejak awal.
• Kini YJIT telah menjadi JIT resmi Ruby dan digunakan di Shopify, Discourse, GitHub, dan lainnya.

Pelajaran dalam sudut pandang yang lebih luas

• Bahasa Crystal, yang mirip dengan bahasa yang sudah ada tetapi tidak kompatibel, juga hanya meraih keberhasilan yang terbatas.
• Sesuatu yang tampak mirip dengan bahasa yang sudah ada tetapi tidak kompatibel hanya akan membingungkan orang.
• Saat membuat bahasa pemrograman baru, lebih baik tidak berusaha menjadi subset dari bahasa yang sudah ada dan memilih jalannya sendiri.
• Dengan begitu, ia bisa berevolusi dengan kecepatan dan arah sendiri tanpa terikat pada performa, fitur, atau library implementasi lain.

Opini GN⁺

• “Masalah implementasi alternatif” yang dijelaskan dalam tulisan ini adalah hal yang perlu diperhatikan bukan hanya dalam bahasa pemrograman, tetapi juga saat membuat berbagai sistem perangkat lunak dan perangkat keras.
• Jika terlalu fokus pada stabilitas dan kompatibilitas saja, inovasi bisa menjadi sulit. Namun dari sudut pandang pengguna nyata, kompatibilitas adalah faktor yang sangat penting. Menjaga keseimbangan antara teknologi baru dan kemudahan bagi pengguna itu penting.
• Dari perspektif jangka panjang, proyek baru perlu benar-benar mempertimbangkan dengan siapa ia kompatibel dan ke arah mana ia akan berevolusi.
• Saat membuat bahasa pemrograman baru, hanya membuat sintaksnya mirip dengan bahasa yang sudah ada justru menambah kebingungan. Sebaliknya, lebih baik menegaskan filosofi dan arah yang khas.
• Dibandingkan bersaing di pasar, menghadirkan solusi yang kreatif dan orisinal tampaknya memiliki peluang lebih besar untuk berhasil dalam jangka panjang.

[GN⁺]

Komentar Hacker News

• Saat mengembangkan implementasi alternatif baru, jika arsitekturnya berbeda dari versi yang sudah ada, hal-hal yang mudah di versi lama bisa menjadi sangat sulit di versi baru. Misalnya, jika perangkat lunak proprietary memuat/menyimpan per section, sementara versi baru memuat seluruh dokumen ke memori, maka untuk mendukung fitur penambahan lampiran bisa jadi perlu mengubah seluruh arsitektur versi baru.
• Memposisikan diri sebagai alternatif dari implementasi yang sudah ada adalah proposisi yang kalah. Proyek yang dipasarkan sebagai "Python + X" sulit bersaing dengan versi resmi. Namun, jika seperti MicroPython dirancang untuk microcontroller dan tidak bersaing dengan CPython, melainkan dengan lingkungan pemrograman microcontroller lain, maka proyek itu bisa berhasil.
• Terlepas dari klaim kompatibilitas, dalam praktiknya sering kali kompatibilitasnya rendah bahkan untuk fitur bahasa yang lama, dan ini menjadi alasan implementasi alternatif gagal. Dalam kasus Ruby dan Python, contohnya adalah kurangnya dukungan untuk native C extension.
• Berdasarkan pengalaman mendirikan startup, seharusnya fokusnya bukan mengejar fitur dasar, melainkan menunjukkan bahwa arsitektur tersebut dapat mendukung fitur enterprise dan memusatkan perhatian pada sesuatu yang benar-benar berbeda.
• Pengembang lebih mementingkan fitur bahasa dan interoperabilitas daripada JIT. Membuat proyek paralel sendiri memang lebih mudah daripada berkontribusi ke proyek yang sudah ada, tetapi perlu bertanya untuk siapa proyek itu dibuat. Harus berhati-hati agar tidak terjebak dalam narsisme.
• Kode wrapper sering menyimpang dari standar dan dokumentasinya kurang, sehingga menimbulkan penderitaan. Sebaiknya hanya menambahkan fitur yang benar-benar perlu dan menggunakan nilai default.
• Ini mirip dengan masalah yang dialami TiDB karena kompatibilitas MySQL. Secara teoretis itu adalah protokol terbuka, tetapi dalam praktiknya Chrome yang memimpinnya.
• Tidak ada penyebutan tentang Kotlin.