Pandangan John Carmack tentang variabel yang dapat diubah

• John Carmack membagikan pandangan pribadinya tentang penggunaan variabel yang dapat diubah (mutable variable)
• Ia menyebut bahwa saat menggunakan Python, ia jadi cenderung mengabaikan prinsip single assignment, dan mengatakan bahwa dirinya sendiri perlu waspada terhadap hal itu
• Ia menekankan bahwa selain perhitungan berulang dalam loop, penugasan ulang atau pembaruan variabel sebaiknya dihindari
• Jika semua tahap perhitungan antara tetap tersimpan, hal itu membantu saat debugging, dan dapat mencegah masalah ketika nilai sebelumnya tidak sengaja digunakan saat memindahkan blok kode
• Ia menjelaskan bahwa di C/C++, merupakan kebiasaan yang baik untuk mendeklarasikan hampir semua variabel sebagai const pada saat inisialisasi
• Terakhir, ia menegaskan harapannya bahwa "mutable seandainya menjadi keyword", sehingga immutability menjadi nilai default

[GN⁺]

Komentar Hacker News

• Setelah memakai Clojure selama 2 tahun, terasa sangat sulit menjelaskan kejernihan yang diberikan immutability kepada developer lain
  Orang yang terbiasa dengan pola pikir menghasilkan efek lewat perubahan state sulit memahaminya sebelum mengalaminya sendiri

  • Mengubah variabel menciptakan ketergantungan urutan yang implisit
    Misalnya jika ditulis seperti x = 7; x = x + 3; x = x / 2, menukar urutannya tidak menimbulkan error tetapi hasilnya berubah
    Sebaliknya, jika memakai variabel baru seperti x1, x2, urutan yang salah akan memunculkan error dan membuat masalahnya terlihat jelas
    Pada akhirnya, single assignment adalah cara untuk mengekspresikan ketergantungan ini secara eksplisit
  • Saya juga pernah mengalami hal serupa di Scheme
    Meski dijelaskan kepada rekan yang belum pernah memakai bahasa fungsional betapa mudah diuji dan rapi pola pikir yang berpusat pada fungsi, mereka tetap sulit merasakannya
    Python sulit dipakai untuk menulis gaya fungsional dengan cara yang enak dibaca, dan JS terasa malah lebih baik
    Pada akhirnya, hanya developer yang penasaran yang akan mencoba bahasa seperti Clojure
  • Jika data immutable dan pure function dijadikan dasar, fungsi bisa diperlakukan sepenuhnya seperti black box
    Fungsi tidak perlu mengetahui state luar, dan pihak luar juga tidak perlu mengetahui bagian dalam fungsi
    Tanpa mengetahui keseluruhan state program, kita bisa menguji atau men-debug fungsi tertentu secara terpisah
  • Menempatkan immutability dan mutability hanya sebagai dua hal yang saling berlawanan adalah cara menghindari kompleksitas
    Menarik melihat komunitas Haskell pada akhirnya mencoba menemukan kembali mutability di dalam type system
    Intinya adalah mengendalikan side effect dengan biaya serendah mungkin
  • Clojure adalah bahasa yang paling berpengaruh di antara semua bahasa yang pernah saya pelajari
    Haskell punya hambatan masuk tinggi karena type system-nya, dan F# terlalu kompromistis sehingga akhirnya saya menulis kode dengan sintaks C#
    Berkat homoiconicity dan struktur data Clojure yang kuat, konsep “bekerja dengan nilai” untuk pertama kalinya terasa benar-benar jelas
    Saya mungkin tidak akan memakainya secara profesional, tetapi untuk orang yang belum punya pengalaman dengan bahasa fungsional atau Lisp, saya sangat ingin merekomendasikannya

• Saya berharap variabel pada dasarnya immutable dan semuanya adalah expression
  Tapi kenyataannya, sebagai developer Clojure saya sedang menderita karena invasi Python

  • Saya juga developer Python, tetapi hanya memakai Clojure untuk proyek pribadi
    Sekarang saya sedang menderita karena invasi TypeScript, jadi saya sangat paham
  • Setelah belajar Rust, saya sadar bahwa meski sebuah bahasa tidak murni fungsional, semuanya tetap bisa berupa expression
    Pendekatan ini sangat berguna untuk membatasi ruang lingkup perubahan
  • Clojure selalu lebih cepat daripada Python, itu setidaknya sedikit menghibur
  • Anda hanya orang yang memakai Clojure, tidak perlu mendefinisikan diri sebagai “programmer Clojure”
    Tidak perlu terseret dalam perang suku antarbahasa
    Di era peningkatan produktivitas, batas-batas seperti itu tidak lagi berarti
    Saya merekomendasikan tulisan Don’t Call Yourself a Programmer

• Saya berusaha meminimalkan reassignment variabel, tetapi kadang memakai variable shadowing
  Saya suka pola seperti result = result.process() karena ringkas

  • Mungkin karena contohnya abstrak, tetapi dalam kebanyakan kasus tiap tahap bisa diberi nama yang jelas
  • Pola seperti ini bisa memicu bug keamanan
    Misalnya jika process() adalah fungsi validasi, bisa jadi tidak jelas pada titik mana nilainya sudah diproses
    Karena itu, lebih baik membedakan state dengan nama yang jelas
  • Dalam gaya fungsional, ini bisa diselesaikan dengan function chaining tanpa variabel perantara
    Contoh: result = x |> foo |> bar |> baz atau (-> x foo bar baz)
  • “result.process()? Sebenarnya result yang mana dan process yang seperti apa?”
    Orang yang membaca kode nanti akan bingung
  • Jika itu sudah merupakan result, lalu diproses lagi, itu terasa janggal secara logis

• Istilah “variabel(variable)” sendiri selalu terasa mengganjal
  Kalau immutable, kenapa disebut variable?

  • Variabel memang tidak berubah selama satu eksekusi, tetapi nilainya bisa berbeda di setiap pemanggilan
    Di Rust, perubahan hanya bisa dilakukan jika dinyatakan eksplisit dengan mut
    Sebaliknya, di C harus memakai preprocessor untuk membuat konstanta, sehingga membingungkan
  • Argumen fungsi x menerima nilai yang berbeda di setiap pemanggilan, jadi itu sendiri adalah nilai yang berubah
    Walau tidak ada reassignment, itu tetap bisa disebut variabel
  • Dalam matematika pun, variabel adalah simbol yang menunjuk ke nilai sembarang, bukan objek tertentu
    Pemrograman mengambil konsep ini apa adanya
  • Pada akhirnya, ia disebut variable karena nilainya bisa berbeda di setiap eksekusi
    Konstanta(constant) memiliki nilai yang sama di semua eksekusi
    Lihat Variable (mathematics)
  • Jadi makna ‘variabel’ di sini bukan berubah seiring waktu, melainkan berbeda tergantung konteks

• Akan bagus jika IDE bisa menandai secara visual apakah sebuah variabel pernah diubah
  Misalnya, variabel yang diubah cukup diberi penanda kecil

  • Di IntelliJ, variabel yang di-reassign diberi garis bawah, dan saat kursor diarahkan muncul petunjuk “Reassigned local variable”
    Jika sebisa mungkin memakai final, kode jadi lebih mudah dibaca dan dipelihara
  • Tapi menurut saya opt-in yang eksplisit lebih baik daripada inferensi otomatis
    IDE sebaiknya memberi peringatan, dan hanya mengizinkan perubahan jika benar-benar diperlukan
    Seperti pembahasan set vs list oleh Rich Hickey, kita harus memilih struktur yang mengekspresikan makna dengan jelas
  • Swift mendeteksi lewat compiler apakah sebuah variabel benar-benar diubah, lalu menyarankan agar dijadikan konstanta jika tidak perlu diubah
  • IDE JetBrains sudah punya fitur untuk mencari lokasi baca/tulis variabel
  • Jika ada linter yang melakukan ini, nama “mutalator” tampaknya cocok

• Dulu saya pernah mengerjakan proyek yang menerapkan immutability secara ketat demi thread safety
  Hasilnya kode jadi mudah dibaca, dan lebih mudah melacak apa yang bisa berubah
  Sejak itu saya menjadi penggemar berat immutability

  • Kalau begitu, saya sangat menyarankan untuk mencoba Rust

• Setelah bekerja di codebase Haskell yang besar lalu kembali ke C, saya jadi merasa seharusnya immutability menjadi default
  const terasa belum cukup

  • Di C, yang sebenarnya bisa dilakukan hanyalah reassignment nilai, bukan perubahan langsung
    Untuk mengubah sesuatu harus memakai pointer, sedangkan di C++ argumen bisa diubah hanya lewat pemanggilan fungsi, sehingga kurang transparan
  • Saya penasaran apakah default Rust sudah memberikan immutability yang cukup aman

• Saya setuju dengan pendapat bahwa “hampir semua variabel sebaiknya dideklarasikan sebagai const”
  Rust layak disebut di sini

  • Terkait ini, layak juga melihat tweet John Carmack
  • Dan Zig juga mengikuti filosofi yang sama

• Saya membayangkan sintaks di mana immutable menjadi default, dan mutable hanya diizinkan di dalam blok tertentu
  Misalnya seperti blok with di Python

  with mutable(x, items):
      x = 3
      items.append(4)
  

  Setelah keluar dari blok, semuanya kembali immutable

  • Itu pada dasarnya adalah konsep mutable borrow
    Kalau melihat borrow checker Rust, kita bisa tahu betapa rumit konsep ini
  • Tanpa pemeriksaan borrow, referensi bisa tetap tersisa di luar blok dan masih bisa diubah

• Ada ungkapan “State is the enemy”
  Semakin banyak state, semakin bertambah secara eksponensial kondisi yang harus diuji
  Immutability adalah cara untuk mencegah ledakan state seperti ini

  • Karena itu programmer fungsional percaya pada pemisahan Church dan state
    Separation of Church and State