Kejenuhan terhadap perangkat lunak

• Perangkat lunak modern, alih-alih mengembalikan kemajuan perangkat keras dalam bentuk efisiensi, kesederhanaan, dan kematangan, selama ini menormalkan inefisiensi dengan bertumpu pada asumsi bahwa “komputer sudah cukup cepat”
• Bahkan tugas dasar seperti scroll web, membuka email di Google Inbox selama 13 detik, pembaruan Windows 10 selama 30 menit, atau jeda input di editor teks terasa lebih lambat dari yang diharapkan
• Sistem Android 6GB, Windows 10 4GB, Google Keyboard 150MB, serta contoh aplikasi Electron dan Slack menunjukkan bahwa pembengkakan aplikasi dan platform berujung pada biaya kinerja, kompleksitas, dan keandalan
• Seperti pembaruan OS, aplikasi, browser, dan penghentian dukungan aplikasi 32-bit di iOS 11, perangkat lunak yang dulu berjalan baik pun bisa melambat atau rusak seiring waktu
• Untuk membuat perangkat lunak yang lebih baik, insinyur harus memahami kinerja, struktur, dan batasan sistem yang mereka buat, serta menghasilkan hasil yang cepat dan dapat diprediksi dengan sumber daya yang lebih sedikit

---

Perangkat lunak yang membuang-buang kinerja

• Perangkat lunak modern sering dianggap tetap baik-baik saja meski berjalan hanya dengan 1% atau 0,01% dari kinerja yang sebenarnya mungkin dicapai
• Sementara mobil, bangunan, dan pesawat mendekati batas fisik atau bentuk optimalnya, perangkat lunak membenarkan inefisiensi dengan alasan “komputer sudah cukup cepat”
• Pepatah “waktu programmer lebih mahal daripada waktu komputer” bisa menutupi kenyataan bahwa waktu komputer dibuang-buang secara belum pernah terjadi sebelumnya
• Sebuah tweet tentang menulis ulang program Python yang dijalankan setiap hari ke Rust sehingga waktunya turun dari 1,5 detik menjadi 0,06 detik, tetapi butuh lebih dari 41 tahun untuk menebus 6 jam kerja, sering dipakai sebagai contoh representatif dalam diskusi efisiensi

Pengalaman dasar yang lambat sampai sulit ditoleransi

• Komputer portabel terbaru ribuan kali lebih kuat daripada komputer era pendaratan di bulan, tetapi bahkan pada MacBook Pro terbaru pun sulit melakukan scroll halaman web dengan mulus di 60fps
• Inbox buatan Google membutuhkan 13 detik untuk membuka satu email di Google Chrome
  • Pendekatan menganimasikan kotak putih kosong alih-alih konten lebih mirip kompromi yang menyesuaikan diri dengan batas kinerja halaman web
  • Bahkan ketika layar 120Hz sudah menjadi arus utama, melihat satu balasan komunitas web saja dianggap belum cukup stabil bahkan di 60Hz
• Pembaruan Windows 10 memakan waktu 30 menit, dan dalam waktu itu orang bisa beberapa kali memformat SSD lalu mengunduh dan memasang build baru sebagai perbandingan
• Editor teks modern memiliki latensi input yang lebih besar daripada Emacs yang berusia 42 tahun
  • Bahkan tugas yang hanya perlu memperbarui area persegi kecil pada setiap penekanan tombol pun disebut tidak dapat diselesaikan dalam 16ms
  • Game 3D, dalam 16ms yang sama, melakukan rendering seluruh layar, memproses input, menghitung dunia, dan mengelola sumber daya
• Perangkat keras yang lebih cepat akhirnya dipakai bukan untuk perangkat lunak yang lebih baik, melainkan untuk menjalankan perangkat lunak yang melakukan hal yang sama dengan lebih lambat

Aplikasi dan platform yang membengkak

• Aplikasi web bisa menjadi 10 kali lebih cepat hanya dengan memblokir iklan, dan AMP lebih dekat ke solusi masuk akal berupa membuang bagian-bagian yang membengkak daripada teknologi baru
• Sistem Android berukuran 6GB bahkan tanpa aplikasi apa pun, Windows 95 berukuran 30MB, dan Windows 10 berukuran 4GB
  • Windows 10 133 kali lebih besar daripada Windows 95, tetapi fungsi dasarnya dinilai tidak jauh berbeda
  • Android bahkan 1,5 kali lebih besar daripada Windows 10
• Google Keyboard biasanya memakan 150MB, aplikasi Google 350MB, dan Google Play Services 300MB
  • Kritiknya diajukan dengan mempertanyakan apakah Google Keyboard, aplikasi yang hanya menggambar sekitar tiga puluh tombol di layar, benar-benar 5 kali lebih rumit daripada seluruh Windows 95
  • Google Play Services tidak bisa dihapus bahkan jika tidak digunakan
• Situasi ketika setelah memasang aplikasi dasar ruang tersisa untuk menyimpan foto hanya sekitar 1GB dikontraskan dengan masa ketika OS, aplikasi, dan data semua disimpan di floppy disk
• Aplikasi Todo berbasis Electron bahkan bisa menyertakan driver kontroler Xbox 360, rendering grafis 3D, pemutaran musik, dan fungsi pengambilan gambar webcam
• Slack, meski hanyalah aplikasi yang dekat dengan chat dan editor teks sederhana, tetap digolongkan sebagai aplikasi berat karena kecepatan muat dan penggunaan memorinya
• Semakin besar aplikasi, semakin besar hilangnya kendali, biaya kompleksitas, penurunan kinerja, dan utang keandalan, sehingga aplikasi yang terlalu berat tidak boleh diterima sebagai hal normal

Perangkat lunak yang membusuk seiring waktu

• Tiga tahun lalu ponsel Android 16GB masih cukup, tetapi pada era Android 8.1 aplikasi menjadi dua kali lebih besar tanpa alasan khusus sehingga sulit dipakai
• iPhone 4s diumumkan bersama iOS 5, tetapi menjalankan iOS 9 terasa berat, padahal iOS 9 juga dianggap tidak secara mendasar jauh lebih unggul
• iOS 11 menghentikan dukungan aplikasi 32-bit, sehingga aplikasi yang tidak lagi punya pengembang atau tidak diperbarui bisa jadi tak akan pernah terlihat lagi
• Sebuah tweet dikutip yang mengatakan bahwa program DOS berjalan di banyak komputer sejak 1980-an tanpa modifikasi, tetapi aplikasi JavaScript bisa rusak hanya oleh pembaruan Chrome berikutnya
• Halaman web yang hari ini baik-baik saja pun mungkin dalam 10 tahun tidak lagi berjalan benar di browser mana pun
• Orang membeli ponsel baru dan MacBook baru untuk melakukan hal yang sama, tetapi akhirnya hanya menjalankan aplikasi yang sama dengan lebih lambat

Turunnya ekspektasi kualitas

• Ketika halaman web bermasalah, alih-alih mencari penyebabnya, pengguna diminta menekan refresh
• Aplikasi web dapat memuntahkan error JavaScript yang “acak” bahkan di browser yang kompatibel
• Desain halaman web dan basis data SQL dikritik karena dibangun di atas harapan bahwa data tidak akan berubah saat pengguna sedang melihat halaman web yang sudah dirender
• Fitur kolaborasi sering berhenti pada tingkat “upaya terbaik”, sehingga memuat skenario sehari-hari yang bisa menyebabkan hilangnya data
  • Dialog seperti “versi mana yang ingin dipertahankan?” pada dasarnya lebih dekat ke memilih mana dari hasil kerja yang akan dihancurkan
• Linux tetap menjadi sistem operasi server paling populer meski memiliki desain yang dapat mematikan proses secara arbitrer
• Contoh monitor Dell, AirDrop, dan Bluetooth menunjukkan bahwa perangkat lunak di dalam perangkat dan spesifikasi yang rumit menciptakan pengalaman yang bergantung pada reset berkala atau keberuntungan
• Untuk mengirimkan sesuatu yang bekerja stabil, kita harus memahami objek yang dibuat luar dan dalam, tetapi itu sulit dalam sistem yang terlalu menggembung

Kekacauan alat pemrograman dan praktik pengembangan

• Bahkan pada elemen dasar seperti manajemen paket, sistem build, compiler, desain bahasa, dan IDE, sulit melihat kematangan yang cepat, efisien, dan tahan lama
• Sistem build, meski punya semua informasi perubahan, tetap secara berkala meminta semuanya dihapus lalu dimulai lagi dari awal
  • Menurut penulis, tidak ada alasan mengapa hal itu tidak bisa dibuat andal, dapat diprediksi, dan dapat direproduksi
  • NPM digambarkan telah bertahun-tahun berada dalam kondisi “kadang berfungsi”
  • Sebuah tweet dikutip bahwa rm -rf node_modules tampak seperti sesuatu yang tak terhindarkan dalam pengembangan Node.js/JavaScript
• Kenyataan bahwa compiler serta pekerjaan pra/pasca-proses yang memakan beberapa menit atau beberapa jam tetap diterima bertentangan dengan ucapan bahwa “waktu programmer itu penting”
• Contoh memilih Hadoop bahkan dalam situasi ketika ia lebih lambat daripada menjalankannya di satu PC menunjukkan bahwa programmer tidak selalu membuat keputusan rasional
• Machine learning dan “kecerdasan buatan” dikritik karena memindahkan perangkat lunak ke era tebakan yang tidak dapat dipercaya
  • Sebuah tweet dikutip yang mengatakan bahwa aplikasi atau layanan yang menyebut “AI” atau “machine learning” dibaca sebagai tidak andal, tidak dapat diprediksi, dan sulit menjelaskan hasilnya
• Menjalankan VM di atas Linux, lalu menaruh Docker di dalam VM, ditafsirkan sebagai tanda bahwa kita tidak tahu cara merapikan program, bahasa, dan lingkungan eksekusi dengan bersih
  • Kenyataan bahwa berkas eksekusi tunggal Go disebut sebagai keunggulan utama memperlihatkan situasi di mana asal tidak berantakan sudah dianggap sukses
• Dependensi diperkenalkan ketika orang mencoba menyelesaikan masalah sederhana dengan “solusi paket lengkap”, sambil menarik masuk biaya adopsi dan dependensi lain
• Sulit menggunakan program selama bertahun-tahun tanpa restart, dan kadang-kadang bahkan sulit selama beberapa hari
  • Restart proses, menyalakan ulang basis data, watchdog yang me-restart aplikasi setiap 20 menit, menyertakan sumber daya duplikat, dan mengirimkannya dalam bentuk terkompresi adalah cara cepat lewat, bukan memperbaiki
• Praktik semacam ini bukan rekayasa, melainkan pemrograman malas, dan rekayasa berarti memahami secara mendalam kinerja, struktur, dan batasan dari apa yang dibuat

Kompleksitas yang menumpuk dan ketidakpedulian pasar

• Perangkat lunak saat ini adalah tumpukan kode yang sekadar berfungsi di atas kode lain yang juga sekadar berfungsi, terus membesar dan makin rumit sehingga peluang untuk mengubahnya makin kecil
• Ekosistem yang sehat kadang butuh proses mundur dulu sebelum maju, tetapi disebutkan bahwa selama 25 tahun kita tidak melihat kernel OS baru dan kini semuanya sudah terlalu rumit untuk ditulis ulang
• Browser juga sulit menulis ulang layout engine dari nol karena edge case dan masalah historis
• Kemajuan hari ini tampak seperti menuang bahan bakar ke api: memperkenalkan microservices untuk menyelesaikan masalah monolit, Docker untuk menyelesaikan masalah microservices, lalu Kubernetes untuk menyelesaikan masalah Docker
• Sebuah tweet dikutip yang mengatakan bahwa kita sudah berpindah dari konfigurasi deklaratif berbasis XML ke konfigurasi microservices berbasis YAML, tetapi setidaknya XML dulu punya skema
• Pengguna pada akhirnya hanya bisa menerima apa yang diberikan insinyur, dan dalam situasi seperti aplikasi Android 350MB, scroll tersendat, atau “kalau tidak berfungsi, reboot saja”, pilihan nyaris tidak ada
• Jika semua produk pesaing juga lambat, besar, dan berkualitas rendah, sulit muncul tekanan kompetitif
  • Produk yang sesekali menciptakan ketegangan seperti iPhone/iOS terhadap ponsel lain, atau Chrome terhadap browser lain, memang pernah muncul tetapi dianggap tidak bertahan lama
• Tugas insinyur seharusnya adalah menunjukkan apa yang mungkin dicapai komputer modern dalam hal kinerja, keandalan, kualitas, dan ketersediaan

Tetap ada alternatif yang terlihat

• LMAX Disruptor, SBE, dan Aeron karya Martin Thompson disebut sebagai contoh yang mengesankan, sederhana, dan efisien
• Xi editor karya Raph Levien dinilai dibuat dengan prinsip yang benar dalam pikiran
• Jonathan Blow membuat bahasa untuk gimnya sendiri, dan di laptopnya ia bisa melakukan kompilasi ulang penuh atas 500 ribu baris kode hanya dalam 1 detik
  • Hasil itu adalah kompilasi ulang penuh, bukan build inkremental maupun cache perantara
• Menulis program yang cepat tidak membutuhkan jenius atau sihir; cukup jangan membangunnya di atas tumpukan sampah raksasa seperti toolchain yang sedang tren

Tuntutan untuk perangkat lunak yang lebih baik

• Rekayasa perangkat lunak tidak boleh berhenti pada keadaan sekarang dan harus menjadi lebih baik; tidak perlu terus membuat hal yang sama dalam bentuk yang lebih lambat dan lebih besar
• Pengembangan saat ini lebih dekat ke sekadar memenuhi tujuan bisnis di atas alat yang compang-camping daripada benar-benar kemajuan
• Hasil dari terjebak pada optimasi lokal adalah kita menjadi terbiasa dengan keadaan yang membengkak dan tidak efisien
• Insinyur bisa dan harus membuat aplikasi yang lebih baik dengan alat yang lebih baik, secara berkali-kali lipat lebih hemat sumber daya, cepat, dapat diprediksi, dan andal
• Untuk menghasilkan produk berkualitas tinggi yang andal dan dapat diprediksi, kita harus sepenuhnya memahami apa yang dikerjakan dan alasannya; alasan “memang bawaan yang ada seperti ini” tidak bisa diterima

[xguru]

Artikel ini sudah pernah memiliki terjemahan bahasa Korea sebelumnya, jadi silakan lihat itu.

https://tonsky.me/blog/disenchantment/ko/

Tautannya sudah saya ubah langsung ke versi terjemahan.

[GN⁺]

Komentar Hacker News

• Kode yang lebih kecil, lebih bersih, lebih sedikit bug, lebih aman, lebih cepat, dan lebih awet jelas mungkin dibuat. Kalau itu bisa dilakukan pada awal era informasi, tidak ada alasan itu tidak bisa dilakukan sekarang ketika kita punya pengalaman puluhan tahun dan alat yang jauh lebih kuat
  Alasan itu tidak dilakukan adalah karena tidak ada uang di sana, atau lebih tepatnya justru sebaliknya. Startup yang didanai VC harus lebih dulu masuk ke pasar agar bisa bertahan hidup, dan bahkan di organisasi yang sudah matang pun biaya dan pembengkakan bukan diperlakukan sebagai masalah, melainkan seperti fungsi yang memperbesar gengsi manajer. Pada akhirnya biayanya dibebankan ke pelanggan
  Alasan “prinsip pasar yang kejam” tidak membetulkan pemborosan seperti ini tampaknya karena, meski codebase yang lebih baik suatu hari bisa mendapatkan kunci kerajaan, lingkungan persaingan nyata terlalu rentan terhadap patologi dan tren

  • Kagi tidak menerima pendanaan VC, tetapi tetap memiliki kode yang tidak optimal, banyak bug, dan masalah performa aneh di sana-sini. Dari sudut pandang orang yang paham pengembangan perangkat lunak, ini sulit dihindari terlepas dari sumber pendanaan atau ukuran perusahaan, dan lebih merupakan fungsi dari kompleksitas perangkat lunak, sumber daya yang tersedia, dan insentif
    Namun, ada satu hal yang lebih mudah dilakukan dibanding perusahaan yang didanai VC, yaitu mengalokasikan waktu untuk refactoring dan penanganan utang teknis. Saat ini kami memang sedang menginjak rem keras selama 45 hari pada pengembangan fitur baru untuk menangani masalah teknis utama. Jika Anda berharap akan diakuisisi tahun depan, sulit membuat investasi seperti ini, dan utang teknis menjadi masalah orang lain
    Selama produk terus dikembangkan, bug dan masalah baru akan terus muncul. “Kode yang sempurna” hanya mungkin dalam konteks tertutup ketika fitur baru tidak lagi ditambahkan
  • Kalimat “tidak ada uang di sana; justru sebaliknya” layak diulang. Inilah penyakit yang menelan dunia perangkat lunak, dan menjadikan perangkat lunak modern sebagai versi terburuk yang mungkin
    Saya rasa model pendanaan VC yang mendorong industri ke arah ini. Startup menerima jutaan dolar, lalu harus menghasilkan uang cukup cepat untuk mengembalikannya kepada investor, jadi mereka harus memeras uang dari aplikasinya secepat mungkin. Pekerjaan yang tidak punya metrik ROI tidak menarik perhatian siapa pun
  • Saya tidak melihat perangkat lunak lama sebagai sesuatu yang lebih aman. Pengguna komputer dulu hanya lebih polos dan lebih mudah percaya. Saat makin banyak mesin terhubung ke jaringan, kita belajar banyak hal
    Pada dasarnya dulu ada akses terbuka, tanpa kata sandi atau kata sandi pendek, penyimpanan kata sandi yang tidak aman, semuanya plaintext, sanitasi input diabaikan, hal-hal seperti telnet, dan seterusnya
    Di sini juga ada alasan lain mengapa perangkat lunak menjadi lebih bengkak. Kita mulai melihat interaksi dan risikonya, dan setelah melihatnya, kita tidak bisa pura-pura tidak melihat. Kondisi batas yang harus ditangani tidak berkurang, malah terus bertambah, dan perangkat keras yang harus didukung juga makin banyak
    Proses menulis kode yang berkinerja baik memang bisa ditingkatkan, tetapi pada saat yang sama garis dasarnya naik lebih cepat daripada kecepatan kita mencapainya. Menarik juga bahwa sekarang kita perlahan bergerak lagi ke arah tanpa kata sandi
  • Saya setuju bahwa insentifnya tidak selaras. Ada bidang industri tempat performa dan ketepatan benar-benar punya nilai nyata. Jika, seperti penulisnya, Anda menganggap craftsmanship perangkat lunak itu penting, pindah ke bidang seperti itu adalah cara terbaik untuk lebih menikmati pekerjaan
  • Secara sederhana, yang dirilis bukanlah kode melainkan fitur. Yang dirilis bukan injeksi dependensi otomatis, abstraksi elegan, atau trik compiler keren, melainkan fitur baru yang akan dibayar pelanggan
    Cakupan unit test yang tinggi, yang membuat refactoring jadi menyakitkan, sering kali menghambat rilis fitur, dan menurut saya itu terjadi jauh lebih sering daripada yang mau diakui para fanatik test-driven development. Banyak “praktik terbaik” di industri lebih mirip dogma tidak realistis yang dibuat oleh orang-orang di perusahaan yang sudah menemukan product-market fit dan uangnya mengalir sendiri

• Saya masih punya HP MS200 all-in-one yang nyaris masih bisa dipakai. Saya membelinya murah di garage sale pada 2017, dan jika dipasangi Linux, setelah Chrome dimuat, komputer itu masih bisa dipakai untuk panggilan video layar penuh Skype versi web atau menonton YouTube layar penuh
  Baru-baru ini saya mengambilnya lagi dan memasang FC38 serta Chrome terbaru sebelum menjadikannya komputer untuk anak, dan video YouTube berubah jadi slideshow. Saya utak-atik semua pengaturan tetap tidak berhasil, lalu menaikkan RAM dari 2GB menjadi 3GB, dan hasilnya kembali ke tingkat pemutaran layar penuh 720p seperti 6 tahun lalu
  Artinya, untuk melakukan hal yang sama sekarang dibutuhkan memori 1,5 kali lebih banyak, tambahan 1GB. Saya tahu orang bilang 16GB itu minimum, tetapi bahkan di mesin jelek ini pun Chrome pada dasarnya hanya browser web yang hampir menganggur, namun jejak memorinya terlihat sekitar 30GB. Mungkin sebagian besar adalah file yang di-mmap, tapi tetap saja 30GB

  • YouTube adalah contoh yang bagus untuk menunjukkan perbedaan performa. Kualitas video meningkat berkat codec terbaru, tetapi mesin lama atau murah tidak punya GPU terbaru sehingga harus melakukan decoding lewat perangkat lunak, dan kadang diproses dengan JavaScript, yang sangat boros tetapi tetap berjalan di semua mesin
    Sebaliknya, pada sebagian besar perangkat, peningkatan daya tahan baterai, suhu yang lebih rendah, serta kebutuhan RAM dan disk yang lebih kecil adalah perbaikan yang jelas. YouTube bisa saja menyimpan duplikat file encoding lama di server, tetapi itu jadi pemborosan ruang ketika mayoritas pengguna mengakses dari perangkat modern
    Sebagian besar kenaikan penggunaan RAM Chrome berasal dari perkembangan arsitektur sandbox. Memori bersama dan ruang proses bisa dipakai untuk serangan keluar dari sandbox, jadi isolasi makin ditambah, dan kebiasaan Chrome menjalankan proses independen baru untuk tiap tab dan ekstensi juga menjadi penyebab besar
    Akhir-akhir ini ad blocker juga berpengaruh besar. Karena web makin memburuk, makin sulit membuat pemblokir iklan yang efektif dan itu butuh lebih banyak sumber daya. Perangkat lunak lambat tidak melambat hanya untuk menyiksa orang; sering kali itu hasil dari mengubah hack berbahaya menjadi implementasi yang baik dan dari perubahan kebutuhan. FLV sudah tidak lagi cukup, dan h264 pun tampaknya sulit bertahan lama lagi dalam 5 tahun ketika h265 dan AV1 makin menyebar
  • Browser web pada dasarnya telah menjadi sistem operasi tersendiri. “Web modern” punya terlalu banyak fitur, dan bahkan untuk fungsi yang sama pun sering ada lima atau enam cara yang saling bersaing untuk mengimplementasikannya. Bahkan pada perangkat keras modern, hanya rendering teks saja bisa menjadi beban besar
    Toolchain modern berfokus pada “jangan menciptakan ulang roda”, tetapi jika setiap dependensi memilih versi roda yang berbeda, maka dengan menarik beberapa dependensi saja Anda bisa membawa masuk enam implementasi fungsi low-level yang sama
  • Setiap kali memasang Linux baru, saya mencoba memberi kesempatan pada UI bawaan, tetapi pada akhirnya sering kembali ke MATE. Namun, di mesin tua ini Gnome Shell terasa cukup tajam dan responsif, ada app store, dan ada Chrome juga
    Hanya saja yang terpasang adalah Flatpak, dan terasa bengkak. Untungnya, Chrome masih bisa dipasang langsung secara native lewat RPM, dan benar-benar memakai shared library milik OS
  • Saya ingat masa ketika menjalankan browser web grafis di Linux/X11 membutuhkan 8MB. Mungkin itu Netscape Navigator, dan 8MB sudah cukup, sedangkan 16MB terasa sedikit lebih nyaman

• Tulisan ini bahkan tidak menyentuh sumber penderitaan utamanya, yaitu bug. Hampir semua software terasa sebisa mungkin penuh bug. Setiap kali harus memakai software lewat jalur yang tidak umum atau alur yang tidak normal, rasanya ngeri, dan hampir selalu gagal
  Belum lama ini saat menjual mobil ke Carvana, saya akhirnya berhasil hanya dengan bolak-balik antara Chrome dan Firefox. Di Chrome, wizard unggah gambar melempar exception JS, dan bagian itu entah bagaimana hanya berhasil di Firefox, tetapi bagian lain dari situsnya jelas bermasalah seolah-olah mereka sama sekali tidak menguji di Firefox
  Yang lebih buruk, ketika pengguna nonteknis menemui bug, mereka mengira merekalah yang melakukan kesalahan. Sekarang saya malah rela menerima software yang besar dan lambat, asalkan stabil dan kokoh

  • Di satu sisi, sulit dipercaya hal-hal yang ada sekarang bisa berjalan sebaik ini. Semua lapisannya terasa seperti direkatkan dengan lakban dan permen karet, tetapi tetap benar-benar berfungsi. Apa yang dicapai manusia sungguh menakjubkan setiap hari
    Di sisi lain, saya terus melihat betapa penuh bug semuanya, dan saya tidak tahu apakah memang bug-nya makin banyak, atau saya yang makin tua dan makin paham isi dapurnya sehingga kesabaran saya terhadap pengembangan software ala perusahaan besar makin menipis. Saya kesal pada product person khayalan yang berkata, “rilis fitur X sekarang juga,” padahal bug UX yang jelas-jelas kentara pun mudah ditemukan
  • Sejak menonton ceramah Jonathan Blow tentang “akhir dunia”, saya jadi lebih memperhatikannya, dan ternyata ada sangat banyak pengalaman software yang buruk yang kita terima begitu saja setiap hari
    Saya paham, dan sampai taraf tertentu setuju, dengan argumen tentang biaya, biaya peluang, dan pragmatisme, tetapi kadang sulit menepis perasaan bahwa kita sekadar menerima hidup di dunia yang setengah jadi
  • Saat masih remaja, ketika MacBook Air generasi pertama keluar, seorang teman menemukan bahwa di unit demo toko ia bisa membuatnya crash secara konsisten hanya dengan membuka aplikasi di Dock secara cepat beruntun. Klik beberapa detik saja, mesinnya crash lalu reboot
    Sekarang pun rasanya tidak lebih baik. Jika anak kecil memegang ponsel atau laptop, hanya dengan menekan tombol terlalu cepat atau dalam urutan yang tak terduga, mereka bisa dengan cukup konsisten membuat perangkat modern macet, freeze, atau crash. Bukan dirusak secara fisik, tetapi begitulah kondisi teknologi modern
    Saya paham kenapa ini tidak diperbaiki. Orang-orang sudah terbiasa menganggap restart sesekali itu perlu, dalam kasus seperti ini mudah menyalahkan anaknya, dan restart biasanya menyelesaikannya. Meski begitu, mengingat siklus hidup sistem operasi, saya berharap sekarang kondisinya sudah lebih baik
  • https://danluu.com/everything-is-broken/
  • Saya tidak merasa software sekarang jauh lebih penuh bug dibanding dulu. Siapa pun yang pernah mendukung mesin Windows pada akhir 1990-an dan awal 2000-an pasti tahu

• Saya tidak membahasnya di tulisan tentang C, tetapi salah satu alasan besar saya memakai C adalah karena software jadi lebih sulit membengkak. Anda bisa menambah fitur, tetapi tidak mudah membuat satu fitur saja menambah 100KB ke executable
  Saat ini saya memang tidak bekerja sebagai karyawan, tetapi saya memakai mesin yang kuat untuk “pekerjaan”. Meski begitu, saya memakai Neovim dan tmux alih-alih IDE, lalu memakai Gentoo yang dimodifikasi besar-besaran alih-alih distribusi Linux biasa, OpenRC alih-alih systemd, dan Qtile sebagai tiling window manager alih-alih desktop penuh
  Saya menjaga mesin ini agar tidak bloat, sampai-sampai setelah boot dan baru login hanya ada 40 proses. Sekarang saya benar-benar sedang merekayasa software. Saya berusaha menjaga software tetap kecil dan cepat sambil secara efektif meredam masalah C, dan berharap suatu hari bisa membangun bisnis di atasnya
  Sepertinya kita akan melihat apakah masih ada pasar untuk software yang tidak bloat dan lincah
  https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
  https://gavinhoward.com/2020/12/my-development-environment-a...
  https://gavinhoward.com/2023/06/an-apology-to-the-gentoo-aut...
  https://gavinhoward.com/2023/09/lessons-learned-as-a-user-3-...

  • Sudut pandang yang menarik. Saya sudah cukup tua untuk mengingat masa ketika bahasa C dianggap bloat dibanding menulis langsung dalam assembly
    Program seperti WordPerfect, Lotus 123, MS-DOS 1.0, dan SubLogic Flight Simulator sebelum diakuisisi Microsoft ditulis dalam assembly. Pengamat industri saat itu melihat bahwa Microsoft bisa mengiterasi fitur baru di MS Word dan MS Excel lebih cepat serta mem-porting-nya ke arsitektur lain lebih cepat karena ditulis dalam C yang “bloat”, dibanding WordPerfect dan Lotus 123. Pesaing mereka terlalu lama bertahan di assembly
    Saya melihat trade-off yang sama di software pribadi. Jika memakai C#/Python yang lebih high-level dan “bloat” ketimbang C/C++ yang lebih ramping, Anda bisa menyelesaikan pekerjaan tertentu jauh lebih cepat. Saya lebih mahir di C++ dan lebih suka executable kecil, tetapi jika C# membuat pekerjaan yang saya inginkan selesai lebih cepat, keunggulan itu jadi tidak berarti. Saya juga bagian dari masalah software bloat
  • Menurut saya, “rekayasa sungguhan” adalah menempatkan keputusan seperti ini pada spektrum trade-off, lalu memosisikan proyek sesuai batasan pembuat dan penggunanya. Hasilnya memang bisa jatuh ke salah satu ujung ekstrem, tetapi itu tidak berarti orang yang berada di posisi lain karena batasan yang berbeda tidak melakukan “rekayasa sungguhan”
    “Saya akan membuat jembatan terkuat dan teringan di dunia” itu luar biasa, sedangkan “Saya akan membuat jembatan yang cukup ringan dan cukup kuat dengan biaya yang sanggup ditanggung pelanggan” itulah rekayasa
  • Anda bilang sulit bagi satu fitur untuk menambah bahkan 100KB ke executable, tetapi coba saja tambahkan dukungan Unicode
  • Saya penasaran apakah Anda bisa menjelaskan lebih lanjut soal “secara efektif meredam masalah C”. Apakah yang dimaksud menyelesaikan masalah pada bahasanya sendiri, memakai dialek C baru, masalah ekosistem seperti sulitnya static linking glibc, atau sebenarnya membicarakan hal yang sama sekali berbeda
  • Saya bisa memahami ucapan “saya pernah menolak tawaran kerja C++”

• Saya berhenti setelah membaca sedikit lebih dari setengahnya, tetapi argumen intinya tampak seperti perangkat lunak harus cepat, dan saya tidak ingat ada pembenaran untuk filosofi itu selain kesan implisit bahwa “itu memang kebenaran”. Memang diakui ada sanggahan bahwa peningkatan efisiensi kadang sama sekali tidak menutup biaya waktu yang dihabiskan untuk mengejar efisiensi, tetapi argumen itu dilewati tanpa benar-benar bergulat dengannya
  Ciri utama lain dari tulisan itu adalah memilih data secara cherry-picking dan terlalu menyederhanakan ranah masalah. Ia berulang kali membuat seruan emosional, “Sebenarnya perangkat lunak memakai waktu dan ruang itu untuk apa?”, tetapi tidak berusaha menjawab pertanyaan itu dengan serius, lalu menggunakan ketiadaan jawaban seolah-olah itu bukti bahwa jawaban yang ada salah. Ia juga membandingkan beberapa perangkat lunak yang tidak setara secara fungsional seakan-akan perbedaannya hanya pada performa
  Ada banyak yang bisa dibahas soal biaya sosial, lingkungan, dan bisnis dari inefisiensi, serta tentang perangkat lunak yang lebih efisien, tetapi juga layak dibahas bahwa perangkat lunak modern memungkinkan orang yang tadinya tidak akan bisa membuat apa pun untuk membuat sesuatu yang “buruk” namun mereka butuhkan. Seperti insinyur struktur memilih sesuatu yang “cukup kuat”, pengembang modern juga sering menargetkan sesuatu yang “cukup cepat”
  Ada banyak bahan untuk perdebatan yang kaya, tetapi tulisan ini berhenti pada kemarahan emosional dan gagal menangani rasionalitas serta argumentasi yang sesungguhnya. Beberapa klaimnya memang mengandung kebenaran, tetapi menurut saya tulisannya sendiri sudah jelas menunjukkan bahwa ia tidak berniat berdiskusi

  • Dari sudut pandang pengguna, perangkat lunak memang harus cepat. Cukup pikirkan apakah komentar ini ditulis di iPhone 4 atau 14, atau apakah workstation Anda adalah Pentium dengan RAM 4GB
    Jaringan Anda juga kemungkinan besar bukan lagi 2G beberapa kbps, melainkan 5G atau fiber ratusan Mbps. Pada akhirnya tindakan berbicara lebih keras daripada kata-kata, dan jika masyarakat secara keseluruhan mengikuti aksioma “perangkat lunak yang lebih cepat”, maka itu bisa diterima sebagai fakta
    Terutama karena ini berasal dari aksioma yang sama dengan klaim “waktu developer lebih berharga”; bedanya hanya waktu siapa yang ingin dihemat
  • Jika kode membutuhkan beberapa detik di Mac M1 yang mahal, maka persentase yang cukup besar dari calon pengguna mungkin harus menunggu beberapa menit. Pengguna nonteknis sering kali menerima absurditas seperti itu begitu saja karena mereka tidak tahu bahwa performa bisa meningkat besar tanpa harus membeli perangkat keras baru
    Jika developer tidak menguji di perangkat berspesifikasi rendah, mereka bisa sama sekali tidak menyadari masalah ini. Masalah sebenarnya, lebih dari sisi teknisnya, adalah sikap sebagian developer yang menjadi defensif dan mulai berdebat saat berhadapan dengan kenyataan tidak nyaman bahwa kode mereka terlalu lambat. Mereka harus duduk bersama manajer produk, menyediakan waktu untuk profiling dan optimasi, dan melihat bagaimana mengurangi masalah performa tanpa harus membangun ulang dari nol
  • Saya suka kemarahan emosionalnya. Kadang data hanya mengaburkan kebenaran yang sebenarnya sudah kita tahu. Kita tidak perlu menunggu data untuk mengatakan bahwa kita harus melakukan yang terbaik demi membuat perangkat lunak terbaik, dan tulisan ini mengingatkan hal itu
  • Dari pernyataan “perangkat lunak modern memungkinkan orang membuat sesuatu yang buruk”, saya tidak mengerti apa tepatnya yang istimewa dari perangkat lunak modern. Juga tidak jelas apa kriteria sesuatu disebut modern
    BASIC dan SQL sejak lama juga ditujukan agar orang bisa membuat sesuatu yang “buruk”, demikian pula Fortran dan banyak bahasa/teknologi lain yang kini sudah hilang
    Python atau Java, kalaupun dinilai dengan murah hati, tetap konservatif, dan jika melihat perkembangan bahasa pemrograman di tahun 70-an, keduanya justru pantas disebut anakronistik. J dan Prolog secara konseptual jauh lebih maju daripada Rust atau Go, tetapi dibuat lebih awal. Dari C89 sampai C23, apakah akumulasi C itu bahasa modern, atau hanya C23 yang modern, dan apakah benar ada perbedaan besar antara C89 dan C23, itu pun samar
    Jadi saya penasaran apakah ada cara lain untuk mendefinisikan kemodernan, selain berdasarkan waktu dibuatnya atau pohon evolusi imajiner
  • Menurut saya penulis sudah menjawab pertanyaannya sendiri di paragraf awal: “Hanya di perangkat lunak kita menganggap tidak apa-apa jika program berjalan pada 1% atau 0,01% dari performa yang memungkinkan. Semua orang tampaknya baik-baik saja dengan itu.” Jika semua orang memang baik-baik saja, ya sudah, lanjut saja

• Ini keluhan lama. Banyak kenyamanan yang kita anggap biasa punya biaya, dan biaya itu menumpuk besar. Layar 4K punya 17 kali lebih banyak piksel daripada 800x600, dan dengan warna 32-bit, ukuran mentah grafis untuk layar modern menjadi sekitar 68 kali lebih besar
  Dulu gambar statis sudah cukup, tetapi sekarang animasi berkualitas tinggi dengan frame rate tinggi sudah menjadi standar. Arial Unicode adalah font 15MB, dan kemungkinan bahkan tidak muat di memori kebanyakan komputer yang menjalankan Windows 95
  Pemeriksa ejaan di mana-mana kini dianggap wajar, dan hal-hal seperti ini terus bertambah. Meski begitu, semuanya membuat komputer jauh lebih nyaman dipakai. Saya tidak merindukan mode video 16 warna, atau masa ketika mustahil memakai dua bahasa non-Inggris sekaligus tanpa akal-akalan yang sangat menyebalkan

  • Bahkan dengan batasan 4K dan Unicode yang sama, ada aplikasi yang lebih efisien beberapa orde magnitudo, jadi itu saja tidak cukup sebagai penjelasan
  • Memang ada biayanya, tetapi biaya itu tidak selalu sepadan. Saya menginginkan layar 4K dan bersedia membayar harga piksel itu
    Tetapi saya tidak menginginkan animasi yang tujuannya cuma membuat waktu tunggu terasa kurang membosankan. Unicode juga layak dibayar
    Namun teks seharusnya tetap bisa dirender ke layar dalam hitungan milidetik satu digit, seperti pada 1981. Piksel dan glif memang lebih banyak, tetapi itu tetap mungkin; hanya saja bukan prioritas
  • Saya paham semua keluaran kini memakan jauh lebih banyak sumber daya, tetapi tetap perlu penjelasan mengapa perangkat lunak masih terasa menyakitkan lambatnya meski memakai 100 kali lebih banyak sumber daya komputasi
    Mirip seperti membayar $100.000 untuk BMW performa tinggi, lalu insinyur berkata akselerasi 0-60mph butuh 30 detik, dan pengguna seharusnya menerima saja karena mereka bukan pakar performa

• Saya juga melihat arus yang mirip di organisasi saat ini. Di awal, ketika tim masih kecil, detail itu penting. Tidak boleh lambat, animasi harus mulus, kecepatan scroll dan waktu muat penting, dan kami berusaha membuat produk yang paling efisien untuk meningkatkan efisiensi pengguna
  Seiring tim membesar, nilai yang dikejar berubah ke arah meningkatkan efisiensi developer. Lebih banyak abstraksi, lapisan, dan framework masuk, dan kompromi yang menghabiskan jutaan detik waktu pengguna demi menghemat satu hari kerja developer pun diterima
  Perbedaannya ada pada visibilitas. Eksekutif bisa melihat biaya pengembangan, tetapi tidak bisa melihat manfaat dari waktu eksekusi yang sedikit lebih cepat, caching yang lebih baik, atau scroll yang lebih mulus. Karena itu tidak diukur. Saat organisasi mencapai titik hanya peduli pada angka yang bisa diukur, arus seperti ini terasa alami

  • Tinggal tunggu saja dampak buruk LLM terhadap kualitas dan performa kode dalam beberapa tahun ke depan. Gelombang programmer baru adalah para “pembisik GPT”, yang menghabiskan sebagian besar waktunya bergantung pada chatbot, bahkan di dalam IDE, dan membiarkan chatbot yang memprogramkan semuanya
    Tentu saja, ini hanya sampai AI mencapai titik di mana ia bisa memperbaiki apa yang kita tulis dengan buruk, atau yang AI tulis dengan buruk, dan bahkan AI yang sendiri sangat tidak efisien seperti diprediksi tulisan aslinya
  • Ini bukan cuma soal keterukuran, tetapi juga soal profitabilitas. Kapitalisme menghasilkan produksi yang efisien, bukan produk yang efisien. Karena ia hanya tertarik mengekstrak laba dari sistem produksi
    Mobil baru dioptimalkan setelah ada guncangan minyak dari luar, dan itu pun sangat tidak merata. Faktanya, produk yang tidak efisien sering kali lebih menguntungkan karena pelanggan harus lebih sering menggantinya. Kabel iPhone murahan yang retak setelah setahun memungkinkan Apple menagih biaya penggantian lagi dan lagi. Peralatan rumah tangga lebih sering rusak tetapi dibuat lebih murah sehingga menaikkan laba per unit. Yang penting bukan efisiensi penggunaan setelah penjualan, melainkan efisiensi produksi
    Dalam software, kapitalisme bekerja dengan mendorong otomatisasi baru secepat mungkin dan membuat konsumen menanggung pemborosan energi dan waktu. Rantai produksi makin distandardisasi dan dioptimalkan sehingga developer React atau admin Kubernetes bisa diganti seperti pekerja gudang, dan muncul pula tekanan upah. Sebagian otomatisasi lebih mirip pembenaran diri, seperti istilah akuntansi yang dibuat rumit untuk membenarkan profesi itu sendiri, dan sisanya soal laba

• Segala sesuatu ada biayanya. Jika biaya komputasi atau buruknya pengalaman pengguna cukup besar, maka efisiensi akan dioptimalkan. Model ML adalah contohnya. Dalam kasus lain, itu tidak dioptimalkan, karena pengguna akhir tidak menginginkannya sampai harus mengorbankan fitur yang lebih sedikit
  Mobil dulu juga boros bahan bakar, tetapi berubah ketika biaya bahan bakar dan kekhawatiran lingkungan membuat pelanggan menginginkan hal lain. Banyak engineer lupa bahwa mereka dibayar untuk membuat produk bagi pelanggan
  Penulis asli juga tampaknya belum pernah menunggu mesin Windows atau Linux lama sampai benar-benar selesai booting. Versi modern boot jauh lebih cepat karena itulah yang diinginkan pelanggan. Ponsel menyala 24 jam, jadi boot yang lama sekali setiap beberapa bulan bukan hal yang dipedulikan pelanggan

  • Waktu boot tetap mengerikan. Terutama pada sistem AM5/DDR5 terbaru
    BIOS saya butuh sekitar 20 detik untuk POST, dan katanya itu normal. Setelah itu boot OS sekitar 10 detik
  • Saya tidak tahu kapan pelanggan pernah benar-benar punya pilihan yang berarti atau cara untuk menyatakan preferensi. Sudah lama ini pasar yang didorong oleh pasokan, di mana pemasok membuat apa yang ingin mereka buat dan pelanggan membeli apa yang tersedia di pasar
  • Di PC sekolah, boot WordPerfect benar-benar butuh beberapa menit
  • Pernyataan “engineer dibayar untuk membuat produk bagi pelanggan” memang ada benarnya, tetapi software dalam banyak hal telah menjadi elemen inti kehidupan manusia seperti listrik atau layanan kesehatan
    Kita bisa bilang dokter atau engineer juga dibayar untuk mengembangkan obat baru atau sumber listrik baru, tetapi bidang-bidang ini sensitif dan penting sehingga ada banyak lapisan pengawasan pemerintah. Software belum punya tingkat pengawasan seperti itu
  • Sebagian benar, tetapi ketika perusahaan sebesar Google atau Apple menentukan arus, mereka tidak bisa berpura-pura sekadar mengikuti keinginan pelanggan seperti perusahaan kecil atau menengah
    Mereka punya kekuatan untuk membentuk lingkungannya sendiri, sehingga bisa sangat mengubah arah hasil dari “permintaan pelanggan” itu

• Ini tulisan dari 2018, dan sudah ada beberapa diskusi sebelumnya
  https://news.ycombinator.com/item?id=18012334 (Sep 2018)
  https://news.ycombinator.com/item?id=21929709 (Jan 2020)
  https://news.ycombinator.com/item?id=31798580 (Jun 2022)

• Sangat relate. Sebagai developer, penting untuk mengingat bahwa kita punya pilihan. Kita memang tidak bisa memilih segalanya, tetapi kita bisa memilih alternatif yang tidak terlalu buruk
  Kita tidak harus memakai Node. Di ekosistem .NET atau JVM pun kita bisa menulis software yang hebat dan kompatibel ke belakang, serta berharap itu tetap berjalan tanpa perubahan 10 tahun kemudian
  Kita juga tidak harus membuat halaman web satu halaman. HTML gaya lama yang memuat ulang halaman sepenuhnya setiap kali diklik juga bekerja dengan baik, dan pada titik ini latensinya bahkan bisa lebih rendah
  Kita juga tidak harus membuat aplikasi desktop dengan Chromium. Memulai framework UI memang butuh sedikit lebih banyak kerja, tetapi kualitasnya sepadan. Kita memang tidak selalu punya kuasa mengambil keputusan, tetapi saat punya, kita harus keluar dari pilihan yang buruk

  • Pola pikir “semuanya harus SPA” akhir-akhir ini menyedihkan. Saya paham aplikasi kompleks seperti GMail mendapat manfaat dari SPA, tetapi terlalu banyak tempat tetap memaksakan kompleksitas frontend padahal fungsi yang sama bisa dibuat dengan jauh lebih cepat dan jauh lebih sedikit bug hanya dengan CSS/HTML dasar dan sedikit jQuery
  • Saya sampai terkesiap mendengar klaim bahwa di ekosistem .NET kita bisa menulis software yang kompatibel ke belakang dengan baik. Inisiatif .NET Core benar-benar merusak banyak kode, dan Microsoft menghentikan banyak library. Tentu, sebagian memang punya alasan yang sangat masuk akal, dan banyak library .NET lama juga punya pilihan desain yang cukup buruk