Hurl, Bahasa Pemrograman yang Tidak Biasa

• Hurl adalah bahasa pemrograman eksperimental yang menyusun alur kontrol hanya dengan penanganan pengecualian, alih-alih percabangan atau perulangan biasa
• Hurl bermula dari percakapan antara Nicole Tietz-Sokolskaya dan teman-temannya di Recurse Center, dan situsnya menyediakan dokumentasi penggunaan, contoh, panduan debugging, serta tanya jawab
• Testimoni di halaman pengantar sengaja menonjolkan nuansa bercanda, dengan kutipan seperti “monstrosity is beautiful” dan “Certified unhinged™”
• Hurl dan kode sumber situsnya dibuka untuk publik, tetapi untuk mengirim patch lewat email diperlukan pengalihan hak atas patch
• Lisensinya ditawarkan dengan skema memilih salah satu dari AGPL-3.0, GAL-1.0, atau lisensi komersial

---

Eksperimen bahasa yang hanya menyisakan penanganan pengecualian

• Hurl dibuat untuk satu tujuan: mengeksplorasi apakah mungkin ada bahasa yang tersusun hanya dari alur kontrol berbasis penanganan pengecualian
• Ide ini muncul dari percakapan antara Nicole Tietz-Sokolskaya dan teman-temannya di Recurse Center, dan identitas teman-teman tersebut tidak diungkap “demi martabat”
• Situs ini menyediakan dokumentasi penggunaan Hurl, contoh, panduan debugging, dan tanya jawab

Terlihat seperti lelucon, tetapi benar-benar proyek yang dirilis

• Halaman pengantar memuat testimoni yang menunjukkan karakter Hurl
  • “This monstrosity is beautiful, and I must never touch it”
  • “Certified unhinged™!”
  • “is "🤮" an available quote?”
• Jika ingin memuat testimoni tambahan, Anda harus mengirim email ke Nicole, dan diperlukan persetujuan eksplisit untuk menyertakan kutipan

Kode sumber dan ketentuan lisensi

• Bahasa Hurl dan kode sumber situs ini dipublikasikan di repo Hurl
• Jika menemukan bug atau kesalahan, Anda dapat mengirim patch lewat email, tetapi harus menyerahkan semua hak atas patch tersebut
  • Ini adalah syarat untuk mempertahankan kemungkinan relisensi dan lisensi komersial
• Proyek ini dapat digunakan dengan memilih salah satu dari tiga lisensi berikut

  • AGPL-3.0

    • GAL-1.0: Gay Agenda License
    • lisensi komersial
    • Dalam proses peninjauan lisensi, joke licenses dan unfortunate licenses juga dipertimbangkan, tetapi akhirnya dipilih tiga lisensi di atas

[GN⁺]

Komentar Hacker News

• Kalau merancang bahasa pemrograman, sebaiknya paksa namespace untuk include/import, dan kalau bisa cegah juga efek samping di level teratas
  Lebih mudah disimpulkan kalau menerimanya seperti let foo = include "lib/foo.hurl" lalu memanggil foo.init()
  Sebaliknya, kalau setelah include "lib/foo.hurl" // side effects muncul baz(buz), sulit tahu apakah fungsi dan variabel itu dari standard library atau di-include dari suatu tempat

  • Jika tidak ada binding nama eksplisit, lebih baik paksa pernyataan import dan namespace-nya cocok
    import "foo/bar" semestinya membuat foo.* atau bar.* bisa dipakai, bukan malah bazz.*. Langsung teringat Go
  • Bukan berarti saya tidak setuju, tetapi IntelliJ yang saya pakai di pekerjaan menunjukkan dengan jelas sebuah referensi di-import dari mana, dan bisa lompat ke sana dengan shortcut
    VSCode juga bisa melakukan hal serupa dengan plugin dan LSP, tapi jauh lebih buruk. Navigasi kodenya terlalu lambat, jadi saya tidak bisa bekerja dengan VSCode
    Saya penasaran apakah usulan seperti ini hanya berguna ketika alat semacam itu tidak ada. Setidaknya di lingkungan profesional, tampaknya mustahil hidup tanpa alat seperti itu
  • Dengan begini, parameter bisa diteruskan ke foo.init(), sesuatu yang mustahil dengan import polos
  • Kalau sebuah bahasa alur kontrolnya berpusat pada exception, sepertinya kapal “mudah disimpulkan” sudah telanjur berlayar
    Bukan berarti proyek ini tidak bernilai; justru saya melihatnya sebagai karya seni
  • Setuju 100%
    Saya pernah mem-fork Ruby dan membuat require tidak menimpa symbol table, tetapi ekosistem Ruby tampaknya terlalu bergantung pada shared global mutable state, sehingga akhirnya saya kehilangan minat pada Ruby itu sendiri

• Exception selalu terasa kurang bagus karena membuat kontrak antara caller dan callee sulit dipahami serta meningkatkan coupling kode
  Saya lebih suka pendekatan seperti Go atau Rust yang menanganinya lewat nilai kembalian. Saat melihat sekilas bahasa ini, saya belum yakin apakah ada elemen yang menyelesaikan masalah tersebut
  Model seperti ini mungkin baik-baik saja jika IDE bisa secara dinamis mengetahui semua exception yang tidak tertangkap dari sebuah fungsi, lalu memungkinkan lompat ke lokasi tempat exception dapat dilempar. Namun saya tidak tahu bagaimana coupling-nya ditangani, dan control-flow graph sepertinya akan menjadi sangat tidak stabil

  • Di Java, IntelliJ melakukan persis hal itu. Jika ada fungsi yang melempar exception dan tidak ditangkap oleh caller di suatu tempat dalam proyek, ia menandainya sebagai masalah, dan kita bisa mudah berpindah ke implementasi atau lokasi pemanggilan
    Namun di Java, selama tidak mewarisi RuntimeException, exception yang dapat dilempar fungsi adalah bagian dari signature fungsi. Jika melempar exception tanpa menambahkannya ke signature dalam kasus seperti itu, kodenya tidak akan dikompilasi
    Kondisi di Java membuat IDE jauh lebih mudah melaporkan exception yang tidak tertangkap, tetapi untuk exception non-runtime ini adalah masalah yang bisa diselesaikan dengan analisis statis
    Sebaliknya, pendekatan mengembalikan nilai terbungkus Ok/Err yang distandardisasi tampaknya lebih sederhana baik dari sisi dukungan tooling maupun kenyamanan developer
  • Secara harfiah tidak ada perbedaan antara melempar exception dan mengembalikan exception sebagai variabel
    Satu-satunya perbedaan adalah pada mekanisme penerusan exception, Anda harus menulis sendiri kode boilerplate yang seharusnya bisa dilakukan compiler
    Saya benar-benar tidak paham mengapa pada 2024 orang dengan kepala yang berfungsi normal ingin melakukannya secara manual
  • Saya mungkin akan lebih menyukai Go andaikan ia tidak secara alami menelan konteks error
    Selama saya menggunakannya, menemukan akar penyebab tanpa debugger jauh lebih menyakitkan

• Contoh toss disebut “terutama dipakai untuk mengirim beberapa nilai ke luar fungsi, tidak benar-benar diperlukan tetapi lucu”, padahal jauh dari tidak berguna; itu mengimplementasikan generator yang dapat dilanjutkan
  Tentu saja, akan cukup menarik jika dibuat melakukan hal lain selain langsung melanjutkan. Cukup susun seluruh codebase sebagai stack dalam-luar toss

  • Tidak persis sama. Generator yang dapat dilanjutkan bisa dilanjutkan di titik mana pun nanti dalam program, tetapi di sini return harus ber-scope secara leksikal ke handler
    Misalnya di Python, next() bisa dipanggil dari mana saja
    Ini lebih mirip meneruskan callback lewat kanal samping. toss memanggil callback itu, dan return secara harfiah kembali dari sana
  • Itu juga persis pikiran pertama saya setelah membacanya
    Rasanya agak seperti lelucon bahwa fitur yang benar-benar berguna di bahasa lain diperlakukan di sini seperti fitur lucu yang bisa dibuang
  • Ini lebih mirip propagasi event berbasis stack
  • Apakah ini seperti yield di C#?
  • Pikiran pertama saya juga sama. Bahasa kecil yang keren dengan generator, lumayan

• Hurl terlihat cukup dekat dengan condition system ala Smalltalk atau Common Lisp
  Stack unwinding dan resume hanyalah dua dari beberapa restart yang mungkin: https://gigamonkeys.com/book/beyond-exception-handling-condi...

• Terlepas dari proyeknya sendiri, saya sangat yakin dunia akan menjadi lebih baik jika lebih banyak hal memakai ekstensi .wtf untuk domain

• Ini terdengar seperti bentuk lemah dari algebraic effects, tetapi tetap keren melihat bahasa seperti ini dan apa yang bisa dilakukan dengannya

  • Saya tidak pernah memahami algebraic effects, tetapi dokumentasi Hurl bisa saya pahami
    Jika algebraic effects pada dasarnya seperti kata kunci toss di Hurl, saya penasaran dalam hal apa ia lebih kuat daripada toss

• Eksperimen pikiran yang menarik
  Saya sangat tidak suka exception, dan menginginkan bahasa tanpa exception
  Exception adalah goto zaman kita
  Dengan adanya Maybe/Option dan Effect/Result, hampir tidak ada alasan untuk melempar exception lalu harus melacak di kepala di mana ia ditangani
  Saya agak khawatir algebraic effects akan makin populer dan memengaruhi JS frontend yang sudah terlalu rumit, karena ia mendorong cara melempar “exception” untuk alur kontrol
  Jika semua ini bertujuan menghindari masalah warna async/sync, bagi saya pribadi itu sama sekali tidak sepadan

• Wah, saya tidak suka ini. Tapi anehnya ada sisi yang hampir elegan
  Sangat sulit dimodelkan di kepala, tetapi tetap begitu
  Sedikit lebih serius, saya berharap ada sintaks catch yang berbeda untuk exception yang dapat dilanjutkan dan yang tidak dapat dilanjutkan. Dengan begitu ambiguitas sintaksis tentang apakah return mengembalikan alur kontrol ke sisi pelempar dari exception langsung terdekat atau tidak akan hilang
  Dan standard library tidak boleh kabur ke fungsi yang mengembalikan nilai biasa. Jangan menolak memakan masakan sendiri hanya karena ternyata bikin mulas

  • Benar. Namun sebagai alternatif lain, ketika memanggil fungsi di posisi tempat nilai diharapkan, sintaksnya bisa dibuat otomatis melakukan catch

• Apakah pemahaman saya benar bahwa yang di-hurl bisa ditangkap tetapi yang di-toss tidak bisa? Sepertinya perlu waktu untuk terbiasa
  Saya juga khawatir berapa banyak Hurl yang harus saya tulis sebelum orang mulai memanggil saya tosser

• Toss terdengar seperti konstruksi bahasa yang menarik. Ia berjalan naik di stack untuk mencari exception handler, lalu kembali ke posisi semula dan melanjutkan eksekusi seolah tidak terjadi apa-apa
  Dengan konstruksi ini, tampaknya perilaku tambahan bisa disuntikkan saat runtime
  Dalam kode berorientasi objek biasanya dependency injection dilakukan lewat constructor service, tetapi apakah toss memungkinkan hal itu lewat “toss handler”?

  • Lihat Koka. Itu bahasa “sungguhan” dengan sistem algebraic effects
    https://koka-lang.github.io/koka/doc/book.html#why-handlers
  • Cukup mirip dengan condition system di Common Lisp
    Saya tidak banyak tahu, tetapi saya tahu bahwa sistem seperti ini memungkinkan penyuntikan perilaku saat runtime
  • Mirip Resume Next di VB