Apakah Abstraksi Perangkat Lunak Menghancurkan Peradaban? (2021)

• Kekhawatiran Jonathan Blow bahwa “abstraksi melemahkan kemampuan esensial untuk memelihara perangkat lunak” valid dari sisi pewarisan pengetahuan, tetapi banyak contoh yang ia jadikan dasar keliru membaca sejarah dan konteks
• Perdebatan tentang “five nines”, perangkat lunak yang tangguh, stagnasi kemajuan teknologi, dan turunnya produktivitas banyak bergantung pada contoh selektif atau gagal membedakan perangkat konsumen dan sistem high availability
• Kekhawatiran hilangnya pengetahuan level rendah sebagian masuk akal, tetapi C, assembly, Rust, porting sistem operasi, pendidikan compiler, dan aktivitas open source masih tetap menjadi jalur untuk mempertahankan kapabilitas sistem
• Abstraksi seperti sistem operasi, file system, jaringan, multitasking, dan framework memang menambah kompleksitas, tetapi juga meningkatkan portabilitas, produktivitas, dan aksesibilitas kreasi sambil menanggung perubahan hardware dan ekspektasi pengguna
• Risiko yang lebih besar daripada abstraksi itu sendiri adalah churn berkelanjutan, platform yang terkunci, iklan, tracker, telemetri, serta melemahnya privasi dan kebebasan; fondasi teknis untuk memelihara sistem penting harus terus dijaga

---

Posisi dasar terhadap argumen Blow

• Ceramah Jonathan Blow memiliki alur bahwa abstraksi perangkat lunak menyebabkan hilangnya pengetahuan pemrograman level rendah, dan pada akhirnya bisa berujung pada runtuhnya peradaban karena kita tidak lagi mampu memelihara perangkat lunak esensial
• Saya setuju dengan pentingnya pewarisan pengetahuan, tetapi untuk mendukung klaim semacam itu, contoh dan konteks historisnya harus akurat
• Sanggahan utamanya adalah bahwa contoh-contoh Blow banyak bergantung pada salah paham, contoh selektif, dan bukti anekdotal, serta melewatkan sebagian sejarah komputer

Perdebatan “five nines” dan ketangguhan

• Blow berargumen bahwa dalam penjualan sistem komputer dulu, “five nines”, yaitu uptime 99,999%, digunakan sebagai retorika kualitas, tetapi laptop masa kini tidak mencapainya
• Memang benar bahwa five nines berarti downtime sekitar 5 menit per tahun, tetapi klaim bahwa metrik ini dipakai untuk menjual laptop konsumen atau word processor dianggap keliru
  • Five nines biasanya diterapkan pada bidang seperti pusat panggilan darurat semacam 911, sistem rumah sakit, dan pemrosesan transaksi keuangan
  • Metrik ini sering digunakan bersama kontrak jangka panjang yang mendefinisikan secara rinci kondisi apa saja yang tidak termasuk downtime
  • Perusahaan seperti IBM dan Amazon masih menjual sistem dan layanan semacam ini
• Klaim bahwa perangkat lunak yang tangguh tidak muncul selama puluhan tahun juga memiliki kontra-contoh
  • iPhone dapat berjalan selama berminggu-minggu atau berbulan-bulan tanpa reboot
  • Server file dan printer Novell memiliki kasus uptime 16 tahun
  • Unix, Windows, perangkat VMS, dan sistem turnkey seperti IBM i juga disebut sebagai contoh ketersediaan jangka panjang

Sanggahan tentang kemajuan teknologi dan produktivitas

• Ada sebagian kebenaran dalam pernyataan bahwa “perusahaan teknologi tidak lagi mendorong teknologi ke depan”, tetapi perusahaan yang lebih mementingkan uang juga sudah ada di masa lalu
• Bidang yang “membosankan” seperti file system, web server, database, dan bahasa pemrograman juga terus dikembangkan dan diperbaiki
• Lapisan abstraksi, virtualisasi, dan containerization yang tidak disukai Blow juga terus diperbaiki lewat banyak upaya, dan sekadar tidak menyukainya tidak membuatnya bukan kemajuan teknologi
• Klaim bahwa produktivitas karyawan Facebook mendekati nol bergantung pada asumsi bahwa produk Facebook hanya dilihat sebagai fitur platform sosial
  • Karyawan perusahaan Facebook mencakup berbagai peran seperti hukum, akuntansi, desain grafis, administrasi sistem, riset, HR, dan manajemen menengah
  • Ada juga bisnis lain seperti Instagram, WhatsApp, dan Oculus VR
  • Produk Facebook yang sebenarnya adalah platform penyampaian iklan; pekerjaan mengumpulkan privasi dan data pribadi lalu mengubahnya menjadi iklan tertarget tidak terlihat sebagai fitur pengguna, tetapi muncul sebagai pendapatan

Dua sisi pengetahuan level rendah dan abstraksi

• Fakta bahwa banyak programmer lebih menyukai lingkungan yang tidak mengharuskan mereka menangani alokasi memori dan pointer diakui sebagai benar
• Abstraksi berlebihan seperti merender blog sederhana dengan framework JavaScript yang tidak perlu, atau aplikasi desktop yang berjalan lambat di dalam browser bundled, dipandang sebagai masalah
• Namun saat ini, jumlah orang yang bisa menggunakan C dan jumlah kode C maupun assembly yang ditulis bisa saja lebih banyak daripada dulu
  • Linux dan NetBSD terus di-port ke berbagai target yang tampak seperti CPU
  • Rust berfokus pada ketangguhan sekaligus tetap menyediakan pointer dan manajemen memori
  • Harvard CS50 membahas layout memori, pointer, malloc(), dan free() dalam kuliah publik
• Garbage collection dan pemrograman fungsional bukan abstraksi baru
  • Lisp sudah menyediakan keduanya pada akhir 1950-an
  • Lisp juga digunakan di lingkungan “hardcore” seperti NASA Jet Propulsion Lab
• COBOL tidak dibahas dalam ceramah Blow, tetapi sebagai bahasa tingkat tinggi yang menjadi fondasi infrastruktur perbankan dan keuangan, ia memainkan peran penting bagi tingkat peradaban saat ini

Kasus “Unix 3 minggu” Ken Thompson

• Pencapaian Ken Thompson yang membuat assembler, editor, dan kernel dasar dalam 3 minggu dinilai sangat luar biasa
• Namun seberapa tangguh, seberapa ramah pengguna, dan fitur apa saja yang dimiliki perangkat lunak pada titik itu tidaklah jelas
• Kondisi kerja saat itu sangat berbeda dari kondisi developer masa kini
  • Dokumentasi, code review, daily stand-up, penataan backlog, user story, unit test, kebutuhan pelanggan, A/B test, pesan commit, dan standar coding perusahaan kini melekat pada pengembangan
  • Lingkungan open office yang penuh gangguan juga bisa berbeda dari lingkungan kerja individual ala Bell Labs
• Satu kasus Thompson bukan bukti bahwa seluruh programmer masa lalu lebih produktif
  • Thompson juga terlibat dalam Multics yang terkenal tertunda
  • Proyek besar seperti IBM OS/360 juga lama tertunda, dan Frederick P. Brooks menulis 『The Mythical Man-month』 pada 1975 berdasarkan pengalaman semacam itu

Kemajuan perangkat lunak dan ekspektasi pengguna

• Secara umum, komputer menjadi lebih tangguh dibanding beberapa dekade lalu, dan programmer setidaknya sama produktifnya seperti dulu
• Namun dalam beberapa kasus, memulai sesuatu menjadi lebih rumit sehingga bisa menurunkan produktivitas awal
• Pengguna modern tidak ingin mempelajari RPN untuk aritmetika sederhana, atau menulis direktif troff untuk membuat selebaran
• Antarmuka yang nyaman dan fitur tingkat lanjut meningkatkan kompleksitas dan waktu pengembangan terlepas dari abstraksi
• Kasus crash saat menyalin file di Amiga OS lama hingga merusak partisi hard drive menunjukkan bahwa sistem masa lalu tidak selalu lebih stabil
  • OS komputer rumah modern memiliki proteksi memori dan journaling file system, sehingga masalah yang sama jauh lebih jarang terjadi
  • Windows 10 Home pun, meski punya kekurangan, mencakup kemajuan seperti ini

Klaim bahwa “dulu bisa dilakukan begitu saja”

• Menyalin dan menjalankan program

  • Menyalin program dari satu komputer ke komputer lain lalu menjalankannya masih mungkin jika arsitektur target dan kondisi kompilasinya sama
  • Ada kasus binary statically linked slack-term yang dibangun dengan Go berjalan di beberapa Raspberry Pi
  • Namun masa ketika program standalone bersifat umum harus ditarik mundur sampai era C64 atau PC/XT; Deluxe Paint IV di Amiga pun bergantung pada beberapa file pendukung dan library fungsi pihak ketiga
  • Sebagian game Amiga menggunakan floppy track-loaded yang melewati file system dan bekerja seperti semacam container versi zamannya, tetapi punya kelemahan karena menghambat instalasi hard disk dan multitasking

• Klaim bahwa kode berjalan asal CPU-nya sama

  • Secara teori, memang mungkin menaruh machine code di memori pada CPU yang sama lalu mengarahkan program counter untuk menjalankannya
  • Namun untuk pekerjaan nyata seperti output grafis, pemutaran suara, pemrosesan input, dan penulisan disk, perbedaan hardware menjadi masalah besar
  • Komputer rumahan berbasis Z80 di masa lalu pun memiliki CPU yang sama, tetapi hardware periferalnya berbeda sehingga porting nyata sulit dilakukan
  • Justru program pada tingkat abstraksi yang lebih tinggi seperti Basic bisa lebih mudah di-port antar mesin
  • Dengan Apple merilis lini desktop berbasis ARM, bergantung pada abstraksi alih-alih melekat langsung ke metal dapat mengurangi beban porting ke CPU baru

• Sistem operasi dan akses hardware

  • Sistem operasi tidak hanya merampas kemampuan CPU, tetapi juga menambahkan kemampuan seperti file system, networking, dan multitasking
  • Pengguna seperti streamer Twitch yang perlu menjalankan game bersama program lain membutuhkan multitasking yang membagi sumber daya hardware secara terkelola dan dapat diprediksi
  • Sebagian software Amiga dan Atari mengakses hardware dan memori secara langsung alih-alih mengikuti spesifikasi dan abstraksi yang disediakan produsen, sehingga upgrade kecil seperti memori atau hard disk pun bisa merusak perilakunya
  • Software yang ditulis sesuai spesifikasi dan abstraksi tetap bisa dijual setelah perubahan hardware

• Grafis, program tanpa tanda tangan, LSP

  • Menggambar piksel di layar masih mungkin dalam banyak bahasa, dan Mode 13h pun diakses melalui VGA BIOS, sebuah lapisan abstraksi hardware awal
  • Kode yang bergantung pada hardware VGA tertentu tidak portabel, tetapi program grafis yang menggunakan abstraksi Windows dapat berjalan di berbagai lingkungan dari Hercules hingga true-color XGA
  • Menjalankan program tanpa tanda tangan juga mungkin, dengan contoh mengompilasi sendiri WordGrinder untuk dipakai
  • Sebagian keluhan Blow lebih dekat ke masalah produsen hardware dan software yang mengunci sistem serta mengurangi hak pengguna daripada ke abstraksi
  • Untuk Language Server Protocol, saya secara umum setuju dengan pihak Blow, tetapi LSP menyelesaikan masalah yang lebih luas daripada sekadar “mengklik metode untuk lompat ke definisi”

Game, performa, dan multitasking

• Di antara aplikasi produktivitas modern, ada banyak contoh penurunan performa dan input lag yang serius
• Sebagian penyebabnya adalah abstraksi, tetapi masalah yang lebih besar adalah kode buruk dan pemilihan tool yang tidak cocok untuk tugasnya
• Bahkan di antara program yang memakai platform dan UI toolkit yang sama, performa yang dirasakan pada mesin yang sama bisa sangat berbeda
• Masalah yang diajukan Blow tentang game yang gagal memulihkan resolusi setelah Alt-Tab adalah pengalaman buruk dan harus diperbaiki
• Namun game DOS di masa lalu sederhana karena tidak perlu memedulikan proses lain
  • Untuk memainkan Doom di Windows 3.1, pengguna harus menyimpan pekerjaan, menutup program, keluar dari Windows, lalu memulai game
  • Game Amiga pun sering boot dari floppy, mengambil alih mesin sepenuhnya, dan tidak bisa kembali bersih ke OS
• Multitasking game masa kini, meski belum sempurna, dipandang membaik dibanding masa lalu

Hilangnya pengetahuan dan laju perubahan

• Blow melihat pengetahuan seperti pengelolaan sprite di Unity berubah menjadi pengetahuan serba-serbi, bukan pemahaman mendalam
• Saya setuju bahwa laju perubahan software dan hardware modern sering kali terlalu cepat untuk diikuti secara bermakna
• Namun ini lebih dekat ke masalah konsistensi dari waktu ke waktu dan model distribusi software daripada abstraksi itu sendiri
• Arus merilis sesuatu setiap 4 minggu dapat membuat pengguna sulit mendapatkan pengalaman yang stabil
• Jika UI sering diubah, pengguna harus terus bergulat dengan detail antarmuka yang berubah alih-alih melakukan pekerjaan sebenarnya

Kompleksitas adalah masalah buatan manusia

• Blow berargumen bahwa kompleksitas bisa dikurangi jika kita memutuskan untuk menguranginya, dan bahwa kita keliru mengira penambahan abstraksi akan menghemat waktu
• Framework yang tepat untuk penggunaan yang tepat dapat sangat membantu web developer
• Pada saat yang sama, ada alasan untuk skeptis terhadap upaya melakukan segalanya di browser, dari word processing hingga game, atau sikap langsung berpindah setiap kali framework baru muncul
• Kompleksitas perangkat lunak bukan hanya masalah programmer, tetapi juga dibentuk oleh pasar dan lingkungan organisasi
  • Politik internal, rapat yang tidak bermakna, software pelaporan waktu yang rumit, tenggat yang ditetapkan pihak luar, kebutuhan pelanggan yang sulit, keputusan manajemen yang aneh, estimasi jadwal untuk kebutuhan abstrak, dan debugging kode legacy memengaruhi pilihan developer
• Kompleksitas adalah masalah buatan manusia, dan mengurangi kompleksitas di tempat kerja dalam jangka panjang juga dapat mengurangi kompleksitas perangkat lunak

Developer muda dan kemampuan membuat engine

• Klaim Blow bahwa developer game muda belum pernah menulis engine sendiri dan segera bisa melupakannya secara kolektif lebih dekat ke logika slippery slope
• Kebanyakan orang yang memiliki C64, Amiga, atau PC 286 tidak menjadi developer level rendah, dan banyak juga yang tidak menjadi programmer
• Abstraksi dan game engine siap pakai memungkinkan kreasi tanpa harus mempelajari manajemen memori level rendah, pointer, dan algoritme
• Anak-anak masa kini ingin membuat sesuatu yang mirip game AAA yang mereka beli di toko, dan ekspektasi terhadap game modern jauh lebih tinggi daripada era C64 atau Amiga
• Jalur untuk mempelajari teknologi level rendah masih ada
  • Linux menarik developer muda melalui komunitas open source dan mendorong minat pada bahasa sistem seperti Rust, C, dan C++
  • dwm adalah window manager yang dikonfigurasi dengan memodifikasi source code C
  • Ada developer muda yang memakai C dan assembly Z80, orang yang membuat distribusi Linux dari nol, orang yang membuat hardware sendiri, dan developer C yang menjalankan OS riset di hardware modern
  • Program ilmu komputer dan teknik elektro terus mengajarkan dasar seperti C, assembly, dan desain compiler
  • Akses ke tool pemrograman, literatur, video edukasi, dan materi seperti MIT OpenCourseWare lebih murah dan lebih baik daripada dulu

Kesimpulan akhir: masalah yang lebih besar daripada abstraksi

• Kesimpulan Blow lebih mirip survivalisme yang diterapkan pada teknologi, dan analogi bahwa kita membutuhkan orang yang tahu cara menyalakan api saat listrik padam dapat dipahami
• Masyarakat bergantung pada kemampuan menjalankan sebagian program hampir secara terus-menerus
  • Jika gagal, konsekuensi serius seperti runtuhnya ekonomi dunia atau gagalnya sistem kesehatan nasional bisa terjadi
  • Karena catatan historis dan modern semakin banyak disimpan secara digital, catatan itu harus tetap dapat diakses di masa depan
• Kompleksitas itu rapuh dan abstraksi dapat menciptakan ketidaktahuan yang berbahaya; shadow DOM tidak diperlukan untuk merender blog sederhana, dan IRC client bergambar tidak perlu memakai cangkang browser
• Namun churn berkelanjutan yang artifisial juga merupakan penyebab besar kerapuhan
  • Pengembangan “Agile” dimaksudkan agar hal yang belum selesai dan belum diuji tidak dirilis, tetapi dalam praktiknya rilis yang belum selesai terus bermunculan
  • Sistem iklan, tracker, dan telemetri pada dasarnya bekerja seperti backdoor by design, menambah kerentanan dan ketidaknyamanan
• Masalah yang lebih besar di dunia digital adalah privasi dan kebebasan
• Alasan kita tidak lagi bisa berinteraksi langsung dengan hardware mungkin bukan karena kita memilih abstraksi, melainkan karena yang tersisa semakin banyak hanyalah platform yang terkunci dan dikendalikan jarak jauh

[GN⁺]

Pendapat Hacker News

• Saya mengajar kelas sistem di Montana State yang membahas dari transistor hingga sistem komputasi nyata, dan saat kelas dimulai ada juga mahasiswa yang tidak benar-benar tahu apa itu sistem berkas
  Blow memang keliru dalam beberapa detail, tetapi menurut saya untuk mahasiswa jurusan teknologi, pendidikan ala NAND-to-Tetris sejak SMA perlu dipertimbangkan secara serius
  Kami memakai model “kuno” seperti Little Man Computer atau emulator MIPS visual sederhana; meski tidak realistis, kompleksitasnya masih bisa dipahami orang biasa dan memberi gambaran dari mana kita berasal
  Kalau melihat buku teks arsitektur 64-bit yang belakangan direkomendasikan, saya cuma bisa tertawa, dan menghubungkan teknologi sampai ke akarnya memang masalah yang sulit

  • Konsep berkas dan sistem berkas berguna bahkan bagi pengguna komputer umum yang tidak peduli cara kerja internalnya
    Masalahnya ada pada sistem operasi mobile dan perusahaan perangkat lunak yang berusaha sebisa mungkin menjadikan data pengguna sebagai taman berpagar di dalam aplikasi
    Bahkan ketika kita sudah bekerja dengan berkas, mereka membuat kita “mengimpor” data lama ke penyimpanan mereka, lalu versi yang sudah diubah harus “diekspor” atau “dibagikan” sendiri sebagai salinan baru
  • Saya sendiri sudah cukup dekat dengan tipe orang tua yang suka menggerutu, tetapi saya sudah berhenti berharap pada generasi “mahasiswa” sekarang
    Saya sedang mengambil magister teknik industri di Montana State, dan setiap hari berurusan dengan mahasiswa doktoral yang bahkan tidak bisa melakukan turunan parsial sederhana
    Semester lalu, di mata kuliah matematika level 400, ada juga mahasiswa yang tidak tahu cara menjumlahkan dua matriks
    Mahasiswa tahun keempat ilmu komputer yang tidak tahu sistem berkas memang aneh, tetapi dibanding hal-hal absurd yang saya lihat di sini, itu malah tampak sederhana
    Suasananya jauh berbeda dibanding saat saya pertama kuliah pada 2000-an, jadi terasa suram, tetapi prospek pasar kerja musim semi tahun depan justru membuat saya lebih percaya diri
  • Tergantung jurusannya. Ilmu komputer berbeda dari teknik komputer dan teknik elektro
    Terlepas dari namanya, ilmu komputer bukanlah ilmu tentang komputer itu sendiri; meski komputer adalah alat wajib, intinya adalah abstraksi domain, pemodelan bahasa, dan penerapannya
    Sama seperti astronom hanya perlu bisa memakai teleskop sejauh yang dibutuhkan, ilmuwan komputer hanya perlu bisa menggunakan komputer sejauh yang dibutuhkan
    Menempatkan komputer sebagai pusat alam semesta dan menjadikannya titik awal ilmu komputer adalah kesalahan besar, dan secara historis juga menjadi sumber banyak kebingungan
    Bahkan pemrograman “level rendah” pada akhirnya tetap merupakan abstraksi dan bahasa; hanya saja ia memakai bahasa perangkat komputasi untuk menyimulasikan abstraksi domain yang sedang dibahas
  • Saya belajar arsitektur komputer dengan MIPS pada masa MIPS masih dipakai di produk nyata, dan saat itu bagus, sekarang pun masih bagus
    Di waktu luang saya mendekompilasi assembly MIPS, dan untuk fungsi kecil saya bisa mengembalikannya dengan tangan menjadi kode C yang sesuai tanpa alat lain
  • Kegiatan mengajar berhadapan langsung dengan klaim bahwa “informasi yang diturunkan antargenerasi menjadi encer”
    Namun sebenarnya tidak menjadi encer. Karena ada kegiatan mengajar, buku, dan komputer, kita tidak perlu menyebut guru sebagai penyair keliling
    Pada akhirnya ini hanyalah tulisan blog lain tentang sebuah tulisan blog, dan entah seberapa “penting” para blogger itu, tetapi aromanya tetap seperti blog demi blog

• Ketika pengembang web tua mengkritik abstraksi, sasarannya pengembang React; ketika pengembang Python mengkritik, sasarannya pengembang web tua; dan ketika pengembang aplikasi C++ mengkritik, sasarannya pengembang Python
  Pengembang firmware menyasar pengembang aplikasi, insinyur elektro menyasar pengembang firmware
  Cukup hebat juga sikap yang menarik garis abstraksi berlebihan berdasarkan level yang ia ketahui sendiri, lalu menyebut semua yang lewat dari sana sebagai “membunuh peradaban”

  • Benar. Ini hampir sama dengan omong kosong yang kadang muncul seperti “kimia adalah fisika terapan, fisika adalah matematika terapan, jadi matematika yang paling hebat”

• Ada banyak poin bagus, dan karena saya juga menonton presentasi itu, menurut saya kritiknya penting
  Namun ucapan Blow bahwa kita “tidak bisa sekadar menggambar piksel di layar” memang benar
  Saya bekerja sebagai programmer game engine di perusahaan game menengah, dan semakin sulit merekrut orang yang bisa menangani kode grafis
  API generasi seperti DX12 menaikkan tuntutan terhadap programmer secara luar biasa dibanding generasi sebelumnya, DX11, dan melakukan sesuatu dengan API ini sendiri sudah menjadi pekerjaan besar
  Microsoft juga pernah mengakui bahwa mempelajari DX12 tanpa pengalaman API grafis sebelumnya sangatlah sulit, tetapi sekarang saya tidak bisa menemukan kutipan itu di dokumentasinya
  Bantahan bahwa “API semacam ini untuk pengembang yang ingin mendorong batas kartu grafis dan melakukan optimisasi level sangat rendah” memang ada benarnya, tetapi sekarang API ini sudah menjadi standar industri dan hampir tidak mungkin diajarkan kepada orang tanpa pengalaman sebelumnya
  Jika tidak ada yang berubah, kumpulan kandidat yang bisa direkrut akan terus menyusut

  • Setelah menonton presentasi Blow, saya merasa ternyata bukan saya yang aneh karena frustrasi melihat hal-hal mendasar menjadi tidak masuk akal sulitnya
    Saat membuat aplikasi perangkat lunak, bahkan menggambar satu tombol di layar pun menjadi terlalu sulit, sehingga kebanyakan orang akhirnya memakai progressive web app yang 100 kali lebih lambat daripada performa yang sebenarnya mungkin dicapai
    Apakah pada 2025 pilihan terbaik untuk aplikasi GUI benar-benar Java Swing dan Qt?
  • Saya setuju dengan intinya, tetapi DX12 bergerak ke arah yang berlawanan dengan abstraksi. Itu API yang jauh lebih rendah levelnya dibanding OpenGL yang sangat diabstraksikan
  • Atau mungkin “developer magang” akan kembali muncul
  • Yang paling perlu diperbaiki adalah pendidikan dan dokumentasi untuk API baru semacam ini
    Ada konsep-konsep besar yang mengikat semuanya, tetapi hampir tidak tersirat di dokumentasi, dan baru bisa dipelajari jika menghadiri sesi pelatihan atau berbicara dengan orang yang sudah mengetahuinya

• Saya rasa hal-hal seperti JavaScript sisi server dan React benar-benar membuat pengembangan perangkat lunak web jadi kacau, dibandingkan dengan apa yang sebenarnya mereka lakukan
  Di antara anak-anak sekarang, ada yang bahkan tidak tahu bahwa yang dirender di browser itu HTML. Mereka mengira React itu sendiri yang dirender oleh browser
  Ditambah lagi, CEO Vercel mengatakan hal yang benar-benar bodoh bahwa ia menganggap React sebagai kernel Linux untuk pengembangan

  • Itu klaim yang aneh, tapi ia memang benar-benar mengatakannya
    https://news.ycombinator.com/item?id=42824720
    Saya sudah cukup lama ada di bidang ini sampai ingat masa vanilla js, jQuery, Knockout, dan Angular 1, tetapi kebingungan mendasar seperti itu selalu ada bahkan saat itu
    React, dan kadang bahkan JSX saja, bisa digunakan secara masuk akal
    Saya justru menyalahkan alat-alat berbasis pendanaan ventura seperti Vercel, Next, Apollo, Prisma, serta sampah yang dijejalkan ke web oleh influencer pengembangan web yang dibayar
    Kalau dipikir-pikir, setiap bagian dari pembuatan perangkat lunak sudah membengkak, mulai dari board Notion sampai pilihan database yang meragukan
  • Saya setuju bahwa mengerikan ada banyak developer muda yang tidak bisa memprogram tanpa React
    Namun sebagai orang yang bisa bekerja dengan baik tanpa library, saya ingin menambahkan bahwa DOM adalah salah satu API terburuk yang pernah diciptakan manusia, dan “pemrograman reaktif” adalah model yang lebih unggul daripada cara lama
    NextJS membalikkan kemajuan tooling selama bertahun-tahun dan jauh lebih lambat daripada Vite
    Pada NextJS yang dibangun secara statis, halaman yang sama sekali tidak memiliki interaksi mengunduh 100KB JavaScript hanya agar tidak melakukan apa-apa
    Facebook mencoba menyelesaikan hal yang seharusnya bisa dilakukan dengan membuat komponen tidak dirender ulang tanpa perlu secara default melalui “compiler” untuk React
    Dibandingkan dengan Preact yang hampir bisa menjadi pengganti langsung, React itu sangat besar, dan itu menunjukkan betapa Facebook tidak peduli
  • Pernyataan “yang dirender browser adalah HTML” ironisnya salah, dan pihak yang mengira browser merender React justru benar
    HTML adalah format serialisasi, dan browser menggunakannya untuk membangun DOM di memori
    React tidak menserialisasi apa pun menjadi HTML, melainkan merender langsung ke DOM
    Fakta bahwa ini salah tetapi mendapat banyak upvote memperlihatkan dengan jelas bahwa thread ini bernuansa “orang tua yang mengacungkan tinju ke awan”
  • Dalam konteks memodifikasi DOM dengan JavaScript, saya tidak tahu apa maksud dari “browser merender HTML”
    Sepemahaman saya, HTML adalah input bagi browser, lalu browser mengubahnya menjadi DOM, kemudian berlanjut ke penggambaran layar, pemrosesan input, dan seterusnya
    Perbedaan ini penting, karena React atau library JavaScript berbasis virtual DOM bukan membuat HTML, melainkan membuat perintah manipulasi DOM dalam JavaScript
  • Saya kira inti React justru bahwa ia sama sekali tidak bekerja jika JavaScript tidak dinyalakan, dan Facebook membuatnya cukup berantakan sehingga bisa menyembunyikan perilaku jahatnya sendiri secara efektif di dalamnya
    Ada banyak bagian bagus dalam kritik Blow, tetapi menurut saya ia melewatkan bahwa banyak kemunduran bukan berasal dari pergeseran antargenerasi atau entropi informasi, melainkan dari niat jahat yang terang-terangan dari orang-orang yang mengambil keputusan

• Blow sering kali menunjukkan poin yang sangat bagus tentang pengembangan, tetapi juga sering benar-benar meleset
  Pencapaiannya besar dan ada ide-ide yang layak didengar, tetapi ada juga banyak omong kosong yang disajikan seolah tidak bisa dibedakan darinya
  Saya sangat merasa cerita tentang runtuhnya peradaban adalah salah satu omong kosong itu, dan meski sudah mendengarnya dua kali, saya sebagian besar mengabaikannya
  Saya berterima kasih karena tulisan aslinya memberikan sanggahan yang lebih berprinsip
  Menurut saya Casey Muratori meniru Blow, tetapi bahkan bagian bagusnya pun tidak ia lakukan dengan benar

  • Blow sudah hampir 10 tahun membuat satu gim, dan bahkan gim itu bukan sesuatu yang perlu menciptakan ulang mesin dari nol
    Muratori bahkan belum menyelesaikan gim yang ia mulai 10 tahun lalu
    Sebaliknya, dengan engine gim modern, termasuk hal seperti Raylib, kita bisa membuat hasil yang cukup lumayan bahkan dalam game jam akhir pekan, dan gim Sokoban milik Blow kira-kira bisa dibuat dalam sekitar 6 bulan, terutama dengan tim sekitar 10 orang
  • Saya penasaran bagian mana dari Casey Muratori yang secara spesifik tidak Anda setujui
    Saya sudah melihat sebagian kontennya, dan untuk topik yang ia pahami ia tampak rendah hati tetapi punya pendapat yang jelas, dan saya pikir Handmade Hero juga ia kerjakan dengan sangat baik
  • Klaim inti Muratori tampaknya adalah bahwa perangkat lunak modern itu lambat, dan saya pikir poin ini 100% benar
    Waktu yang dibutuhkan Jira untuk menampilkan satu tiket, waktu Slack untuk berpindah ruang chat, dan VSCode yang tidak bisa mengikuti kecepatan mengetik biasa itu benar-benar gila
  • Saya agak ragu apakah memang begitu
    Ia tampak hanya melempar pernyataan kritis yang luas lalu menghilang lagi untuk tidak melakukan apa-apa
    Sulit juga mengatakan ia sudah mencapai prestasi besar; menurut saya yang ia lakukan hanya cukup bagus
    Gim yang ia rilis hanya dua, dan lebih mirip puzzle daripada gim. Setelah sekali selesai, hampir tidak ada alasan untuk memainkannya lagi
    Braid lumayan, dan The Witness terasa seperti Flow saja
    Setelah itu ia sudah 10 tahun membuat bahasa pemrograman, tetapi tidak merilisnya dengan alasan “belum selesai”
    Setelah beruntung menghasilkan uang, ia tampaknya menganggap dirinya jauh lebih berbakat daripada kenyataannya

• Lingkungan perangkat lunak modern jelas punya banyak masalah, dan menurut saya abstraksi berlebihan juga merupakan masalah
  Namun ekstrem sebaliknya juga buruk, dan ada kecenderungan untuk terlalu meromantisasi masa lalu
  Crash dan reboot juga dulu menjadi masalah, sistem seperti Amiga punya masalah kompatibilitas antarversi hardware, dan bahkan sistem yang menekankan kompatibilitas pun tidak bebas dari ketidakcocokan
  Bahkan pada Windows 11, sistem modern yang paling tidak stabil, komputer saya jauh lebih stabil daripada komputer mana pun yang saya gunakan sebelum 2010, dan masih bisa menjalankan perangkat lunak untuk Windows 95
  Komputer yang bisa digunakan sehari-hari lebih baik daripada komputer yang tidak bisa

• Tidak semua penyederhanaan adalah abstraksi, dan tidak semua abstraksi juga merupakan penyederhanaan
  Namun, abstraksi sering kali tercipta saat mengejar penyederhanaan
  Saya tidak berpikir abstraksi membunuh perangkat lunak atau peradaban, tetapi abstraksi yang buruk yang dibuat dengan dalih penyederhanaan jangka pendek menurunkan fleksibilitas, kelincahan, dan aksesibilitas
  Jika melihat syntax sugar di hampir semua bahasa, pada titik tertentu penyederhanaan lokal yang didapat dari nuansa khusus ini tidak lagi cukup untuk membenarkan meningkatnya kompleksitas seluruh alat
  Dalam bahasa yang memiliki banyak sintaks, orang membuat kesalahan bukan karena satu elemen tertentu, melainkan karena tindakan memakai alat untuk menyelesaikan masalah kompleks dengan baik itu sendiri menjadi sulit
  Kompleksitas yang, menurut pengalaman saya, ditambahkan async dan coroutine di Kotlin ketika menangani kode yang “mirip thread”, sangat berbeda dari cara Elixir/Erlang menangani jenis masalah yang sama
  Keduanya menyediakan abstraksi dan penyederhanaan untuk masalah lama berupa komputasi paralel dan asinkron, tetapi yang pertama menumpuk kesederhanaan berlapis-lapis hingga kembali menciptakan sesuatu yang kompleks, sedangkan yang kedua lebih dekat dengan abstraksi yang benar-benar sederhana dan langsung bekerja

• Penulisnya tampak berasal dari generasi yang lebih muda, jadi sepertinya melewatkan poin Blow tanpa memahaminya
  Ironisnya, tulisan itu sendiri tampak seperti contoh dari apa yang dibicarakan Blow
  Ini mirip seperti mengatakan bahwa Figma sedang merusak dunia desain dalam skala yang belum pernah terjadi sebelumnya dengan menormalkan UX, UI, dan cara manajemen produk Figma sendiri yang buruk, lalu mendapat reaksi bingung dari desainer muda yang menganggap semuanya baik-baik saja
  Pengetahuan itu ada karena tumbuh di lingkungan tersebut, sementara mereka tidak, dan hal-hal yang termasuk budaya serta pengalaman juga tidak mudah dipelajari di tempat lain

  • Apakah sanggahannya pada akhirnya hanya “Anda salah karena masih muda dan kurang pengalaman”? Mungkin saja, tetapi bagian tepatnya yang salah tidak dijelaskan
    Serangan ad hominem seperti ini tidak menambahkan apa pun pada percakapan
  • Bisakah menjelaskan lebih lanjut bagaimana Figma merusak dunia desain?
  • Bagian apa yang menurut Anda dilewatkan oleh penulis?
  • Saya sama sekali tidak mendapat kesan bahwa penulisnya berasal dari generasi yang lebih muda. Isi selebihnya juga tidak benar
  • Argumen Blow sudah dibantah dengan baik, jadi tidak perlu membawa-bawa usia, tetapi penulis tampaknya setidaknya mungkin berusia sekitar pertengahan 40-an. Amiga populer pada akhir 80-an
    Berbeda dengan pernyataan bahwa “klaim bahwa perangkat lunak sedang berkembang jelas salah”, saya masih sering memakai komputer Amiga yang saya cintai
    Beberapa minggu lalu, ketika menyalin file ke hard drive Amiga, komputer tiba-tiba crash, bukan karena saya melakukan sesuatu yang salah, melainkan karena sistem operasi komputer rumahan lama memang tidak begitu stabil
    Akibatnya, partisi hard drive rusak, sistem operasi tidak bisa memverifikasi ulang file system, dan akhirnya satu-satunya pilihan adalah memformat ulang partisi itu
    Saya tidak terlalu paham desain, tetapi saya tahu klaim tentang Figma itu sepenuhnya salah, sama seperti klaim Blow
    Itu adalah nostalgia yang berbicara. Antarmuka pengguna selalu punya banyak hal yang berantakan, begitu pula perangkat lunak dan semua hal lainnya
    Yang diingat hanyalah kelebihan dari contoh-contoh terbaik masa lalu, sementara hal-hal sampah dan bahkan kegagalan dari hal-hal yang dirancang dengan baik ikut terlupakan

• Masalahnya adalah abstraksi yang tidak dipikirkan secara mendalam
  Banyak abstraksi yang jelas-jelas merupakan draf pertama atau percobaan pertama, tetapi karena pemujaan terhadap kecepatan dan arogansi di industri teknologi, abstraksi itu langsung dirilis sebelum sempat dipoles berkali-kali
  Ketika abstraksi seperti itu menjadi bagian dari proyek populer, orang lain menyalinnya karena mentalitas ikut-ikutan di bawah panji kabur “praktik terbaik”
  Ulangi proses ini selama 10–20 tahun, maka terciptalah kekacauan raksasa
  Yang lebih buruk, dalam masyarakat yang secara paradoks menjadi terlalu tersosialisasi karena teknologi, konsensus sosial untuk tidak ketahuan sebagai “penipu” terus menyebarkan solusi yang belum matang
  Saya menyukai presentasi Jonathan Blow itu dan menontonnya lagi setidaknya setahun sekali. Menurut saya, ia tidak sedang mengatakan hal kontroversial; banyak developer marah atau merasa tersindir karena di dalam hati mereka tahu bahwa mereka tidak merilis dengan upaya terbaik, dan juga tidak membimbing generasi muda dengan benar
  Kita telah sampai pada budaya di mana mengejar hal baru adalah sesuatu yang lazim, dan kadang bahkan dipuja
  Dulu, solusi yang sudah cukup ditelaah adalah standar budaya, tetapi sekarang hal yang baru menjadi standar, terlepas dari apakah itu benar-benar baik atau tidak
  Kita bisa mengulik detail argumen Blow tanpa akhir, tetapi buktinya terpampang jelas di mana-mana
  Dan pada rentang waktu yang cukup panjang, itu bisa berujung pada runtuhnya peradaban; melihat banyaknya hal yang rusak di dunia, bisa juga dikatakan bahwa itu sudah sedang terjadi

• Sangat disayangkan bahwa tesis yang cacat harus dibongkar sedetail ini
  Seorang empirisis murni sama jauhnya dari kenyataan seperti seorang teoritikus murni, dan Blow menciptakan argumen karena itu cocok dengan pengalamannya sendiri, memilih hanya contoh-contoh yang sesuai dengan keluhannya, lalu mendorong pengecualian seolah-olah itu aturan