Menuju Perangkat Lunak yang Dapat Dipahami

• Pemrograman sulit dibaca, diuji, dan dipelihara, serta pemahaman proyek cenderung terkonsentrasi pada segelintir orang, sehingga alih-alih mengotomatiskan penulisan kode dengan LLM, dibutuhkan abstraksi yang mengurangi cakupan kebutuhan kode itu sendiri
• LLM telah menyebar ke pengembang maupun non-pengembang, tetapi masalah seperti dampak merusak lingkungan, berbasis pada kode curian, hasil yang tidak konsisten, dan menimbulkan ketergantungan masih sangat besar
• Titik berangkatnya adalah membalik kebiasaan menulis kode terlebih dahulu lalu menambahkan dokumentasi, dengan beralih ke pemrograman literer yang mendahulukan dokumentasi dan membuat kode menyusul setelahnya
• Pemrograman visual berbasis GUI dan pemrograman bahasa alami yang deterministik dapat membuat kode menjadi hanya salah satu dari banyak representasi, tetapi dalam lingkungan visual, desain aksesibilitas seperti integrasi screen reader adalah hal yang wajib
• Upaya terdahulu seperti Eve dan Inform, serta alat seperti Entangled dan ReTangled, menunjukkan kemungkinan membangun perangkat lunak dengan cara yang dapat dipahami baik oleh pemula maupun pakar

---

LLM bukan model tujuan

• LLM telah menjadi alat penting dalam pengembangan perangkat lunak industri, dan bahkan para profesional berpengalaman memakai agen LLM untuk pengujian, debugging, dan penulisan kode
• Non-pengembang juga membuat berbagai hal dengan LLM, dari skrip pribadi hingga alat pemrosesan data ilmiah
  • Pemrograman sulit diakses karena titik mulainya tidak jelas, dan bagi orang yang tidak ingin mempelajari sintaks bahasa tertentu serta detail library, hambatannya tinggi
• Penyebaran LLM bukan terutama karena LLM sangat hebat dalam pemrograman, melainkan lebih merupakan sinyal bahwa pemrograman itu sendiri adalah pekerjaan yang rumit dan tidak menyenangkan
  • Ada software stack yang saling bertabrakan, boilerplate yang tak ada habisnya, dan library yang rewel
  • Pekerjaan pengembang perangkat lunak rata-rata menyusut menjadi merangkai library alih-alih mengembangkan kode yang menarik
• LLM masih menyisakan masalah besar
  • Merusak lingkungan
  • Pada dasarnya dibangun di atas kode curian
  • Menghasilkan kode yang tidak konsisten
  • Menanamkan ketergantungan
• Paradigma pemrograman saat ini punya banyak kekurangan, tetapi LLM juga membutuhkan alternatif yang lebih baik

Mengabstraksikan, bukan mengotomatiskan

• Menolak LLM tidak berarti harus menolak otomatisasi, abstraksi tingkat tinggi, dan antarmuka yang ramah manusia
• Tujuannya bukan berhenti pada mempermudah penulisan kode, melainkan menangani software stack di bawah kode dan mengurangi kebutuhan untuk menulis kode itu sendiri
• Jika sebuah lapisan abstraksi terus-menerus ingin Anda otomatisasi, arah yang lebih tepat adalah mengabstraksikannya hingga hilang alih-alih sekadar mengotomatiskannya
• Fenomena luasnya penggunaan LLM dalam pemrograman menunjukkan keinginan untuk mengotomatiskan proses penulisan kode, dan ini adalah sinyal bahwa kebutuhan menulis kode itu sendiri harus diabstraksikan
• Alih-alih memaksa manusia berpikir seperti komputer, dibutuhkan lapisan abstraksi baru yang lebih dekat dengan cara manusia berpikir secara alami

Pemrograman dengan dokumentasi lebih dulu

• Langkah pertama menuju perangkat lunak yang dapat dipahami adalah dokumentasi
  • Jika ingin orang lain memahami perangkat lunak, Anda harus menjelaskannya
• Cara umum saat ini adalah menulis kode terlebih dahulu, lalu menambahkan doc-comment atau contoh penggunaan belakangan
• Pendekatan yang diusulkan adalah membalik urutan itu: menulis dokumentasi lebih dulu, lalu menambahkan kode setelahnya
  • Menjelaskan kepada manusia apa yang dilakukan program, lalu memberi tahu komputer apa yang harus dilakukan
  • Konsep ini dikenal sebagai pemrograman literer
• Dalam pendekatan ini, alih-alih langsung membaca kode orang lain dan menebak niatnya, kita membaca dokumentasinya lebih dulu untuk memahami maksudnya, lalu memeriksa kodenya
• Entangled adalah implementasi yang baik untuk pendekatan ini
  • Sebuah tangler dua arah yang mengekstrak kode dari dokumen dan menempatkannya ke file source code yang sesuai
  • Blok kode di dalam dokumen dapat diedit, dan perubahan yang dibuat di file kode biasa juga dipropagasikan ke blok kode dalam dokumen
  • Alat yang sudah ada seperti pengujian, refactoring, dan formatting kode tetap bisa dipakai tanpa dukungan khusus untuk pemrograman literer
  • Tangler menambah overhead yang kecil pada build system, dan terutama sangat kecil jika dibandingkan dengan compiler
• Pendekatan ini tidak menghapus kompleksitas kode itu sendiri, tetapi dapat menggantikan LLM dalam ranah memahami kode orang lain

Menghapus kode: GUI dan banyak representasi

• Kode adalah konsep dari era lama, dipakai karena dulu kita harus berinteraksi dengan komputer melalui terminal
• Walaupun komputasi telah berubah selama 40 tahun terakhir, tidak ada alasan untuk bersikeras bahwa kita hanya boleh berkomunikasi dengan komputer melalui string satu dimensi berisi simbol dan kata kunci yang ambigu
• GUI sering membuat konsep yang kompleks lebih mudah ditangani daripada antarmuka berbasis teks, dan kerap lebih mudah diakses oleh pengguna baru
• IDE bisa menjadi cara baru untuk berinteraksi dengan pengembangan perangkat lunak, bukan sekadar tempat nyaman untuk mengedit kode
  • Beberapa IDE sudah menawarkan kemampuan seperti ini
  • Lebih jauh lagi, pemrograman visual bisa menjadi cukup umum dan sederhana sehingga siapa pun dapat membuat hal yang mereka inginkan tanpa harus belajar kode
• Tidak perlu sepenuhnya meninggalkan kode itu sendiri
  • Representasi GUI bisa menjadi salah satu dari banyak representasi yang dapat diedit manusia
  • Seperti halnya ada orang yang lebih menyukai antarmuka sistem operasi berbasis teks, akan tetap ada orang yang lebih memilih pengeditan perangkat lunak berbasis kode
  • Hanya saja, kode tidak harus menjadi pilihan default atau satu-satunya pilihan
• Pemrograman visual dapat dirancang agar lebih mudah diakses, tetapi lingkungan yang berpusat pada visual bisa berujung pada pengecualian penyandang tunanetra
  • Diperlukan integrasi screen reader yang kuat
  • Diperlukan juga representasi alternatif yang kaya secara audio atau taktil agar dapat dipahami

Menjadikan bahasa alami sebagai abstraksi deterministik

• Berbeda dari anggapan bahwa LLM menaikkan satu tingkat lapisan abstraksi, LLM sebenarnya lebih dekat ke lapisan otomatisasi daripada abstraksi
• Lapisan abstraksi harus dapat diprediksi dan diandalkan, dan niat tingkat tinggi harus diekspresikan secara tepat dan konsisten pada tingkat yang lebih rendah
• LLM bekerja tidak dapat diprediksi karena menafsirkan prompt secara probabilistik dan menebak niat
  • Ia mengotomatiskan proses yang secara acak mengaproksimasi hasil kerja
  • Jika ini disebut abstraksi, maka itu lebih mirip abstraksi dengan kehilangan informasi yang sangat besar
• Kemajuan dalam pemrosesan bahasa alami (NLP) membuka kemungkinan membangun pipeline yang dapat diprediksi dari bahasa alami ke bahasa mesin
• Tujuannya adalah memungkinkan input seperti prompt LLM, tetapi menghasilkan program yang dapat diprediksi dan kokoh setiap kali
  • Bukan menyarikan pekerjaan orang lain seperti rata-rata dari kode curian, melainkan membangunnya langsung lewat definisi
• Pendekatan ini dapat mengikat dokumentasi dan kode dengan lebih kuat
  • Jika bagian kode dalam pemrograman literer diganti dengan bahasa alami, yang tersisa bisa jadi hanya dokumentasi
  • Tulisan yang menjelaskan cara kerja program kepada manusia pada saat yang sama juga bisa menjadi tulisan yang berkomunikasi dengan mesin
• Pemrograman bahasa alami ini harus bersifat deterministik
  • NLP dapat dipakai untuk mem-parsing makna dari tata bahasa tanpa kemampuan generatif model transformer
  • Tata bahasa yang telah di-parse dapat langsung diubah menjadi representasi perantara yang kemudian dikompilasi sesuai kebutuhan platform, seperti bahasa pemrograman lainnya
• Ini dibayangkan mirip Inform, tetapi dengan pengenalan sintaks yang lebih tinggi dan terhubung ke jaringan definisi yang lebih luas
• Berkat sifatnya yang deterministik, prompt dapat diubah menjadi kode secara andal dan konsisten; inilah lapisan abstraksi yang nyata, yang secara mendasar berbeda dari LLM

Upaya sebelumnya: Eve dan Inform

• Gagasan seperti ini bukan hal baru, dan sebelumnya sudah ada upaya implementasi
• Eve adalah bahasa pemrograman sekaligus IDE yang mencoba membuat pemrograman lebih mudah diakses manusia
  • Menggunakan pendekatan pemrograman literer
  • Menyisipkan bahasa pemrograman berorientasi data yang spesifik domain ke dalam dokumen yang menjelaskan perilaku perangkat lunak
  • Kode bergantung pada dokumen, dan seluruh lingkungan pemrogramannya juga mencerminkan hal itu
• Eve juga mencoba memperluas gagasan ini dengan mengganti bahasanya sendiri menggunakan kueri NLP
  • Saat itu belum siap menangani kompleksitas pemrosesan bahasa alami
  • Pada 2016, NLP yang lebih maju belum mudah diakses oleh perusahaan yang tidak berpusat pada machine learning
  • Ia juga bereksperimen dengan pendekatan berorientasi GUI
• Mantan kontributor Eve juga membahas kekhawatiran serupa mengenai kompleksitas proyek dan keterbatasan LLM
• Eve berakhir karena merupakan proyek ambisius yang didanai VC namun gagal dimonetisasi, sehingga kita tidak sempat melihat gagasannya membuahkan hasil
• Inform adalah bahasa deklaratif untuk membuat fiksi interaktif, dan menunjukkan bahwa konsep seperti ini dapat diterapkan lebih luas
• Bahasa alami mungkin pada dasarnya adalah abstraksi yang bocor, tetapi potensinya untuk memungkinkan orang kebanyakan mengendalikan komputer mereka sendiri secara langsung layak mendapat perhatian yang lebih besar

Langkah berikutnya dan usulan pekerjaan

• ReTangled sedang dikembangkan sebagai proyek untuk membuat perangkat lunak yang dapat dipahami
  • Ini adalah tangler dua arah kompatibel Entangled yang ditulis dalam Rust
  • Tujuannya adalah memperluas pemrograman literer sejauh mungkin, dan mengintegrasikannya secara erat dengan toolchain yang ada pada tingkat yang masuk akal
  • Saat ini masih dalam tahap pengembangan awal dan kontribusi sangat disambut
• Ada rencana untuk menulis artikel yang lebih lengkap masing-masing tentang pemrograman visual, pemrograman literer, dan pemrograman bahasa alami
• Pada tingkat komunitas, usulannya adalah melanjutkan jejak Eve tetapi dengan pendekatan yang sedikit berbeda
• Tujuannya adalah membangun lingkungan pemrograman visual atau bahasa alami yang terdokumentasi dengan baik, mudah diakses, dan berguna dari pemula hingga pakar
• Titik mulainya adalah mendokumentasikan perangkat lunak dengan lebih baik, dan tujuan akhirnya adalah membalik konsep pemrograman itu sendiri

[GN⁺]

Komentar di Lobste.rs

• Saya tidak yakin apakah membuang kode atau membuatnya tunduk pada prosa bahasa alami adalah solusi efektif untuk masalah aksesibilitas dalam pemrograman
  Bahasa pemrograman adalah antarmuka pengguna yang menyeimbangkan kebutuhan komputer dan manusia. Notasi formal yang jelas dan dirancang dengan baik dapat menjadi alat berpikir yang membantu pemahaman pribadi serta penyampaian ide antara manusia dan mesin
  Saya sangat terpengaruh saat mempelajari bahasa keluarga APL. Memang butuh waktu untuk menguasainya, tetapi setelah mempelajarinya, saya bisa menampung masalah yang lebih besar di kepala dan berpikir dengan lebih presisi. K memungkinkan kita memecahkan masalah hanya dengan kepala, kertas, dan REPL sederhana, tanpa IDE yang rumit
  Proyek yang terdokumentasi dengan baik dan literate programming memang bernilai, tetapi dokumentasi juga membutuhkan waktu untuk dibaca, ditulis, dan diperbaiki. Seperti halnya pengujian, dokumentasi yang banyak tidak otomatis berarti baik; saya lebih suka penjelasan yang ringkas dan terstruktur serta program ringkas yang mudah dijelaskan. Kode bisa menjadi puisi, tetapi sebagian besar puisi bukanlah program

  • Saya menyukai pemrograman formal, tetapi tidak percaya bahwa pengguna rata-rata harus menjadi programmer agar bisa memakai kekuatan komputer
    Kebanyakan orang tidak akan mempelajari cara kerja internal seperti ini, jadi saya ingin menurunkan hambatan masuk agar lebih banyak orang bisa berpartisipasi
    Karena itu saya menganggap LLM populer. Saya sering melihat non-programmer menulis kode dengan LLM untuk menyelesaikan pekerjaan, tetapi seperti yang disebutkan dalam tulisan itu, LLM memiliki cacat besar yang ingin saya hindari. Orang seharusnya bisa memodifikasi game, membuat skrip, dan memperluas program dengan bahasa alami atau antarmuka pengguna yang nyaman
    Ungkapan “hapuskan kode” mungkin agak berlebihan, tetapi banyak orang tidak ingin memikirkan kode, dan seharusnya mereka juga tidak perlu melakukannya

• Para programmer pada dasarnya telah meninggalkan non-programmer
  Visual Basic sudah mati, PHP tanpa framework juga tampaknya tidak lagi ramai, dan Access secara praktis sudah mati. Yang tersisa adalah alat mirip database seperti Notion atau Airtable
  Programmer terlalu mencintai kegiatan menulis kode, sehingga banyak yang menjauh dari solusi sederhana untuk masalah sederhana
  Python pernah menyapu dunia non-programmer karena terlihat sederhana, dan alat seperti Pandas juga tampak mudah dipakai. Menariknya, banyak programmer menganggap Python atau Pandas kurang bagus. Misalnya, melihat kode yang memakai Pandas untuk hal yang bisa dilakukan dengan mudah memakai standard library cukup membuat jengah
  Dulu, non-programmer pun membuat halaman HTML dan menambahkan warna serta gambar. Sekarang, kalau meminta programmer membuat situs web statis, kompleksitas yang tidak masuk akal ikut terbawa. Sebagian memang perlu, tetapi kebanyakan sama sekali tidak perlu. Jika prosedur yang dipakai programmer saat ini untuk membuat situs web sederhana diberikan kepada non-programmer, bahkan orang-orang yang 20 tahun lalu menikmati mengedit HTML akan lari sambil menjerit
  Sangat ironis sekaligus mengkhawatirkan bahwa ada hal-hal yang justru menjadi jauh lebih sulit sekarang

  • Itu sama sekali tidak masuk akal. Sekarang pun siapa saja bisa menulis HTML, bahkan lebih mudah daripada dulu
    CSS menjadi lebih kuat, browser tidak lagi serusak dulu, dan ada asisten coding pribadi yang bisa membantu semuanya. Python murni juga sama saja, tinggal dipakai. Pemrograman lebih mudah daripada sebelumnya
    Kompleksitas stack teknologi modern biasanya ada alasannya, tetapi harus dipakai setelah alasannya muncul, dan pemula sama sekali tidak perlu memakainya
    Jika orang tidak membuat situs web HTML atau program dasar, itu karena mereka tidak ingin melakukannya. Dulu saya mengira di masa depan semua orang akan memahami pemrograman dasar, tetapi kenyataannya ternyata orang memang tidak mau melakukannya. Kita bisa saja berargumen bahwa orang juga seharusnya bisa melakukan perawatan dasar mobil atau sepeda, tetapi mereka menolaknya. Itu bukan berarti pekerjaannya sulit atau mustahil, melainkan lebih dekat ke tidak adanya kemauan untuk melakukannya
    Saya melihat kemampuan komputer masyarakat umum hampir tidak berkembang, dan itu tidak terkait dengan kompleksitas pemrograman. Di dunia pendidikan bahkan ada yang mengatakan kemampuan komputer justru tampak mundur, tetapi sulit menganggap itu disebabkan oleh framework frontend yang kompleks

• Saya setuju dengan banyak bagian tulisan itu. Misalnya, saya menyukai literate programming, tetapi saya tidak berpikir pemrograman itu sendiri buruk
  Sebagian pemrograman memang buruk, dan pemrograman yang dilakukan di perusahaan BigTech umumnya sering buruk. Namun menulis program untuk diri sendiri atau orang-orang yang saya sayangi masih menyenangkan
  Saya belum tahu Entangled, tetapi idenya tampak bagus, dan ia menangani masalah terbesar dalam literate programming, yaitu LSP dan alat yang ada tidak mengenalinya. Karena itu sejauh ini saya terutama memakai literate programming untuk bahasa deklaratif seperti konfigurasi NixOS
  Jika literate programming dua arah, hidup mungkin menjadi lebih mudah saat memakai bahasa non-deklaratif. Saya berniat mencoba ReTangled

  • Pemrograman tidak buruk. Sampai kalimat itu saya setuju dengan penulis, tetapi ketika muncul bagian “mari menerima GUI”, minat saya memudar
    GUI terutama tampak ada untuk membuat eksekutif ke atas percaya bahwa karyawan sedang melakukan sesuatu yang bisa mereka pahami dan lakukan sendiri
    Saya pernah mengikuti kelas alat ETL visual drag-and-drop, dan yang tersisa hanya pikiran bahwa akan sulit membuat ulang sesuatu yang hampir sama dengan sistem pertama serta sulit melakukan version control untuk keseluruhannya. Sistem pengganti cron visual drag-and-drop yang dipakai perusahaan saya pada 2010 juga serupa
    Bagi eksekutif, drag-and-drop itu mudah, tetapi bagi praktisi, mencari kesalahan, menjaga versi dan backup, serta penggunaan ulang menjadi sulit
  • Jika fungsi itu adalah tujuan utama, saya menyarankan memakai Entangled sampai stitching berfungsi di ReTangled
  • Ada bagian yang benar-benar berat dalam proses menaikkan sesuatu yang menyenangkan dipakai dari waktu ke waktu menjadi sesuatu yang mungkin disukai pengguna
    Untuk menjadikan prototipe yang menarik layak dijalankan di produksi, dibutuhkan banyak penanganan kesalahan, serialisasi, deserialisasi, proyeksi tipe, dan sebagainya. Salah satu aturan saya adalah pengalaman pengguna yang hebat hampir selalu disertai struktur internal yang berantakan
    Secara pribadi saya tidak menikmati sebagian besar hal itu, dan dulu saya pernah mengambil jalan pintas atau bahkan tidak mengerjakan bagian itu sama sekali

• Sangat setuju. Jika melihat editor WYSIWYG, memang tidak sepenuhnya menggantikan pengembangan web, tetapi berhasil mengurangi ceruk yang cukup besar bagi orang-orang yang hanya menginginkan situs web dasar atau penjualan produk sederhana
  Masih ada banyak area perangkat lunak yang bisa dibuat lebih sederhana dengan antarmuka GUI yang baik
  Jika sekarang kita hanya menyambung-nyambungkan kode atau menjalankan LLM secara sembarangan, sebenarnya pemrograman GUI mungkin bisa lebih baik. Kode yang sering saya pakai pun banyak berupa server REST, dan tidak ada alasan kita tidak bisa membuat sesuatu untuk hal seperti itu

• Kita berbagi tujuan yang sama, dan selama bertahun-tahun saya memikirkan stack teknologi yang bisa menyediakan solusi persis seperti yang ingin saya gunakan
  Saya memang telah merilis sebuah proyek bernama Curv, tetapi itu hanya sebagian kecil dari sistem yang jauh lebih indah yang masih ada di kepala saya
  Ribuan orang lain juga telah bergulat dengan masalah ini. Melihat skalanya, tampaknya diperlukan kerja tim, tetapi pada kenyataannya kebanyakan berupa proyek kecil satu orang. Orang dengan visi paling kuat sering kali tidak ingin mengompromikan visinya demi tujuan tim. Saya tidak tahu bagaimana cara menyelesaikan ini
  Proyek-proyek yang menginspirasi antara lain visi Dynabook dari Alan Kay, Smalltalk yang berlanjut dari sana, proyek lanjutan Alan Kay yaitu STEPS Toward the Reinvention of Programming, karya Bret Victor, terutama pencapaiannya yang luar biasa, Dynamicland
  Komunitas yang tertarik pada topik ini antara lain Feeling of Computing, yang dulu disebut Future of Coding. Kalau ada tambahan lain, beri tahu saya

• Gagasan “membuat program lengkap dengan memasukkan instruksi seperti ke prompt LLM, tetapi membuatnya bekerja secara dapat diprediksi dan kokoh setiap kali” bertumpu pada asumsi besar bahwa kita bisa mem-parse semantik yang deterministik dan konsisten dari bahasa alami
  Namun sejak awal saya tidak yakin itu benar. Terlepas dari masalah bahwa sejauh ini belum pernah benar-benar berhasil dijalankan, saya juga ragu apakah itu mungkin
  Bahasa memiliki terlalu banyak konteks. Kalimat yang sama, meski diucapkan dua belas kali, akan memiliki makna yang sedikit berbeda setiap kali tergantung intonasi, audiens, lokasi fisik, medium ujaran, dan waktu. Teknik pemrosesan bahasa alami tradisional pada dasarnya tidak mampu menangani fleksibilitas semacam ini
  Justru karena itulah LLM ada. Alih-alih mencoba menetapkan aturan konteks yang ketat—yang mungkin memang tidak ada—pendekatannya adalah melatih model yang dapat mengodekan deteksi konteks ke dalam bobot. Ternyata ini bekerja dengan sangat mengejutkan
  Itu juga alasan orang memakai LLM. Dibanding antarmuka bahasa alami apa pun yang pernah dibuat sejauh ini, LLM jauh lebih baik dalam mempertimbangkan konteks dan menghasilkan respons yang diharapkan. Dari sudut pandang itu, LLM memang benar-benar bekerja. Pemrosesan bahasa alami di luar LLM belum menunjukkan tingkat keberhasilan yang sama

• Jika tertarik pada lingkungan pemrograman visual yang kaya, Glamorous Toolkit adalah contoh bagus yang menunjukkan salah satu arah yang mungkin https://gtoolkit.com/
  Saya belum menganggapnya sebagai bentuk final, tetapi ini adalah alat yang mendorong lebih jauh hal-hal yang sudah ada. Di era kode yang dihasilkan LLM, lingkungan berbasis gambar juga layak dibicarakan

  • Saya menelusuri situs web Glamorous Toolkit, tetapi sama sekali belum menangkap apa sebenarnya itu. Bisa dirangkum dalam beberapa kalimat?

• Yang kurang adalah abstraksi yang dapat diprediksi yang melampaui elemen primitif yang umum dipakai programmer saat ini, yaitu baris-baris kode yang diorganisasi ke dalam fungsi dan modul
  Terutama ketika kebutuhan untuk memodelkan sistem eksternal yang kompleks, bukan sekadar transformasi data sederhana, dipindahkan hanya dengan elemen-elemen seperti itu, hasilnya akan menjadi bola lumpur yang terus membesar bahkan bila dibuat oleh programmer manusia. LLM juga sedang meniru bentuk itu