Cara Membuat Hal-Hal Sulit Menjadi Mudah

• Keynote Strange Loop dari Julia Evans membahas mengapa keterampilan yang tampak “dasar” seperti DNS, Bash, HTTP, dan SQL justru sulit dipelajari dan memakan waktu lama, serta cara menurunkan hambatan belajar
• Kesulitan Bash terletak pada banyaknya pengecualian kecil dan jebakan, seperti set -e yang dinonaktifkan saat pemanggilan fungsi berada di dalam kondisi ||, dan banyak orang hanya memakai Bash sesekali sehingga sulit mengingat detailnya dengan tepat
• HTTP dan SQL menyembunyikan beban belajar besar di balik permukaan yang tampak sederhana, seperti implementasi browser sebesar 20 juta baris kode, banyak header dan flag, serta perbedaan antara urutan penulisan dan urutan eksekusi SQL
• Pada DNS, komunikasi antara library, cache, dan authoritative nameserver tidak mudah terlihat oleh pengguna, dan output dig juga rumit, sehingga alat yang menampilkan perilaku tersembunyi serta demo menjadi penting
• Dukungan belajar yang baik mencakup berbagi alat dan referensi, menyusutkan daftar besar menjadi daftar kecil yang benar-benar dipakai, menjelaskan apa yang dilakukan komputer secara kronologis, dan turut membagikan kisah kegagalan serta catatan bug

---

Mengapa teknologi yang tampak “dasar” butuh waktu lama untuk dipelajari

• Keynote Strange Loop Making Hard Things Easy membahas cara membuat teknologi yang sulit dipelajari menjadi lebih mudah
• Titik awalnya adalah DNS
  • Mencari alamat IP dari nama domain tampak sederhana, tetapi pembicara mengatakan bahwa bahkan setelah 7 tahun belajar DNS, ia masih mengalami masalah saat mengatur situs web, dan secara keseluruhan butuh sekitar 10 tahun
  • Teman-temannya juga terus mengalami masalah yang sama berulang kali, dan banyak orang menerimanya sebagai masalah pribadi seolah-olah mereka “seharusnya sudah paham”
• Untuk menjelaskan topik-topik seperti ini dengan lebih mudah, pembicara memulai penerbit kecil bernama Wizard Zines, dengan Bash, HTTP, SQL, dan DNS sebagai contoh

Bash: pengecualian yang sulit diingat sebaiknya ditangani alat

• Bash adalah bahasa pemrograman, tetapi termasuk salah satu bahasa yang menurut pembicara memiliki perilaku aneh paling banyak
• Dalam skrip contoh, meskipun mv ./*.txt /tmmpp gagal, Bash secara default tidak berhenti dan tetap menjalankan echo "success!"
  • Dengan set -e, Bash bisa dibuat berhenti saat terjadi kegagalan
  • Namun jika fungsi dipanggil di dalam kondisi seperti f || echo "failed!", maka set -e di dalam fungsi akan dinonaktifkan secara global dan success kembali tercetak
  • Perilaku ini bukan bug Bash, melainkan perilaku yang terdokumentasi
• Salah satu alasan Bash sulit adalah banyak orang hanya menulis skrip Bash sekali tiap 6 bulan lalu tidak melihatnya lagi
  • Jika sistem yang jarang dipakai penuh dengan pengetahuan kecil dan jebakan, maka sulit menggunakannya dengan benar
• Reaksi seperti “tak seorang pun bisa memakai Bash” tidak sepenuhnya benar
  • Banyak orang memakai Bash, dan meskipun tidak sempurna, mereka sering tetap berhasil menyelesaikan pekerjaan
  • Tujuannya adalah membawa seseorang yang berdiri di depan tumpukan jebakan yang menakutkan ke kondisi “bisa memakainya dengan cukup benar”
• ShellCheck adalah alat yang mengingat jebakan Bash yang sulit dihafal manusia dan memberi peringatan
  • shellcheck -o all bad-again.sh menampilkan peringatan SC2310 bahwa set -e dinonaktifkan untuk fungsi yang dipanggil dalam kondisi ||
  • Pemeriksaan ini hanya muncul jika dijalankan dengan -o all
  • Alat seperti ini membuat komputer menangani pengetahuan kecil yang merepotkan sehingga beban kognitif berkurang

Kisah kegagalan lebih membantu penilaian daripada “best practices”

• Bahkan tanpa membuat alat sendiri, penting untuk memberi tahu teman atau rekan kerja tentang alat berguna yang sudah dipakai
  • Pembicara juga baru mengetahui ShellCheck terlambat, dan mengatakan ia kesal karena selama itu ternyata ia tidak perlu mengingat semuanya di kepala
• Berbagi jebakan dan kisah kegagalan lebih mirip layanan komunitas
  • Kasus set -e yang dinonaktifkan di Bash dipelajari dari pengalaman yang diceritakan teman bernama Jesse beberapa minggu sebelumnya
  • Dengan mengetahui kegagalan orang lain, kita bisa menghindari masalah yang sama tanpa harus mengalaminya sendiri
• Daripada opini keras seperti “tidak ada yang boleh memakai Bash”, cerita tentang masalah nyata yang ditimbulkan Bash jauh lebih berguna
  • Mendengar cerita yang sama, seseorang bisa memutuskan memakai ShellCheck dan tetap mempertahankan skrip Bash sederhana
  • Orang lain bisa memutuskan tidak ingin memakai Bash sama sekali
  • Tidak masalah jika reaksi terhadap contoh yang sama berbeda-beda

HTTP: harus dipahami dengan asumsi adanya browser 20 juta baris kode

• Respons HTTP mungkin tampak memiliki struktur sederhana berupa status code, header, dan body
• Namun pertanyaan seperti “mengapa header ini perlu disetel?” segera mengarah ke perilaku browser
  • Firefox terdiri dari sekitar 20 juta baris kode
  • Browser telah berevolusi sejak 1990-an, dan model keamanannya terus berubah mengikuti serangan dan perubahan di web
• Untuk memahami mengapa suatu topik sulit, kita perlu melihat apakah ada codebase yang sangat besar di belakangnya
  • Bukan hanya HTTP, tetapi juga CSS, JS, dan lainnya, namun kompleksitas browser modern membantu menjelaskan hambatan belajar HTTP
• Daftar besar perlu diperkecil menjadi daftar kecil agar lebih mudah dipahami
  • Daftar header permintaan HTTP berjumlah lebih dari 43, dan masih ada header tidak resmi
  • Dalam komik header permintaan HTTP, pembicara membahas 15 header yang ia ketahui dan gunakan
  • “Header paling penting” bukan daftar objektif, melainkan daftar subjektif berdasarkan yang ia pahami dan pakai
  • Misalnya, sering kali cukup tahu bahwa jika Accept-Encoding disetel ke gzip, maka kita bisa menerima respons terkompresi
• Alat command line juga bisa didekati dengan cara yang sama
  • Man page grep punya banyak flag, tetapi bahkan setelah 20 tahun memakai grep, pembicara tidak mengetahui semuanya
  • Akan membantu bagi pemula jika orang berpengalaman berkata, “Saya hanya tahu 7 hal dalam sistem ini, dan inilah 7 hal itu”
  • Orang berpengalaman lain mungkin mengenal 7 hal yang berbeda

Referensi harus dengan jujur membagikan yang benar-benar dipakai

• Informasi yang tidak muat di kepala manusia membutuhkan referensi yang baik
• Pembicara mengatakan bahwa setelah 20 tahun belajar CSS secara berkala, ia baru mengetahui CSS-Tricks sekitar 2 tahun terakhir, dan andai tahu lebih awal itu akan sangat membantu
  • CSS-Tricks tampaknya berhenti menerbitkan artikel baru sejak April setelah akuisisi, tetapi artikel yang sudah ada masih dianggap berguna
• Untuk HTTP, ia banyak memakai Mozilla Developer Network
• Sebagai referensi resmi HTTP, ada RFC 9110, 9111, 9112, 9113, dan 9114 yang ditulis pada 2022
  • Di sana bisa dicari detail seperti perilaku tepat dari header Connection
  • Referensi utama pembicara biasanya MDN, tetapi ia sangat menghargai bahwa RFC resmi tersebut tersusun rapi
• Saat membagikan referensi, perlu dibedakan antara yang dibagikan karena terlihat keren dan yang benar-benar dipakai dalam pekerjaan nyata
  • Dalam praktiknya, meskipun seseorang memakai referensi yang “kurang keren” seperti w3schools, yang penting adalah jujur tentang apakah itu benar-benar digunakan

SQL: jelaskan apa yang dilakukan komputer secara kronologis

• SQL bisa membingungkan bagi pemula karena urutan menulis query berbeda dari urutan eksekusi konseptual yang sebenarnya
• Model mental SQL yang dipakai pembicara adalah urutan berikut
  • FROM
  • WHERE
  • GROUP BY
  • HAVING
  • SELECT
  • ORDER BY
  • LIMIT
• Database nyata lebih kompleks karena ada optimisasi, tetapi model kronologis ini berguna untuk kebanyakan situasi
  • Urutannya hampir sama dengan urutan yang tertulis di query, kecuali SELECT berada di posisi kelima
• Pendekatan dengan bertanya “apa yang sebenarnya dilakukan komputer lebih dulu?” bisa dipakai untuk topik lain juga
  • Dalam CORS, semua komunikasi antara browser dan server bisa dituliskan secara kronologis agar lebih mudah dipahami
  • Pembicara menyebut komik CORS sebagai contoh pendekatan ini
• Penjelasan kronologis tampak sederhana, tetapi sebenarnya sulit, dan itulah sebabnya berguna untuk kolaborasi
  • Behind Hello World on Linux membahas apa yang terjadi saat menjalankan “hello world” di Linux
  • Pembicara juga menulis artikel serupa 10 tahun sebelumnya, tetapi tulisan tahun 2023 itu sekitar 6 kali lebih panjang
  • Bukan karena Linux menjadi lebih rumit, melainkan karena pada 2013 ia masih kurang memahami apa yang terjadi secara kronologis
• Dalam tim pun, ketika sebuah request masuk ke endpoint API, membuat timeline kronologis bersama tentang apa yang terjadi bisa membantu menyambungkan bagian-bagian yang diketahui masing-masing orang

DNS: perilaku tersembunyi harus ditampilkan agar intuisi terbentuk

• DNS adalah struktur di mana browser, fungsi library yang mengirim permintaan DNS, cache, dan authoritative nameserver bekerja bersama
• Masalahnya, banyak bagian di antaranya tersembunyi dari pengguna
  • Tidak mudah mengetahui kode library mana yang mengirim permintaan DNS
  • Data yang tersimpan di cache sulit diperiksa, dan pengguna tidak bisa mengendalikannya
  • Komunikasi antara cache dan authoritative nameserver juga tidak terlihat
• Pembicara bersama temannya Marie membuat DNS server kecil bernama Mess With DNS
  • Pengguna bisa membuat record DNS untuk domain
  • Setiap kali ada permintaan dari resolver, layanan itu menampilkan pesan apa yang masuk
  • Dalam demo Strange Loop, mereka membuat record CNAME bernama strangeloop yang mengarah ke orange.jvns.ca, dan melihat bahwa resolver DNS Kanada yang dipakai browser meminta record A dan AAAA
• Contoh lain yang menunjukkan hal tersembunyi adalah float.exposed
  • Dengan mengubah significand dan exponent pada angka floating point 32-bit, kita bisa melihat angka floating point berikutnya dan perubahan jaraknya
• Alasan lain DNS sulit adalah karena ia merupakan sistem terdistribusi yang sangat besar
  • Pembicara mengatakan kurang lebih “lebih dari 5 juta komputer bisa terlibat”, di mana sebagian besar tidak berada dalam kendali pengguna dan sebagian bisa berperilaku berbeda dari harapan

Ketika alat seperti output dig justru menjadi hambatan belajar

• Output dari alat DNS juga bisa menambah kebingungan
• dig memiliki flag +norecurse
  • Kita bisa meminta resolver hanya mengembalikan hasil yang sudah ada di cache
  • dig +norecurse jvns.ca bisa dipakai untuk memeriksa apakah resolver tersebut telah menyimpan domain itu di cache dalam 5 menit terakhir, misalnya
• Output dig bisa memberi kesan kepada pemula bahwa DNS itu sendiri jauh lebih rumit
  • Pembicara melihat ini lebih sebagai akibat dari format output yang cukup arbitrer yang ditetapkan pada 1990-an dan terus dipertahankan
• “eraser eyes” adalah cara mengabaikan bagian lain dari output yang rumit seolah-olah dihapus, dan hanya menyisakan bagian yang benar-benar dilihat
  • Dalam contoh, fokusnya hanya pada response code SERVFAIL
  • Menurut pemahaman pembicara, dalam konteks ini SERVFAIL kurang lebih berarti “tidak ada di cache”
• Saat mendemonstrasikan alat, akan membantu jika kita menjelaskan output atau UI mana yang dilihat dan bagian mana yang diabaikan
  • dig memang punya output yang kasar, tetapi kelebihannya adalah fiturnya banyak, mendukung +norecurse, tersedia di mana-mana, dan stabil karena sudah lama tidak berubah

Peran-peran untuk bersama-sama membuatnya lebih mudah

• Upaya membuat teknologi lebih mudah bisa dibagikan dengan orang sekitar bahkan tanpa memiliki blog
• Cara-cara yang dirangkum pembicara adalah sebagai berikut
  • Berbagi alat yang berguna
  • Berbagi referensi yang benar-benar dipakai
  • Menjelaskan apa yang terjadi di komputer secara kronologis
  • Meringkas daftar besar menjadi daftar kecil yang benar-benar kita gunakan
  • Menunjukkan perilaku yang tersembunyi
  • Mendemonstrasikan alat yang membingungkan sambil menunjukkan bagian mana yang perlu dilihat
• Jenis orang yang membantu pun beragam
  • “Pengguna lama yang suka menggerutu” menceritakan apa yang dulu salah sehingga bisa mengurangi penderitaan orang lain
  • “Pemula yang berisik” bertanya, “Bagaimana ini bekerja?” sehingga orang lain juga merasa lega
  • Saat developer senior bertanya secara terbuka tentang hal yang tidak ia ketahui, orang yang khawatir dianggap bodoh karena tidak tahu bisa ikut belajar
  • “Pencatat bug” merangkum apa yang terjadi agar bug yang sama tidak terulang
  • “Pembuat alat” menulis kode untuk membuat masalah menjadi lebih mudah secara permanen alih-alih menjelaskan hal yang sama berulang kali
  • “Pembagi hal yang dipelajari hari ini” membagikan alat baru, bug yang dialami, atau fitur library yang baru diketahui
  • “Orang dengan 700 tab terbuka” kemungkinan besar sudah tahu harus mencari informasi di mana
  • Kita juga membutuhkan “orang yang menjawab pertanyaan” dan “orang yang menuliskannya agar bisa dicari lagi nanti”
• Kesulitan memahami hal yang terlihat dasar bukanlah masalah pribadi semata
  • Banyak orang mengalami kesulitan di titik yang sama karena alasan yang sama
  • Jika kita memahami mengapa sesuatu terasa sulit, kita bisa memperbaikinya lebih baik, seperti memperbaiki bug pada program komputer
• Faktor-faktor yang membuatnya sulit mencakup pengetahuan kecil dan jebakan yang sangat banyak, kode berskala 20 juta baris, sistem tersembunyi, serta output alat yang membingungkan dan tidak diperbaiki
• Pembicara mengatakan ia masih belum benar-benar memahami mengapa Git begitu sulit, tetapi tetap ingin terus memikirkannya dan memahaminya

[GN⁺]

Komentar Hacker News

• Bagian yang paling mengena bagi saya adalah nasihat untuk tampilkan hal-hal yang biasanya tersembunyi
  Alat-alat seperti ini hampir seketika membuat situasi jadi lebih jelas. Coba pikirkan developer tools di browser web; pada “masa kegelapan” ketika belum ada alat seperti itu, kita harus menebak apa yang terjadi tanpa bisa melihatnya, dan itu mengerikan
  Alat seperti Wireshark, yang menampilkan byte dari paket jaringan yang dapat diakses dan bahkan mem-parse strukturnya, sangat berguna bukan hanya untuk debugging jaringan, tetapi juga untuk mengajarkan konsep jaringan, karena tidak ada yang disembunyikan
  Itu juga alasan saya menyukai software open source. Tidak ada yang tersembunyi karena kita bisa melihat source untuk memahami penyebab bug, mengisi celah pengetahuan yang ditinggalkan dokumentasi, atau mempelajari konsep pemrograman lebih jauh

  • Di dunia pengembangan game, alat yang sesuai dengan ini adalah renderDoc. Saya benar-benar kagum saat pertama kali tahu alat itu ada
  • Wireshark memang hebat, tetapi tidak menampilkan semua byte yang dibawa jaringan
    Misalnya, ia tidak pernah menampilkan Ethernet preamble, hanya kadang-kadang menampilkan Ethernet frame checksum, dan juga tidak pernah menampilkan interframe gap, yang merupakan elemen wajib protokol Ethernet
    Memang sudah sangat dekat, tetapi ini menunjukkan bahwa selalu ada detail lain yang tersembunyi di suatu tempat
  • Impian saya adalah membuat semuanya bisa divisualisasikan saat runtime. Kalau itu bisa dilakukan, menurut saya seluruh komputasi akan menjadi sangat sederhana dan jauh lebih tidak rumit
    Di kepala kita, kita sudah memvisualisasikannya, dan penjelasan apa pun tentang komputasi pada akhirnya diungkapkan sebagai diagram. Tetapi saat coding, tidak ada diagram sama sekali
    Tinggal instrumentasikan semua kode secara dinamis lalu kirim pesan ke GUI
  • Berbeda dengan ungkapan “tampilkan hal-hal yang biasanya tersembunyi” dan “alat seperti itu hampir seketika membuat situasi jadi jelas”, alat DevOps masa kini justru tampaknya makin menyembunyikan lebih banyak hal
    Para ahli yang punya pengetahuan itu dan bisa mengajarkannya pun kini berkumpul di perusahaan-perusahaan pembuat alat tersebut, bukan lagi di dalam organisasi
  • Inilah hal yang saya sukai dari Magit untuk Emacs. UI-nya benar-benar cerdik dan mulus, mungkin front-end Git terbaik yang pernah saya pakai, tetapi cara kita berinteraksi dengan UI adalah dengan menyalakan/mematikan flag dan opsi yang dipetakan ke argumen command line Git internal yang sebenarnya
    Jadi ketika beralih secara alami ke command line, kita langsung familier dan bisa menggunakannya sendiri

• Julia tampaknya salah satu orang paling menyenangkan di industri teknologi
  Setiap kali membaca tulisannya, saya kembali merasakan kegembiraan berdebar seperti saat kecil, ketika mulai menguak rahasia realitas lewat eksperimen-eksperimen kecil. Benar-benar menyenangkan

  • Jarang ada orang yang sekaligus punya pengetahuan teknis mendalam dan kemampuan mengajar serta berkomunikasi yang luar biasa. Orang lain yang terlintas adalah Andrej Karpathy
    Untungnya belakangan ini saya mulai menemukan lebih banyak orang yang cocok dengan tipe seperti ini
  • Sebentar saya kira ini membahas bahasa Julia :)
  • Sangat setuju. Biasanya saya kurang suka posting blog atau tutorial yang terlalu heboh dengan gaya “omg awesomesauce”, dan jauh lebih menyukai tulisan bergaya Landau&Lifschitz yang kering, ringkas, indah, dan punya rasio signal-to-noise tinggi
    Namun semua tulisan Julia membuat saya merasakan kegembiraan berdebar yang disebutkan tadi
  • Saat bertemu langsung pun ia benar-benar menyenangkan. Saya minta tanda tangannya di buku How DNS Works saya

• Menurut saya, pernyataan “ketika junior bilang ‘ini sulit’, orang berpengalaman menjawab ‘benar, bash memang tidak bisa dipakai. Tidak ada yang benar-benar memahaminya’” tidak perlu dipahami secara harfiah
  Maknanya lebih dekat ke “pemahaman kita atas kode bash yang kita tulis, atau keyakinan bahwa ia akan berjalan sesuai harapan dalam situasi yang belum diuji, tidaklah kuat”
  Artinya, begitu ada sesuatu yang sedikit saja tidak biasa, kita agak mengantisipasi bahwa sesuatu akan gagal, lalu fakta baru yang kita pelajari tentang bash akan membuat kita bergidik atau memukul benda di sekitar cukup keras sampai rusak
  Bash adalah bahasa yang kompleks, dan bagi kebanyakan programmer sangat berbeda dari bahasa lain yang biasa mereka pakai. Di kebanyakan perusahaan, biasanya ada sedikit bash di production di suatu tempat, tetapi sering kali tidak ada satu pun orang yang menggunakannya cukup banyak hingga benar-benar memahaminya
  Menurut saya bukan kebetulan kalau build tools, CI tools, dan cloud orchestration tools berevolusi ke arah mengurangi kebutuhan shell scripting

  • Menurut saya kompleksitas alat seperti bash berasal dari kurangnya evolusi
    Sebagai eksperimen pikiran, tidak bisakah kita menambahkan assignment statement yang lebih baik ke bash? Misalnya, jika dalam mode seperti set --goodass kita bisa menulis a = string1 + '.' + string2, banyak kerumitan shell quoting bisa dipangkas
    Alat seperti make juga akan diuntungkan. Jika kita menghabiskan 6 bulan untuk membuat make punya variabel yang layak pakai, cara yang jelas untuk memanipulasi path dan nama file, serta target yang lebih berguna, itu bisa lebih baik daripada menghabiskan 6 bulan membuat Makefile yang kompleks
  • Masalahnya adalah apakah junior akan memahami makna implisit itu, atau justru memahaminya lebih harfiah daripada yang dimaksudkan
    Khususnya, perasaan bahwa “bagi kebanyakan programmer, bash berbeda dari bahasa apa pun yang biasa mereka pakai” bukan sesuatu yang pasti bisa disimpulkan pemula. Sebab dibutuhkan pengalaman yang cukup untuk memahami perbedaan antara “tidak umum” dan “sangat sulit dipahami”

• Terkait itu, sebagian besar software dirancang berlebihan
  Saya pikir ini juga karena sentralisasi industri. Semua orang didorong memakai alat-alat tersebut demi keuntungan segelintir pihak yang mengendalikan segelintir alat, dan akibatnya banyak alat menjadi “alat untuk segala hal” yang mencakup jauh lebih banyak daripada use case yang harus ditangani
  Perusahaan ingin para developer semuanya memahami alat yang sama. Dengan begitu mereka mudah diganti antarproyek dan antarperusahaan, dan posisi tawar mereka di industri melemah
  Karena itu, di software hanya tersisa satu arus utama, sementara pendekatan alternatif disingkirkan tanpa lapangan kerja. Industri ini secara alami ingin terdistribusi, tetapi tidak bisa menjadi seperti itu
  Sisi positifnya, suatu hari nanti pendekatan-pendekatan non-mainstream yang jauh lebih unggul akan muncul dan menggerogoti pendekatan arus utama. Teknologi bukan matematika dan juga berbeda dari sains; ia cukup mampu menopang banyak cabang yang menyelesaikan masalah yang sama dengan berbagai cara

  • Setuju. Dalam beberapa hal, pengembangan web bahkan terasa mundur dibanding masa awal ASP.NET atau Rails
    Saat itu perang browser membuat kita sibuk, tetapi sekarang browser pada umumnya kompatibel, namun kita justru menciptakan banyak kompleksitas front-end untuk web app yang biasanya tidak diperlukan
    Hal-hal seperti DNS, IP, dan HTTPS adalah teknologi fundamental yang terikat kompatibilitas mundur dan faktor politik, jadi memang tidak bisa dihindari
    Meski begitu, saya merasa mempelajari hal-hal tersebut dengan baik adalah investasi yang lebih baik daripada mempelajari framework. Kalau dibahas lebih jauh, mungkin akan sampai ke pembicaraan tentang innovation token

• Untuk membuat hal-hal sulit menjadi mudah, kita perlu menemukan abstraksi yang tepat. Caranya adalah hanya menyimpan sebagian dari materi yang sulit dan detail yang sering dipakai di kepala, lalu mencari sisanya saat dibutuhkan
  Masalahnya, orang tidak mau repot-repot membuat kompresi kognitif untuk topik besar sampai mereka benar-benar membutuhkannya. Karena mereka sudah memikul beban kognitif besar lainnya, mereka menolak menambahkan beban baru
  Jika bisa bergantung pada orang lain yang memahami suatu topik X dengan baik, mereka akan begitu saja melakukannya, dan mungkin tidak berusaha cukup keras untuk memahami X. Cara terbaik bagi orang yang memahami X dengan baik untuk mengurangi permintaan bantuan adalah membantu orang lain memahami X pada tingkat minimal
  set -e itu rusak, kebutuhan untuk mengapit semuanya dengan tanda kutip juga rusak, dan globbing seharusnya menjadi fitur yang harus diminta secara eksplisit. Di command line itu mungkin merepotkan, tetapi dalam skrip ceritanya berbeda; saat ini, jika globbing dimatikan secara global, sulit melakukan globbing di tempat yang diinginkan
  Default yang buruk seperti ini tidak hanya ada di Bash, tetapi juga di seluruh shell garis keturunan Ksh dan Bourne shell
  Banyak orang juga ingin mengubah urutan klausa SQL. Tidak ada alasan untuk tidak bisa, dan tampaknya itu perubahan yang relatif kecil agar parser SQL yang ada mengizinkan klausa dengan urutan berbeda
  Namun secara pribadi saya tidak punya masalah kognitif ini, mungkin karena saya tahu harus melihat sumber tabel terlebih dahulu

  • Tiga jebakan bahwa set -e rusak, semuanya harus diapit tanda kutip, dan globbing harus eksplisit, semuanya diperbaiki oleh OSH sambil tetap menjalankan skrip shell yang ada
    Jika menambahkan shopt --set ysh:upgrade di bagian paling atas skrip, tiga masalah itu hilang
    Jika ingin membantu proyek ini, akan bagus jika mengunduh tarball, memverifikasi klaimnya, lalu menulis posting blog
    Detailnya ada di https://www.oilshell.org/release/latest/doc/error-handling.h... dan https://www.oilshell.org/release/latest/doc/simple-word-eval...
    Dokumentasinya komprehensif, tetapi kebanyakan orang tidak menginginkan detail sebanyak itu, jadi akan membantu jika ada yang menguji dan menuliskannya secara singkat
    Alasan saya tidak terlalu aktif mendorong Oils selama beberapa waktu adalah karena ada dependensi Python, tetapi sekarang sudah murni C++ dan per minggu ini mengalahkan bash pada beberapa benchmark yang berfokus pada komputasi
    Skrip yang berfokus pada input/output selalu memiliki kecepatan yang sama, seperti kebanyakan skrip shell. Di dokumentasi, Oil masih perlu diganti menjadi YSH, jadi mungkin akan ada kebingungan untuk sementara: https://www.oilshell.org/blog/2023/03/rename.html
  • Masalahnya adalah kita terus memakai shell kuno seperti ini padahal ada shell yang lebih baik. Pengguna tidak seharusnya membuang waktu menghafal pengetahuan gelap seperti set -e. Meski begitu, sekarang setidaknya ada mesin pencari
  • Cara yang agak radikal untuk memperbaiki urutan klausa SQL mungkin adalah memperkenalkan project yang berperilaku seperti select, tetapi bisa ditempatkan di posisi yang benar
  • Jika penjelasan memasukkan detail yang tidak perlu, itu sangat membingungkan. Seperti senjata Chekhov, kita terus berusaha memasukkannya ke dalam alur cerita, tetapi tidak cocok
    Kekuatan super saya adalah ingatan yang buruk sekali. Jadi untuk mengingat, saya harus benar-benar memahami; dengan kata lain, saya butuh kompresi kognitif. Saya tidak bisa sekadar belajar seperti orang biasa
  • Kita harus bisa mengupas SQL dan mengakses lapisan bawah

• Pelajaran hari ini: dalam daftar && atau ||, shell tidak akan keluar meskipun ada perintah yang gagal, kecuali perintah setelah && atau || terakhir di antara perintah-perintah yang dijalankan
  Referensi: https://www.gnu.org/software/bash/manual/bash.html#index-set

  • “Gagal” adalah konsep pada level yang lebih tinggi daripada yang dipedulikan shell. Kondisi kegagalan dan responsnya sepenuhnya merupakan kebijakan programmer, dan tidak tertanam sebagai asumsi di dalam shell
    Yang dilakukan /bin/false hanyalah mengembalikan 1. Apakah itu kegagalan? Bukan. Ia memang dirancang untuk bekerja seperti itu dan secara harfiah merupakan alat dengan tujuan tersebut
    Saya sudah menulis ratusan skrip shell, dan banyak perintah di antaranya mengembalikan nilai bukan 0 dengan sangat normal untuk melakukan tugasnya, misalnya memeriksa apakah sebuah string memiliki pola tertentu
    Program bisa mengembalikan kode keluar apa pun dalam situasi apa pun, dan secara konvensi sukses adalah 0, gagal adalah nilai bukan 0. Namun yang dipedulikan bahasa shell hanyalah bahwa 0 dievaluasi sebagai “true”, dan nilai bukan 0 sebagai “false”
    Jika shell keluar setiap kali program apa pun mengembalikan nilai bukan 0, pernyataan if dan loop akan menjadi mustahil, sehingga sangat merepotkan
    Jika sebuah skrip menganggap kode kembalian program tertentu penting, ia harus memeriksa dan menanganinya secara eksplisit. Seperti di tautan tadi, ada opsi yang membuat shell keluar jika perintah internal mengembalikan nilai bukan 0, dan banyak penulis skrip shell tingkat pemula-menengah secara dogmatis bersikeras bahwa opsi-opsi itu harus dipakai di semua skrip
    Namun pada skrip yang kompleks, saya merasa ada banyak edge case yang agak hacky dan sulit ditangani. Kalau setiap kali membutuhkan opsi seperti itu, mungkin lebih baik memakai Makefile saja
  • Karena && dan || sering dipakai seperti kondisional
    [ -e README ] && cat README menghindari error saat file README tidak ada, dan [ -e README ] || echo "You should write a README!" bekerja sebaliknya
    Masalah yang lebih licik adalah, bahkan dengan asumsi set -e, dalam pipeline shell tidak akan keluar jika perintah terakhir tidak gagal
    grep foo README | sort tidak akan gagal meskipun README tidak ada, kecuali juga memakai set -o pipefail
  • Saya menganggap ini salah satu cacat terbesar dalam desain bahasa shell. Sebab sebuah fungsi bisa menghasilkan akibat yang berbeda tergantung konteks pemanggilannya, terlepas dari argumennya
    Bahkan jika set -e disetel secara eksplisit di dalam fungsi, ini tetap ditimpa
    Saya pernah memberikan contoh sebelumnya: https://news.ycombinator.com/item?id=22213830
  • Ada banyak pengetahuan tersirat tentang shell yang masih harus dipelajari. Pada titik tertentu, kita harus mengangkat bahu dan menerima bahwa ini alat yang oke untuk mendapatkan hasil cepat, tetapi tidak cocok untuk menulis program yang tangguh

• Ini tulisan yang menggambarkan dengan baik hal-hal yang tampak seharusnya tidak sulit, tetapi sebenarnya punya banyak kompleksitas
  Namun bagian SQL tampaknya lebih mendorong kegagalan konseptual daripada menyingkap misterinya
  Logika kueri bersifat deklaratif dan mendefinisikan output. Yang memiliki urutan eksekusi atau sifat prosedural adalah rencana kueri. Ini yang harus dipelajari lebih dulu
  Setelah itu, barulah area abu-abu seperti subkueri dependen bisa dipelajari. Jika Anda bisa melihat bahwa not exists dan anti join itu setara, Anda bisa memahami dan menalarnya
  Analogi yang menyuruh memahami kueri tertulis secara prosedural hanya menunda masalah, dan ketika tersandung pada hal yang lebih kompleks, tidak ada cara untuk membongkar kebohongan yang diniatkan baik itu

  • Bagian SQL membicarakan model mental yang membantu memahami kueri, dan juga menyebutkan bahwa database sebenarnya mungkin tidak memprosesnya seperti itu
  • Episode terbaru terkait Postgres, tetapi dalam banyak kasus bisa diperluas untuk memikirkan database lain juga: https://www.se-radio.net/2023/09/se-radio-583-lukas-fittl-on...

• Presentasi yang bagus. Memang benar Bash penuh dengan “jebakan” dan trivia yang sulit dihafal semuanya, tetapi menurut saya sebagian trivia sebaiknya memang dihafal
  Misalnya saya sering lupa urutan argumen perintah find, sehingga saat berada di depan mesin yang tidak langsung punya koneksi internet, saya sering kehilangan waktu untuk mengingat sintaksnya
  Jadi saya memutuskan mempelajari dan menghafal beberapa alat baris perintah yang paling umum beserta sebagian jebakannya, memakai Anki dan beberapa mnemonik. Menurut saya imbal hasil dari investasinya sangat sepadan

  • Anki adalah tali penyelamat saya untuk memahami hal-hal sulit seperti DNS
    Saya benar-benar membaca Networking for System Administrators karya Michael W. Lucas setelah melihat rekomendasi buku di jvns.ca, lalu mengekstrak pengetahuan teknis dan cukup banyak kebijaksanaan sysadmin menjadi kartu Anki
    Sekarang saat men-debug masalah lapisan transport, saya langsung ingat cara memakai alat seperti netcat dan tcpdump, jadi itu mungkin salah satu buku dengan imbal hasil investasi tertinggi di antara buku yang pernah saya baca
  • Saya memelihara sebuah file berisi perintah-perintah yang jarang dipakai. Misalnya perintah untuk menaikkan volume dengan ffmpeg, atau menambahkan bingkai pada gambar dengan convert
    Saya juga membuat shortcut untuk menambahkan perintah terakhir yang dijalankan ke file ini, dan shortcut untuk mencari di dalam file ini
  • Halaman man bisa langsung digunakan
    Halaman man bash memang besar dan rumit, tetapi komprehensif. Jika sudah terbiasa dengan bagian-bagian utama dan bentuk visual teksnya, cukup berguna karena bisa cepat menelusurinya dan menemukan informasi tepat yang dibutuhkan
    Cara ini sering kali lebih cepat daripada memakai mesin pencari internet
  • Agar tidak bergantung pada internet tetapi juga tidak perlu menghafal desain yang buruk, mungkin lebih baik berinvestasi pada dokumentasi/cheatsheet yang lebih umum
    Misalnya mengubah halaman man lama ke format yang ramah editor teks, atau memakai alat yang lebih baik seperti tldr dan Dash. Karena bukan hanya find yang seperti itu
  • Anda harus berhenti memakai Bash dan memakai TypeScript sebagai gantinya. Bash itu mengerikan

• Entah kenapa saya sempat ingin tidak menyukai tulisan ini. Mungkin karena jvns terlalu sering muncul di HN, atau suasana hati saya sedang buruk
  Namun ini benar-benar tulisan yang bagus, dan sebagai orang dengan pengalaman 20 tahun di bidang pengembangan, menurut saya ini cukup mendekati kebenaran di antara diskusi tingkat meta tentang pemrograman
  Pembahasan tentang pandangan selektif benar-benar cocok untuk dig maupun halaman man. Tak terhitung berapa kali saya membuka man lalu kewalahan melihat opsi konfigurasi dan flag command-line yang tak ada habisnya
  Tips yang saya pakai di man adalah menggunakan fitur pencarian ala Vim, yaitu /. Misalnya, kalau ingin mencari cara agar grep mencetak nomor baris untuk tiap kecocokan tetapi tidak ingat caranya, buka man grep, lalu ketik /line dan tekan Enter untuk mencari kemunculan “line” di dalam halaman man. Kecocokan berikutnya cukup dengan /
  Saya juga agak sedih mendengar Strange Loop sudah berakhir. Saya baru mengetahuinya sekitar tahun lalu, tetapi banyak presentasinya tampak berkualitas luar biasa

  • Sepertinya bagus untuk menonton presentasi terbaru dari Alex Miller: https://www.youtube.com/watch?v=suv76aL0NrA
    Sedih memang karena berakhir, tetapi presentasi itu cukup meyakinkan menunjukkan bahwa kadang-kadang berakhirnya sesuatu juga bisa baik. Kalau menonton presentasi lengkapnya, akan paham
  • https://cheat.sh adalah penyelamat
    Dan saya juga membuat https://github.com/kristopolous/mansnip
  • Untuk kecocokan berikutnya, bisa juga tekan n

• Saya sangat tidak setuju dengan pandangan tentang bash. Solusi terbaik bukanlah menumpuk alat di atas bash atau menghafal keanehannya, melainkan tidak memakai bash
  Itulah satu-satunya cara menghindari jebakannya

  • Saya belum menemukan pengganti bash yang benar-benar layak. Terutama untuk skrip
    Alternatif yang paling umum adalah 1) memakai shell baru seperti Oil shell [0], atau 2) memakai bahasa pemrograman seperti Python, JavaScript, PHP
    Masalah dengan shell baru adalah Anda harus memasang shell itu di setiap tempat tempat Anda ingin menjalankan skrip. Sementara bash ada di mana-mana. Jika itu bukan skrip yang hanya Anda pelihara sendiri, berarti Anda juga meminta orang lain mempelajari shell tersebut untuk memeliharanya
    Masalah dengan bahasa pemrograman lain adalah bash punya usability yang jarang tertandingi untuk hal-hal yang memang dikuasainya: merangkai perintah, serta menangani input/output perintah dan file
    Ketika dicoba dengan bahasa lain, tiba-tiba semuanya menjadi jauh lebih rumit, atau setidaknya lebih bertele-tele
    Jadi saya masih memakai bash, tetapi mengakui bahwa kekuatannya ada pada menjalankan perintah lain dan menangani input/output. Jika logikanya kompleks dan tidak terkait dengan hal itu, saya serahkan ke bahasa lain. Kadang ini bukan sepenuhnya menghindari bash, melainkan sekadar memanggil skrip Python dari bash
    Kalau ada pendekatan lain yang lebih cocok, saya akan senang jika dibagikan
    [0] https://www.oilshell.org
  • Itu poin yang valid. bash adalah alat yang terlalu kompleks, jadi terasa aneh menulis alat lain di atasnya untuk membuat bash menjadi tidak terlalu kompleks
    Apalagi alat baru itu belum melewati puluhan tahun debugging seperti bash sendiri. Masalahnya ada pada bash itu sendiri
    Kita cenderung meremehkan kemudahan penggunaan dan melebih-lebihkan “kecerdikan”
    Contoh utamanya adalah Git. Alat yang sangat cerdik, tetapi kemudahan penggunaannya mengerikan. Namun karena dibuat oleh Linus dan Linus itu cerdik, seolah-olah masalahnya ada pada kita
    Kita mendapatkan apa yang kita hargai. Kita perlu lebih menghargai kemudahan penggunaan
  • Saya penggemar berat shellcheck dan pernah benar-benar memakai bash secara mendalam, tetapi tidak ada linter atau alat di atas bash yang bisa memperbaiki ini
    Solusi terbaik adalah menjauh saja. Sungguh, harus berhenti. Jangan mencoba bersikap macho
    Seluruh model bahasanya pada dasarnya rusak. Tipe yang berpusat pada string, switch mode global, flag satu huruf untuk operator perbandingan dasar, perilaku yang secara default mengabaikan error di mana-mana, terutama bahkan fungsi
    Satu saja keanehan seperti ini sudah cukup untuk menyingkirkan sebuah bahasa, tetapi bash punya semuanya, dan masih lebih banyak lagi
  • bash itu aneh karena memang bukan bahasa serbaguna. Hal-hal yang disebutkan dalam tulisan itu pun punya alasan yang cukup baik. Misalnya, fakta bahwa set -x bisa merusak perilaku yang diharapkan dari || dan &&
    Memang bahasa apa yang bentrok hanya karena sebuah fungsi mengembalikan false? Ada bahasa yang melempar exception, tetapi bukankah “false” adalah nilai valid yang boleh dikembalikan?
    Hal yang sama terlihat di Makefile. Orang-orang tidak memahami apa yang mereka lakukan, dan belum pernah memikirkan build system secara mendalam, sehingga berharap ia berperilaku dengan cara tertentu
    Misalnya, recursive assignment di Make membuat hampir semua orang tersandung
    FLAGS=-b, COMPILE=compile $(FLAGS), $(info compile command=$(COMPILE)), FLAGS=-a, myfile:, echo $(COMPILE) $? -o $@ akan menampilkan compile -b pada keluaran info pertama, tetapi eksekusi sebenarnya menjadi compile -a -o myfile
    Meski begitu, jika semua assignment dibuat dievaluasi segera demi menyesuaikan dengan bahasa pemrograman lain, kita justru akan kehilangan alat yang sangat berguna. Semakin memahami alat-alat seperti ini, semakin baik kita tahu di mana menggunakannya dan seberapa besar usaha yang layak dicurahkan
  • Tidak semudah kedengarannya, dan menghapus bash sepenuhnya mungkin tidak selalu sepadan dengan waktu dan usaha yang dibutuhkan
    Namun secara umum saya setuju. Saya berusaha menyerahkan hal yang sedikit saja kompleks ke skrip yang ditulis dalam bahasa yang tidak terlalu aneh
    Dalam situasi seperti itu, alat yang membantu menghindari kesalahan pada 5% terakhir yang tetap berada di bash sangatlah berguna