Berhenti Merancang Bahasa, dan Sebagai Gantinya Tulis Library

• Inti produktivitas pemrograman terletak pada ekosistem library yang kaya, bukan pada bahasanya sendiri
• Framework seperti Ruby on Rails yang memanfaatkan fitur-fitur canggih bahasa dapat memberikan produktivitas tinggi bahkan bagi nonspesialis
• Namun, karena keterbatasan struktural bahasa, framework setingkat Rails sulit diimplementasikan dalam Java atau C
• Perancangan bahasa secara langsung menentukan bentuk dan kompleksitas library yang dapat ditulis, dan inilah tujuan esensial dari evolusi bahasa
• Bahasa Stanza menunjukkan, dari sudut pandang ini, pentingnya perancangan bahasa yang memungkinkan pembuatan library yang kuat dan mudah digunakan

---

Hubungan antara bahasa pemrograman dan library

• Sebagian besar bahasa pemrograman memiliki elemen dasar serupa seperti variabel, array, perulangan, dan fungsi
  • Beberapa bahasa menyediakan fitur lanjutan seperti fungsi kelas satu atau coroutine, tetapi nonspesialis jarang menggunakannya
• Bagi banyak pengembang, faktor yang meningkatkan produktivitas adalah library, bukan bahasa
  • Sebagai contoh, Ruby on Rails memudahkan pembuatan aplikasi web berbasis database
  • Berkat Rails, preferensi sering kali lebih kuat pada framework-nya daripada pada bahasa Ruby itu sendiri

Interaksi antara Ruby on Rails dan fitur bahasa

• Rails memanfaatkan beragam fitur Ruby seperti metaprogramming, evaluasi saat runtime, fungsi kelas satu, dan garbage collection
  • Contoh: ActiveRecords menggunakan metaprogramming, dan sistem template menggunakan evaluasi saat runtime
  • Pemrosesan event diimplementasikan dengan cara meneruskan fungsi kelas satu sebagai callback
• Dalam Java atau C, fitur-fitur ini kurang memadai sehingga framework setingkat Rails tidak dapat diimplementasikan
  • Metaprogramming di Java tidak cukup kuat untuk mengimplementasikan ActiveRecords
• Karena itu, Rails dimungkinkan oleh struktur bahasa Ruby, dan perancangan bahasa menentukan kemungkinan library

Perancangan bahasa menentukan bentuk library

• Bahasa C hanya mendukung reuse melalui deklarasi dan pemanggilan fungsi, sehingga sebagian besar library C berbentuk kumpulan fungsi
• Ruby mendukung fungsi kelas satu, sehingga “aksi yang dijalankan saat tombol diklik” dapat diekspresikan secara ringkas
  • Sebaliknya, di Java perlu mendefinisikan kelas handler, sehingga kode menjadi lebih rumit
• Daya ekspresif bahasa secara langsung menentukan struktur dan kegunaan library

Munculnya software interaktif dan framework yang dapat diperluas

• Dalam komputasi batch pada tahun 1970-an, library yang berpusat pada fungsi sudah memadai
• Dalam software interaktif modern, dibutuhkan library yang dapat diperluas
  • Pada GUI atau sistem berbasis event, diperlukan struktur seperti “jalankan kode saya saat pengguna mengklik”
• Java dan C++ mendukung perluasan melalui pewarisan dan method overriding, dan struktur ini berkembang menjadi framework

Latar belakang desain Stanza dan keterbatasan bahasa

• Motivasi desain Stanza berawal dari sulitnya menulis library pemrograman game yang mudah digunakan di Java
  • Di Java, konkurensi harus diekspresikan sebagai state machine
  • Scheme mendukung continuation sehingga implementasi yang lebih intuitif dimungkinkan
• Namun, Scheme tidak mendukung pemeriksaan tipe statis sehingga efisiensi debugging rendah
  • Saat ini sebagian besar bahasa tidak dapat memperluas sistem tipe sebagai library
• Stanza menyediakan sistem tipe opsional, garbage collection, dan sistem objek berbasis multimethod
  • Namun, sistem objek buatan pengguna yang sepenuhnya baru tidak dapat ditulis

Tujuan bahasa dan arah riset

• Tujuan bahasa pemrograman serbaguna adalah mendukung pembuatan library yang kuat dan mudah digunakan
  • Semakin kuat suatu bahasa, semakin ringkas penggunaan library-nya
• Saat kode menggunakan library yang dirancang dengan baik, ia memiliki kesan alami seperti membaca kalimat yang memberi instruksi kepada rekan kerja
• Riset seperti Racket, Shen, dan meta object protocol sedang mengeksplorasi sistem tipe dan objek yang dapat diperluas
• Pada akhirnya, bahasa dibedakan berdasarkan “library apa yang bisa digunakan, dan apa yang tidak bisa digunakan”
• Di balik library yang elegan terdapat puluhan tahun riset bahasa dan upaya perancangan

[GN⁺]

Komentar Hacker News

• Contoh terbaiknya adalah Prolog. Sering disebut sebagai bahasa representatif untuk pemrograman logika, tetapi pada praktiknya tidak lebih dari sekumpulan algoritma yang dapat diimplementasikan sebagai library di berbagai bahasa. Menurut saya, cukup sediakan ekspresi sintaks Prolog yang sesuai dengan tata bahasa masing-masing bahasa

  • Inti Prolog bukan pada algoritmanya, melainkan pada cara menyatakan aturan logika secara deklaratif. Misalnya, jika kita mendefinisikan aturan “kakek-nenek adalah orang tua dari orang tua”, kita bisa memakainya untuk mencari kakek-nenek atau sebaliknya menyimpulkan hubungan orang tua. Inferensi dua arah seperti inilah daya tarik Prolog. Tentu saja, untuk meniru fitur seperti ini di bahasa umum dibutuhkan kode tanpa efek samping dan DSL yang terbatas. Seperti CUDA yang dijalankan dari Python melalui PyTorch atau TensorFlow, pemanggilan lintas bahasa juga memungkinkan, jadi struktur yang tidak bergantung pada satu bahasa tertentu sepenuhnya masuk akal
  • Sintaks Prolog adalah subset dari First Order Logic, dan variabel tidak diberi nilai secara langsung, melainkan dicari di atas himpunan nilai yang mungkin sampai kondisinya terpenuhi. Mesin Prolog melakukan lebih dari sekadar pemanggilan library biasa — misalnya representasi terkompresi dari ruang solusi, eksekusi paralel, dan pemangkasan otomatis. Karena itu, Prolog biasanya diintegrasikan sebagai layanan backend atau lewat pendekatan code generation. Prolog sangat kuat khususnya untuk perencanaan, penyelesaian kendala, pembuktian teorema, pengujian kombinatorial, dan pemodelan harga. Jadi menurut saya, agak sulit melihat Prolog hanya sebagai “bahasa yang cukup dijadikan library”
  • Dengan logika yang sama, kita juga bisa bilang fitur berorientasi objek tidak perlu ada di bahasa karena bisa ditiru dengan closure. Namun, ada keuntungan dari daya ekspresi yang diberikan oleh sintaks yang jelas
  • Untuk mengimplementasikan pemrograman relasional seperti Prolog sebagai library, sebuah bahasa harus mendukung manipulasi simbol dan variabel sebagai warga kelas satu. Bahasa keluarga Lisp mungkin masih memungkinkan, tetapi di bahasa umum kegunaannya turun drastis. Saat saya membicarakan ini dengan Bob Harper, dia berkata, “buat saja bahasa baru”, dan itu terdengar cukup meyakinkan
  • Saya ingin belajar Prolog, tetapi sulit menemukan materi tingkat menengah di antara tutorial pemula dan contoh tingkat lanjut. Saya sedang mencoba menyelesaikan varian puzzle Sudoku dengan Prolog, tetapi contoh-contoh yang ada terlalu dioptimalkan sehingga sulit mempelajari definisi relasi yang digeneralisasi. Saya terutama ingin tahu bagaimana memodelkan situasi ketika beberapa aturan bisa saja salah. Sebagai referensi, saya sedang melihat contoh Sudoku di SWI-Prolog

• Sepuluh tahun lalu saya adalah penggemar Scala. Konsep “Scalable Language” yang memungkinkan membuat DSL di dalam sistem tipenya sangat menarik. Namun saya kehilangan minat ketika komunitas mulai memakainya seperti Haskell di atas JVM. Belakangan saya berharap teknologi seperti WASM atau Graal akan memberi fleksibilitas lebih besar dalam memilih bahasa. Dalam banyak kasus JS sudah cukup, tetapi menyenangkan mengetahui kita punya opsi menggunakan bahasa tingkat rendah seperti Rust saat diperlukan

  • Saya juga merasa masalah terbesar Scala adalah penyalahgunaan DSL. Bukan hanya bahasanya sendiri, bahkan di framework pengujian terasa seperti harus mempelajari bahasa lain lagi. Tentu, kemampuan mengekspresikan Hadoop MapReduce dalam satu baris itu mengesankan, tetapi untuk kebanyakan pekerjaan itu berlebihan. Selain itu, pengembang Scala tampaknya tidak suka menulis “kode yang membosankan”. Saya sering melihat orang mengejar gaya keren, lalu pergi meninggalkan neraka pemeliharaan
  • Tidak seluruh komunitas Scala berorientasi ke Haskell. Hanya sebagian penyihir tipe yang cenderung seperti itu. Scala juga sangat bagus jika dipakai hanya sebagai “Java yang lebih baik”. Kita bisa menikmati keuntungan pemrograman fungsional tanpa terlalu terbebani
  • Haskell memang sering dipakai sebagai bahasa untuk membuat DSL. Haxl dari Meta dan TidalCycles, DSL untuk musik, adalah contoh yang bagus. Namun, library berbasis tipe tingkat tinggi sering mengalami penurunan performa yang parah dan menjadi rumit tanpa perlu
  • Apakah Anda pernah memakai Clojure(Script)? Sesuai karakter keluarga Lisp, ia memungkinkan pemrograman bottom-up dengan memperluas bahasa sesuai masalah yang dihadapi. Pendekatan ini juga ditekankan Paul Graham dalam On Lisp. Saya juga merekomendasikan presentasi terkait Bottom Up vs Top Down Design in Clojure
  • Saya baru mulai belajar Scala akhir-akhir ini, dan saya sangat menyukainya bahkan dari sisi pemrograman fungsional. Menurut saya, Scala cukup umum untuk dipakai dengan banyak cara selain membuat DSL. Saya penasaran, apakah ada kekurangan tertentu yang Anda rasakan pada Scala

• Akan bagus kalau ada bahasa skrip bertipe yang bisa menggantikan bash. Saya pernah membuat skrip parser JSON sederhana dengan Elixir, dan hasilnya cukup bagus

  • Sudah pernah mencoba Nushell? Banyak pekerjaan yang dulu mengharuskan memakai “bahasa sungguhan” bisa diselesaikan dalam satu baris. Misalnya, pipeline untuk mengurutkan daftar file dan mengeluarkannya sebagai JSON bisa ditulis dengan sederhana
  • Sebenarnya, dengan shebang kita bisa menulis skrip dalam berbagai bahasa. Misalnya C#, Java, dan Go semuanya bisa. Dengan Scriptisto, Anda bisa membuat skrip shebang dalam hampir semua bahasa
  • OCaml juga bisa dipakai seperti skrip. Bisa langsung dijalankan dengan #!/usr/bin/env ocaml. Hanya saja, tidak ada fitur untuk memasang dependensi eksternal secara otomatis dari satu file
  • Di Go juga ada trik untuk meniru shebang. Diskusi terkait bisa dilihat di sini
  • Untuk scripting sehari-hari, Python atau PowerShell juga pilihan yang bagus

• Bahasa dan library tidak saling eksklusif. Ada library yang pada praktiknya bertindak seperti bahasa, dan sebaliknya ada bahasa yang dirancang untuk library tertentu. Misalnya Julia adalah contoh yang menyeimbangkan performa dan kemudahan pakai dengan baik. Kita bisa menulis kode berperforma tinggi langsung di Julia, lalu mendapatkan eksekusi yang dioptimalkan lewat kompilasi spesialisasi tipe setingkat JIT. Modelnya berupa pemanggilan fungsi yang sederhana, tetapi di dalamnya bekerja dengan sangat canggih

  • Benar, pada akhirnya poin utamanya adalah bahwa kita membutuhkan bahasa dan library sekaligus

• Raku dirancang sebagai struktur yang menggabungkan beberapa subbahasa (slang). Misalnya regex, PEG, quoting, dan lainnya diperlakukan sebagai mini-bahasa masing-masing, dan dengan Slangify kita bisa dengan mudah menambahkan DSL sendiri

  • Tetapi secara pribadi saya tidak suka sintaks yang menaruh tipe setelah nama variabel, jadi saya kurang menyukai Raku

• Dulu ada seorang pengembang senior yang berkata, “kalau saya lihat Rails di CV, langsung saya buang.” Itu membuat saya sekali lagi sadar betapa bodohnya menilai orang dari bahasanya

  • Kebangkitan Rails dan kemunduran J2EE yang terjadi bersamaan bukan kebetulan. Rails menunjukkan kode backend yang sederhana dan punya opini yang jelas, dan pengaruhnya melahirkan framework Java seperti DropWizard, Javalin, dan Spring Boot
  • Saya penasaran seperti apa stack teknologi senior itu
  • Rasanya saya ingin mengambil isi tempat sampah rekan seperti itu. Sulit menemukan pengembang Rails yang bagus. Saya juga punya pengalaman RoR dan masih menyukainya
  • Tentu saja, jika Anda sedang mencari pengembang Java, mungkin efisien untuk menyaring CV Rails
  • Pada akhirnya, standar menilai orang bergantung pada kecocokan budaya organisasi dan gaya kolaborasi. Tidak ada metode penyaringan yang sempurna

• Bahasa atau library pada akhirnya adalah alat komunikasi baik dengan mesin maupun manusia. Mesin berkomunikasi lewat bit dan tegangan, manusia lewat niat dan konsep. Jadi jika sebuah bahasa atau library memberi manusia cara yang jelas dan cepat untuk mengekspresikan sesuatu, tidak penting apakah itu bahasa atau library. Rails atau Stanza, kalau cocok untuk tujuannya dan mudah dipahami tim, itulah jawaban yang benar

• Saya menganggap “library adalah bahasa akhir”. Misalnya Ruby on Rails adalah bahasa yang hebat untuk layanan web yang dibangun di atas Ruby. Ruby dan Rails berkembang saling mendukung. Pada akhirnya, saya melihat pemrograman sebagai proses penerjemahan bahasa yang berkesinambungan

  • C# dan ASP.NET Core juga berkembang dengan cara serupa. Sintaks yang ramah pengguna dan optimisasi level sistem berkembang bersamaan

• Pernyataan “semakin kuat bahasanya, semakin mudah memakai library” memang benar. Dulu sulit membuat framework seperti Express di Java lama

  • Saya tidak tahu apa itu Express, tetapi menurut saya Java berhasil menjadi bahasa enterprise berkat kemampuan memanfaatkan library
  • ASP.NET Core minimal API di C# adalah contoh yang hampir mereplikasi Express apa adanya. Ini hanya mungkin jika bahasa dan framework berkembang bersama
  • Di Java juga ada framework mirip Express seperti Javalin. Masalahnya adalah komunitas tidak menginginkan kesederhanaan

• Kalau bicara framework web untuk bahasa C, bukankah itu PHP? ;)

  • Itu terdengar seperti lelucon yang terlalu memperluas konsep library