Bahasa kecil adalah masa depan pemrograman

Apa itu "Little Language"?

• "Bahasa kecil" adalah bahasa yang dibuat dengan tujuan menyelesaikan masalah tertentu
  → SQL, RegEx, Dhall,..
  → Juga disebut sebagai DSL

Mengapa bahasa kecil diperlukan?

• Seiring aplikasi menjadi jauh lebih kompleks, source code juga membesar dan makin sulit dipahami
• Onboarding karyawan baru menjadi sulit, kurangnya pemahaman terhadap dependensi bisa menimbulkan error, dan perubahan kode makin sulit dikelola
• Dalam 10 tahun terakhir, codebase telah membesar 100~500 kali lipat
  • Kernel Linux dimulai dari 10 ribu baris pada 1992, tetapi 20 tahun kemudian menjadi 30 juta baris
• Kode seperti ini bukan hanya karena "fiturnya bertambah banyak". Ini juga karena cara kita membuat software telah berubah
  • Software mirip membangun piramida: untuk meletakkan batu terakhir, dibutuhkan lebih banyak batu di bawahnya

Mengatasi tren ini

• Apakah benar untuk membuat OS modern kita harus menulis ratusan juta baris kode?
• Alan Kay menantang asumsi ini dalam program STEPS pada 2006

• Kami berpikir bahwa membuat 'bahasa' yang sesuai dengan masalah yang ingin diselesaikan akan mempermudah pemecahan masalah, serta membuat solusi lebih mudah dipahami dan lebih kecil

• Di STEPS, mereka membuat bahasa bernama Nile, dan merancang renderer Cairo 44.000 baris agar menjalankan fungsi serupa dengan sekitar 300 baris kode

Mengapa bahasa tingkat tinggi saja tidak cukup?

• Mengapa tidak cukup membuat bahasa umum yang levelnya lebih tinggi?
• Secara pribadi, saya merasa kita sudah mencapai diminishing returns pada daya ekspresi bahasa umum
• Seperti apa bahasa yang lebih tinggi itu? Jika memakai Python sebagai contoh, levelnya sudah sangat tinggi hingga terlihat seperti pseudocode
• Masalah bahasa umum adalah Anda harus menerjemahkan masalah Anda menjadi algoritme, lalu mengekspresikan algoritme itu dalam bahasa target
  • Dalam Programming Pearls karya Jon Bentley pada 1986, ia pernah mengundang Donald Knuth dan Doug Mcllroy yang terkenal untuk menulis program penghitung frekuensi kata. Don menulisnya sepanjang 10 halaman dalam WEB, varian Pascal, lengkap dengan struktur data yang kompleks
  • Sebaliknya, Doug membuatnya dengan sintaks pipe Unix 6 baris memakai tr, sort, uniq, sort, sed, dan lainnya

Lebih sedikit lebih baik: Less is More

• Perintah Unix di atas menunjukkan karakteristik lain dari bahasa kecil.
  "Bahasa yang kurang kuat dan runtime yang lebih kuat"
• Gonzalez membahas tren ini dalam "The end of history for programming"
  • Mendorong problem domain ruang pengguna ke problem runtime
    • Membuat program menjadi mirip ekspresi matematis murni, sambil sangat meningkatkan kompleksitas runtime
• Regular expression dan SQL masing-masing tidak bisa mengekspresikan apa pun selain pencarian teks dan pekerjaan basis data
• Ini berlawanan dengan bahasa seperti C yang tidak memiliki runtime dan dapat mengekspresikan segalanya
• Bahasa kecil berada di ujung berlawanan dari spektrum kekuatan yang dimiliki C
  • Bukan hanya arsitektur komputer yang diabstraksikan, tetapi juga jenis program yang dapat diekspresikan dibatasi, sehingga secara desain bersifat Turing-incomplete
  • Ini mungkin terdengar sangat membatasi, tetapi membuka dimensi baru kemungkinan untuk optimisasi dan analisis statis

Analisis statis

• Bahasa yang kurang kuat lebih mudah ditalar dan dapat memberikan jaminan yang lebih kuat daripada bahasa umum
• Misalnya, Dhall adalah "Total Functional Programming Language" untuk menghasilkan file konfigurasi
  • Artinya, untuk menghilangkan risiko infinite loop, program Dhall "dijamin" "(1) tidak crash, dan (2) selesai dalam waktu terbatas"
  • (1) dicapai dengan tidak melempar exception. Perintah yang bisa gagal mengembalikan hasil Optional (nilai bisa ada atau tidak ada)
  • (2) dicapai dengan tidak mengizinkan definisi rekursif
• Dalam bahasa fungsional lain, rekursi adalah cara dasar untuk mengimplementasikan loop, tetapi Dhall harus mengandalkan fungsi fold bawaan
• Tidak adanya struktur loop umum berarti Dhall tidak Turing-complete. Namun ini bukan bahasa tujuan umum, jadi memang tidak perlu
• Jika bahasanya kecil, penalarannya jauh lebih mudah
  • Misalnya, sulit memastikan apakah program Python tidak memiliki efek samping lain, tetapi di SQL cukup memeriksa apakah query dimulai dengan SELECT
• Dalam kasus Nile, tim STEPS membutuhkan graphical debugger sehingga mereka membuatnya, dan bisa dilihat langsung
  • Hal seperti ini dimungkinkan karena Nile adalah bahasa kecil yang mudah ditalar

Kebutuhan akan kecepatan

• Bahasa pemrograman yang lebih kuat tidak hanya meningkatkan kemungkinan bug, tetapi juga bisa merugikan performa
• Misalnya, jika program tidak diekspresikan sebagai algoritme, runtime dapat memilih algoritme sendiri
  • Ekspresi yang lambat bisa diganti dengan yang cepat (dengan asumsi bisa dibuktikan menghasilkan hasil yang sama)
• Sebagai contoh, query SQL tidak memberi instruksi bagaimana query itu harus dieksekusi
  • Database engine bebas menentukan query plan mana yang paling sesuai
    • Apakah memakai indeks, indeks gabungan, atau memindai seluruh tabel DB
  • Database engine modern juga mengumpulkan statistik distribusi nilai tiap kolom, sehingga dapat memilih rencana query yang optimal secara statistik saat itu juga
  • Jika query ditulis dalam bentuk algoritme, hal seperti ini tidak mungkin dilakukan
• Salah satu "secret sauce" yang membuat bahasa Nile sangat ringkas adalah "Jitblt", compiler Just-in-Time untuk graphic rendering
  • Melalui diskusi antara tim STEPS dan tim Cairo, mereka mengetahui bahwa banyak kode Cairo dipakai untuk mengoptimalkan pekerjaan compositing piksel secara manual
  • Secara teori, pekerjaan ini bisa di-offload ke compiler
  • Dan Amelang dari tim Cairo kemudian secara sukarela mengimplementasikan compiler seperti ini, yaitu Jitblt
  • Artinya, pekerjaan optimisasi di graphics pipeline bisa dipisahkan dari deskripsi matematis murni tentang apa yang akan dirender,
    dan dengan begitu Nile dapat berjalan secepat kode Cairo asli yang dioptimalkan dengan tangan

Small languages, Big Potential (bahasa kecil, potensi besar)

• Jadi, bagaimana akhir dari STEPS? Apakah mereka berhasil membuat OS yang bisa berjalan dengan kode yang muat dicetak di kaos?
• Hasil akhir STEPS adalah KSWorld
  • OS lengkap dengan editor dokumen dan editor spreadsheet bawaan
  • 17.000 baris kode
  • Mungkin masih sedikit terlalu panjang untuk muat di kaos, tetapi menurut saya ini tetap sukses
• Lahirnya KSWorld menunjukkan bahwa "bahasa kecil" punya potensi besar
• Namun, masih banyak pertanyaan yang belum terjawab
  • Bagaimana bahasa-bahasa ini akan saling berkomunikasi?
  • Haruskah semuanya dikompilasi ke representasi perantara yang sama?
  • Atau haruskah runtime yang berbeda hidup berdampingan dan berkomunikasi lewat protokol standar (seperti pipe Unix, TCP/IP)?
  • Atau justru tiap bahasa cukup kecil sehingga bisa diimplementasikan ulang di banyak host language?
  • Atau mungkin kombinasi dari semua itu adalah arah yang harus dituju?
• Bagaimanapun, saya yakin kita perlu menemukan cara lain untuk membangun software
  • Mungkin "bahasa kecil" akan menjadi bagian dari kisah itu
  • Yang penting, kita tidak boleh terus menumpuk lebih banyak bata di atas masing-masing fondasi terlalu lama, sampai kita masih mampu memikirkan sesuatu yang lebih baik

[ide127]

"
Kami berpikir bahwa membuat 'bahasa' yang sesuai dengan masalah yang perlu kita selesaikan akan mempermudah penyelesaian masalah, serta membuat solusi lebih mudah dipahami sekaligus lebih kecil.
"

Setelah membaca bagian ini, kesan yang saya dapat adalah, pada akhirnya apakah yang dimaksud dengan 'bahasa kecil' itu sebenarnya sama maknanya dengan framework? Seperti contoh JavaScript -> React, yang memaksa penggunaan fungsi dan design pattern yang sering dipakai lalu menjadikannya semacam tata bahasa.

[chicol]

Topik yang menarik.

[kunggom]

Ngomong-ngomong, saya baru-baru ini menemukan alat pembuat DSL bernama MPS(Meta Programming System) yang dibuat oleh JetBrains.
Ternyata ini produk yang usianya sudah cukup lama, lebih dari yang saya kira. Karena tertarik, saya sempat ingin melihatnya lebih jauh, tetapi terus tertunda karena berbagai hal. Kalau ada yang pernah memakainya, saya ingin sekali mendengar ulasan atau pengalaman penggunaannya.

[uglyduck68]

Wow, terima kasih

[nicewook]

Terima kasih, saya membacanya dengan baik.

[roxie]

Lisp tersenyum lebar

[xguru]

Menurut saya ini cerita yang menarik, jadi saya bagikan terjemahannya.