- Jauh lebih banyak sistem daripada yang dibayangkan banyak orang sebenarnya dapat berfungsi dengan baik di perangkat keras lama
- Jika optimisasi perangkat lunak yang sesungguhnya dilakukan, kemungkinan untuk mencapai efisiensi semacam ini akan jauh lebih tinggi
- Sinyal harga pasar dari sumber daya komputasi yang langka memberi insentif bagi efisiensi perangkat lunak
- Ada kebutuhan untuk mengubah produk microservices berbasis interpreter yang ada menjadi arsitektur monolitik yang dibangun dengan native code
- Di sisi lain, tanpa sumber daya komputasi yang sangat murah dan dapat diskalakan, kemungkinan pengembangan produk baru yang inovatif akan jauh lebih jarang terjadi
1 komentar
Opini Hacker News
Bisa dibilang pasar menjual software yang penuh bug dan tidak efisien hampir sama baiknya dengan software yang sempurna; yang menang adalah mana yang paling murah dibuat. Ini mirip kisah ‘pasar lemon’: pasar memperdagangkan semua barang seolah-olah berkualitas tinggi, padahal sebenarnya kualitas dikorbankan demi menekan biaya. Pembeli tidak bisa membedakan kualitas tinggi dan rendah sebelum membeli, sehingga permintaan untuk keduanya jadi tampak mirip secara artifisial. Ini terjadi karena asimetri informasi. Fenomena ini sudah nyata, dan makin terasa di AI. Pengguna tidak bisa membedakan aplikasi machine learning yang canggih dengan mesin cuci yang cuma ditempeli label ‘AI’. Label AI sendiri memberi premium harga, jadi pengguna membayar terlalu mahal untuk mesin cuci. Secara mendasar, hal yang sama terjadi saat pembeli membayar software buruk karena mengira itu ‘software yang dirancang dan ditulis oleh para ahli’. Hampir semua software ditulis di level IC1-3, dan di mayoritas perusahaan, orang QA sendirian menjadi satu-satunya indikator peningkatan kualitas. Kadang ada intern yang menghafal mantra ‘LGTM’ sambil berharap ada perbaikan, tapi kenyataannya itu pun jarang
Saya pernah mencoba membangun startup software yang membedakan diri lewat kualitas. Saya yakin kalau produknya lebih baik, orang akan menyadari dan kami akan sukses, tapi ternyata tidak begitu. Kami memang tumbuh, tetapi terlalu lambat sampai dana habis sebelum sempat untung. Pelajaran yang saya dapat: biaya rendah, dan akibatnya kualitas rendah, bisa menjadi keunggulan kompetitif di pasar yang kompetitif. Saya sudah mendengarnya sejak kuliah, tapi pengalaman ini membuat saya benar-benar merasakannya sampai ke tulang. Inilah sebabnya segala hal di pasar cenderung jadi biasa-biasa saja, dan mengapa kualitas tinggi pun memburuk saat makin populer. Semakin besar skala produk, semakin besar tekanan untuk memangkas biaya. Orang ingin membeli murah, jadi akan selalu ada yang memotong biaya (dan kualitas) untuk menawarkan harga lebih rendah. Perusahaan membayar seminimal mungkin demi bertahan hidup dan mengambil untung. Tentu sesekali ada pengecualian, tetapi arahnya tetap menuju pemotongan biaya bertahap. Mungkin ada nama untuk fenomena ini; sedikit berbeda dari pasar lemon. Pasarnya tidak runtuh, tetapi menghasilkan mediokritas yang stabil di mana-mana
Ada bantahan terhadap sudut pandang bahwa ‘pasar’ menjual semua barang sebagai barang berkualitas tinggi. Arti ‘berkualitas tinggi’ di sini penting. Kalau maksudnya performa buruk berarti kualitas rendah, maka aplikasi seperti Teams, Slack, Jira, dan lain-lain yang dinilai buruk performanya sebenarnya punya pesaing dengan performa jauh lebih baik. Tetapi kalau pengguna disuruh memilih Weechat yang berbasis terminal UI, tanpa video chat, tanpa emoji, sebagai pengganti Slack, kebanyakan justru akan menilai Weechat lebih rendah kualitasnya. Performa hanyalah salah satu fitur. Contohnya, kesuksesan awal Chrome memang karena cepat, dan developer Python juga pindah ke uv/ruff karena peningkatan performa. Namun jika Slack terbuka dalam 10ms alih-alih 5 detik, sebagian besar pengguna tetap tidak akan peduli
Saya tidak setuju bahwa software yang tidak efisien itu akibat struktur pasar lemon. Itu hanya berlaku jika ada asimetri informasi. Dalam kebanyakan kasus, orang tidak terlalu peduli pada sedikit bug dan lebih menginginkan harga yang lebih murah. Kalau software dibuat lewat QA yang sangat ketat dan prosedur pengecekan kode oleh banyak engineer, perbandingan biayanya akan sangat jelas. Saya pernah membuat software untuk toko buku kecil: saya membuatnya cepat dan tidak mematok harga tinggi. Meski tidak sempurna, setiap ada masalah saya langsung memperbaikinya, dan klien puas karena merasa mendapat transaksi yang bagus
Saya pernah memakai portal HR, penggantian biaya, pelacakan waktu, dan asuransi yang mengerikan di perusahaan besar. Saking buruknya, saya curiga orang yang membayar produk itu benar-benar pernah memakainya atau tidak. Kalau sebuah tim menyerahkan produk penuh bug dan mimpi buruk UI seperti itu ke pelanggan, mereka pantas langsung dimarahi, diturunkan jabatan, bahkan dipecat
Inti dari pasar yang mau membeli ‘software penuh bug dan tidak efisien’ adalah bahwa pasar sebenarnya membeli <i>dukungan</i>. Ini juga berlaku untuk Google atau perusahaan yang minim dukungan manusia. ‘Dukungan’ bisa muncul dalam banyak bentuk — dokumentasi, video, informasi blog, orang yang membantu, dukungan untuk lingkungan yang saya pakai (OS, browser, dan sebagainya), dukungan untuk pekerjaan yang ingin saya lakukan, dan lain-lain. Hal nomor satu yang membuat ERP terburuk sekalipun tetap hidup pada akhirnya adalah manusia sungguhan. Ada atau tidaknya dukungan menentukan garis hidup-mati sebuah produk. Kalau tim kecil ingin menang, lebih bijak mengurangi ‘kebutuhan akan dukungan’ dan menaruh dukungan di dimensi lain. Cara termudah adalah menambah manusia, lalu mengomunikasikan keunggulan dengan benar. Setiap jenis dukungan dinilai berbeda; misalnya kode open source vs kode proprietari, banyak orang akan memilih yang proprietari kalau dukungannya lebih baik daripada kodenya
Salah satu alasan besar saya suka belanja di Costco adalah karena mereka umumnya tidak menjual barang sampah. Filternya memang tidak selalu cocok dengan standar saya, tetapi tetap merupakan filter kualitas yang cukup bermakna
Bahkan jika pengguna bisa membuat keputusan berdasarkan kualitas dan performa software, kalau saya lihat daftar aplikasi yang sedang terbuka, tidak ada satu pun yang bisa diganti hanya karena ada alternatif yang lebih cepat. Misalnya Docker, iterm2, WhatsApp, dan lain-lain saya gunakan karena alasan spesifik masing-masing. Sekalipun ada solusi yang paling cepat, saya tidak bisa begitu saja pindah. Fakta bahwa software itu memenuhi kebutuhan saya sejak awal adalah faktor yang jauh lebih penting daripada sekadar performa
99% software ditulis tanpa mempertimbangkan performa. Bahkan di HN pun ada kecenderungan menganggap peningkatan performa sebagai hal yang tabu. Banyak engineer level L4/5 ke atas pun kurang punya intuisi soal performa. Dari sisi bisnis juga, efisiensi tidak diperhatikan sampai hardware benar-benar tidak mampu menjalankan software itu. Dan bahkan saat itu pun prioritas pertama biasanya menambah hardware
Struktur pasar saat ini membuat software penuh bug dan tidak efisien mendominasi, karena kapan saja kita bisa membeli hardware untuk menjalankannya. Software mengembang untuk memenuhi spesifikasi pemrosesan hardware — hukum “apa yang diberikan Andy akan diambil Bill”. Karena itu tidak ada insentif untuk membuat software yang ramping dan berkualitas tinggi. Tetapi jika datang dunia di mana chip mutakhir tak lagi bisa didapatkan (misalnya karena krisis geopolitik, hancurnya pabrik besar, dan sebagainya), maka software yang hemat sumber daya akan memiliki nilai ekonomi besar — software yang menggelembung tak akan bisa dijalankan lagi. Carmack mengatakan bahwa dalam situasi seperti itu, ruang optimisasi masih cukup lebar sehingga pada akhirnya software tetap bisa dipaksa berjalan di chip zaman lama
Software yang dirancang dengan baik itu mudah diganti. Sebaliknya, kumpulan spaghetti code penuh bug adalah sesuatu yang tak ingin disentuh siapa pun, sehingga justru bertahan selamanya. Kalau dilihat dari evolusi murni, akhirnya software buruklah yang mendominasi
Pasar mobil bekas menjadi pasar lemon karena sulit membedakan mobil yang dirawat baik dan mobil yang nyaris rusak total. Tetapi pasar mobil baru tidak demikian karena dikelola ketat. Software selalu baru. Seperti kualitas mobil yang meningkat selama puluhan tahun, kualitas software juga bisa ditingkatkan. Biarkan hanya software yang memenuhi standar tertentu yang boleh dijual; kalau ada bug serius, wajib recall; kalau sengaja menjual produk cacat, harus dihukum. Begitulah cara industri lain beroperasi
Berkat Web 2.0 ‘beta permanen’ dan model SaaS, kesabaran pengguna juga berubah. Microsoft selama beberapa generasi menanamkan persepsi bahwa ‘software memang sewajarnya rusak’. Karena semua orang terbiasa dengan software buruk, mereka jadi kurang paham nilai software yang benar-benar bagus
Saya benar-benar pernah membeli mesin cuci berlabel AI itu. Saya tertawa melihat pemasarannya, tapi tetap membelinya karena harganya masuk akal
Mungkin yang dibicarakan hanya celah keamanan. Kalau Excel atau Photoshop penuh masalah performa atau bug lain, orang akan cepat berhenti memakainya. Tetapi keamanan tidak disadari pengguna sampai masalah benar-benar terjadi, dan bahkan jika diretas pun mereka mungkin tidak tahu penyebabnya. Tidak ada insentif bagi developer. Soal performa, setelah mencapai tingkat yang cukup, orang enggan terus menuangkan sumber daya untuk optimisasi. Hukum hasil yang semakin menurun berlaku di sini
Pengguna mungkin tak bisa membedakan AI yang benar-benar canggih dengan ‘mesin cuci AI’ yang hanya tempelan, tetapi AI yang baik justru bisa membantu pengguna sendiri mengatasi asimetri informasi. Pada akhirnya ini bisa diatasi kalau ada cara untuk memilih AI yang baik
Saya tidak yakin membuat ‘software termurah’ itu otomatis benar-benar murah. Di level startup, software yang dibuat asal-asalan memang lebih murah, tetapi pada skala besar justru bisa lebih mahal. Maskapai saja mengurangi biaya sampai ke satu butir zaitun; jadi saya heran mengapa menyuruh developer mengoptimalkan software dianggap tidak efisien. Kita hanya terus menambah fitur baru, tetapi pengguna pada akhirnya merasakan software makin lambat setiap update. Sebaliknya, kalau software terasa lebih cepat, mereka bersorak. Engineer bertindak seperti MBA dan terus mengulang jawaban bahwa itu ‘tidak memberi nilai’, padahal ‘nilai’ dari perbaikan bug software sangat subjektif. Tugas engineer adalah memperbaiki bug. Brand juga penting, tetapi brand besar saat ini mengabaikan nilai brand mereka sendiri. Mungkin karena konsumen jarang pindah, namun kalau pun pindah yang didapat cuma UI baru dan hal-hal baru yang harus dipelajari lagi (bahkan Apple pun tidak lagi intuitif)
Dunia saat ini mungkin bisa berjalan di hardware lawas, tetapi CPU dan hardware toh terus menjadi lebih cepat, jadi tidak ada alasan khusus untuk membuat kode lebih efisien
Masalah asimetri informasi bisa diatasi pada produk FOSS atau produk proprietari dengan model ‘shared source’. Dengan melihat kode secara langsung, kita bisa menilai apakah kualitas keseluruhannya baik. Meski tidak menemukan bug yang nyata, dari panjang fungsi, komentar, penamaan, dan sebagainya kita bisa membaca budaya pengembangan yang jujur. Kalau saya benar-benar melihat schema db yang berantakan pada produk proprietari mahal, saya tidak akan percaya padanya
Software buruk dalam jangka panjang lebih mahal untuk dibuat (dan dirawat)
Itulah sebabnya brand berfungsi sebagai penjaga kualitas
Seperti makanan yang dilarang menjual racun, produk kedaluwarsa, atau zat adiktif lewat hukum, software juga harus diatur. Tetapi sebelum GDPR, regulasi nyaris tidak berarti apa-apa, dan sekarang pun pelanggaran masih menjadi hal sehari-hari
Daya komputasi telah meningkat sekitar 1000 kali sejak 1980. Jika penalti performa dari dynamic array bounds checking kita anggap 5% (padahal sebenarnya jauh lebih kecil), maka meski check itu diaktifkan kita tetap bisa memakai komputer yang 950 kali lebih cepat. Jika kita kembali ke 1980 dan diminta memilih antara ‘komputer yang 950 kali lebih cepat, dengan bug lebih sedikit dan debugging lebih mudah’ dan ‘komputer yang 1000 kali lebih cepat tetapi tetap penuh bug dan lebih sulit di-debug’, kebanyakan orang akan memilih yang 950 kali. Namun pada akhirnya kita memilih yang 1000 kali. Secara pribadi saya merasa kaum 1000Xers yang merusak keadaan
Tetapi performa 1000 kali itu terbuang bukan untuk bounds checking, melainkan untuk abstraksi tanpa akhir dan inefisiensi
Saya pernah memaksa vendor menjalankan software yang lambat dan penuh bug di Sparc 20. Hasilnya mereka mengoptimalkan software tersebut, dan itu menjadi dasar keberhasilan perusahaan di pasar. Optimisasi adalah keunggulan kompetitif
Itu mungkin benar jika bicara sejak 1980. Namun ringkasan dari video terbaru mengatakan, “komputer saat ini tidak jauh lebih cepat dibanding komputer 20 tahun lalu, dan peningkatan itu baru terasa kalau ada optimisasi khusus.” Penulis videonya memang mengabaikan hal seperti optimisasi compiler, tetapi katanya peningkatan performa nyata ternyata jauh lebih kecil dari dugaan, bahkan hanya sekitar dua kali lipat dalam 15 tahun
Tadi disebut bounds checking array hanya memakan 5%, padahal tidak semua algoritme sesederhana itu. Tergantung jumlah operasi, menambahkan check saja bisa menaikkan biaya 3–4 kali lipat. Di kasus tertentu, kalau check dipaksakan, bahasanya sendiri akan kehilangan daya saing. Dalam kebanyakan kasus memang tidak masalah, tetapi saya rasa lebih baik dibagi menjadi mode aman dan mode umum
Jika hanya memikirkan bounds checking, biayanya memang relatif rendah, tetapi overhead dari bahasa yang aman itu sendiri jauh lebih besar. Bahasa dengan GC bahkan bisa melipatgandakan penggunaan memori beberapa kali
Kita juga tak boleh lupa hukum bilangan besar. Penurunan performa 5% pada satu sistem mungkin bukan masalah besar, tetapi bila kerugian 5% itu terakumulasi di seluruh lingkungan komputasi dunia, dampaknya sangat besar
Saya setuju manusia memang cenderung mengejar keuntungan jangka pendek, tetapi dynamic bounds checking sendiri tidak menyelesaikan isu keamanan. Solusi akhirnya pun sampai sekarang belum ada
Akar utama dari kondisi kita saat ini adalah karena kita terikat pada browser
Balasan pertama pada dasarnya benar. Fakta bahwa C masih dipakai secara luas saja sudah menunjukkan masalah intinya adalah struktur yang tidak efisien di lapisan bawah stack
Dasar angka ‘5%’ itu terasa kabur. Saya tidak yakin biaya itu dihitung berdasarkan apa. Kalau setiap memasukkan satu nilai ke array harus selalu dicek, saya malah penasaran apakah biayanya bisa lebih dari dua kali lipat
Saat ini sebagian besar bahasa pemrograman memang sudah mendukung array bounds checking secara default
Ini mengingatkan saya pada masa awal Node.js. Saat itu keuntungan besarnya adalah menjembatani coding klien dan server, tetapi sekarang ia menjadi mimpi buruk keamanan; jadi bahasa minimalis dengan codebase kecil juga punya kelebihan
Andai saja kita lebih cepat menyadari bahwa satu string bisa memuat data berukuran gigabyte, mungkin null-terminated string sudah lama hilang dan semua orang tidak perlu begitu menderita
Sebenarnya orang yang menikmati produk 1000 kali lebih cepat, para 1000Xers itu, justru sangat sedikit. Software desktop yang dialami pengguna biasa tetap lambat
Kenyataannya peningkatannya mungkin mendekati 100.000 kali: clock saja 1000 kali, core 10 kali, instruksi sendiri 10 kali lewat AVX dan sejenisnya, secara arsitektural bahkan 1–2 juta kali lebih cepat. Tetapi tetap saja tidak berdampak pada kecepatan yang dirasakan
Mengutip ucapan Robert Barton yang menyebut orang-orang seperti itu sebagai ‘pendeta tinggi dari kultus yang rendah’
Sejak 1980 memang cepat, tetapi kalau dilihat sejak 2005, peningkatannya hanya sekitar 5 kali lipat
Clock 2000 kali, IPC lewat SIMD dan lain-lain sampai 80 kali, ditambah core, akhirnya 1–2 juta kali lebih cepat. Tetapi kebanyakan program ditulis oleh orang yang berpikir, ‘asal jalan, ya segitulah cepatnya’. Yang benar-benar memikirkan optimisasi jumlahnya sangat sedikit, bahkan di antara pengguna HN juga begitu
Seharusnya sejak 2001 CPU 1GHz dijadikan patokan target eksekusi software dasar. Pengalaman saya dengan AI juga sangat mengecewakan. Saya berharap LLM bisa melakukan hal-hal seperti konversi bahasa dan optimisasi kode dengan memadai, tetapi kenyataannya tidak begitu. Saya bahkan pernah menyuruh AI mem-port kode Unix sed ke bahasa di JVM, dan di luar hal-hal dasar ia benar-benar gagal untuk level menengah ke atas. Pada akhirnya semua arus ini bertujuan ‘mengurangi pekerjaan’, bukan meningkatkan kualitas software. AI ke depan justru akan menghasilkan lebih banyak software buruk
Inilah JavaScript, dan masa depan pengguna
Saat bekerja di Google (dan Facebook), saya menyadari betapa murahnya harga hardware dan betapa optimisasi kode kebanyakan tidak bernilai. Lebih dari 10 tahun lalu, Google mewajibkan manajemen sumber daya datacenter dan setiap proyek punya anggaran. Sumber daya seperti CPU, HDD, flash, dan lain-lain saling dipertukarkan untuk menghitung biaya relatif. Meski flash 20 kali lebih mahal daripada hard disk, dengan mempertimbangkan bottleneck yang sebenarnya, kadang flash justru lebih murah. Sumber daya itu lalu dikonversi ke waktu software engineer (1 SWE = 1 orang-tahun), dan kalau optimisasi tidak bisa menghemat lebih dari 5000 core CPU, hasilnya malah rugi. Optimisasi hanya berarti untuk proyek besar; selebihnya tidak ada gunanya karena kodenya toh segera diganti. Dari sisi kegunaan Web juga, antarmuka mouse sangat tidak efisien, sedangkan terminal berbasis teks 30–40 tahun lalu jauh lebih efisien. Saya berharap ‘Web akan distandardisasi lalu bergerak ke tahap berikutnya’, tetapi itu tidak terjadi. Sampai sekarang masih ada framework baru tiap minggu, dan bahkan scrollbar yang sama pun terus diimplementasikan ulang sampai tidak kompatibel dengan hardware. Saya tidak tahu solusinya
Menurut saya penilaian itu hanya berlaku di perusahaan dengan biaya engineering tinggi, margin besar, dan banyak proyek. Kalau memang ada sedikit saja uang tersisa, lebih baik benar-benar mengalokasikan engineer ke optimisasi. Nyatanya banyak perusahaan hanya meniru Google, jadi mereka mengambil keputusan yang tak ada hubungannya dengan logika ekonomi, dan itu menjelaskan banyak masalah ini
Saya juga mantan Google. Google memang sering bicara soal optimisasi penggunaan per CPU, tetapi sebenarnya ada dua hal yang sangat ditekankan: latency dan utilisasi server secara keseluruhan. Keduanya KPI penting di organisasi tingkat atas, jadi sumber daya engineering yang sangat besar dialokasikan ke sana. Semakin banyak jumlah mesin, semakin tak ingin dibiarkan menganggur, dan bisnis yang sensitif terhadap latency akan berusaha keras mengurangi bahkan hanya beberapa ms
Logika ala Google ini berlaku karena mereka perusahaan yang biaya per core-nya besar. Untuk kebanyakan perusahaan biasa, sama sekali tidak relevan. Pendekatan itu hanya berlaku pada skala Facebook/Google/Netflix dan sejenisnya
Google merancang kompresi yang lebih baik dan format serialisasi biner yang lebih baik juga demi meningkatkan profitabilitas mereka sendiri
Saat melihat judul artikelnya, saya kira Carmack sedang mengkritik optimisasi software pada hardware berperforma rendah. Ternyata bukan begitu; ia sedang membahas eksperimen pikiran tentang dunia di mana kemajuan hardware berhenti, dan dalam kesimpulannya ia menyatakan bahwa “tanpa komputasi yang murah dan mudah diskalakan, produk inovatif akan berkurang”
Ini terkait dengan thread yang muncul kemarin
Soal kesimpulan “tanpa komputasi murah dan skalabel inovasi berkurang”, faktanya setelah smartphone kita memang nyaris tidak punya inovasi lagi, dan karena modal begitu bergantung pada perkembangan hardware, produk baru pun pada dasarnya tidak lagi berbeda secara esensial dari yang lama
Secara pribadi saya tidak setuju dengan klaim itu. Sekalipun pengembangan fitur berhenti sebentar, setelah persiapan yang cukup inovasi akan kembali. Mungkin ada penurunan, tetapi tidak akan berlangsung terus-menerus
Intinya adalah bahwa “bloat” bukan sekadar pemborosan, melainkan peningkatan produktivitas pengembangan yang lahir dari insentif ekonomi. Meningkatkan produktivitas dengan bahasa yang kurang kompleks bisa berdampak pada perekrutan lebih banyak orang dan pengurangan biaya
Jika umur hardware bisa diperpanjang 5 atau 10 tahun lebih lama daripada planned obsolescence, kita bisa mengurangi sangat banyak limbah elektronik, penggunaan mineral langka, dan emisi gas rumah kaca. Tetapi pasar software tidak menanggung biaya eksternal seperti itu. Setelah rilis, menguji, memperbaiki, dan mengulang jauh lebih murah daripada desain jangka panjang. Sebagian industri game memang menemukan rumus performa tinggi + pendapatan, tetapi itu tidak tersebar luas. Software enterprise dan konsumen lebih fokus pada syarat minimum selama pengguna masih ‘tahan’, bukan performa. Karena fitur baru dan perubahan terus-menerus ditambahkan, sulit benar-benar memikirkan performa, dan anggaran sejak awal sudah menyisihkan cadangan untuk tingkat error. Berbeda dari cara rilis yang relatif ‘siap’, risiko kompleksitas dan perubahan jauh lebih besar
Selama lebih dari 10 tahun terakhir, kami menjalankan seluruh matching engine bursa pada satu thread. Untuk bagian pemrosesan transaksi yang terserialisasi, daya komputasi memang tidak tumbuh secepat itu. Kalau belum mencapai jutaan TPS, bahkan tidak perlu diskalakan ke cluster. Justru desain bisa disederhanakan dan semuanya ditangani di satu mesin
Ini yang benar-benar membuat frustrasi. Banyak arsitek sistem membuat sistem jadi rumit hanya untuk meninggalkan jejak keberadaan mereka sendiri, dan akibatnya malah memproduksi isu-isu baru. Padahal dengan desain semula pun sebagian besar kebutuhan sudah terpenuhi, dan dengan daya komputasi lokal standar sekarang, pemrosesan di satu mesin pun baik-baik saja
Saya penasaran mengapa order matching tidak bisa diparalelkan — apakah dengan menerapkan pemadatan log yang mirip sort itu tidak bisa dibuat paralel, atau memang karena di proses matching hampir tidak ada perhitungan lain selain penyortiran sederhana?
Kalau hanya pemrosesan sederhana, satu thread memang cukup. Tetapi jika setiap transaksi butuh operasi yang kompleks, itu tidak mungkin. Masalahnya saya kurang paham domain ini, jadi sulit membayangkan pemrosesan seperti apa yang dianggap cukup kompleks
Jika tool pengembangan terus berkembang, dulu di era RAD kita bisa dengan mudah membuat GUI native sepenuhnya, tetapi sekarang yang dominan justru Electron. Akibatnya, beberapa web browser berbeda terpasang sebagai turunan Chromium masing-masing
Pada akhirnya ini soal ekonomi alokasi sumber daya. Apakah waktu developer dipakai untuk optimisasi software, atau untuk membuat fitur baru? Jika yang kedua menghasilkan pendapatan lebih besar, itulah yang akan dipilih. Sebaliknya, jika optimisasi lebih penting, perusahaan akan bertindak sesuai itu
Saya setuju ini soal ekonomi, tetapi intinya bagi saya adalah perusahaan software melempar externality negatif ke seluruh masyarakat. Mereka tidak peduli pada konsumsi energi tambahan, pemborosan, peningkatan limbah elektronik, dan sebagainya
Ini struktur yang melempar utang teknis/finansial ke orang lain sambil hanya menambah sampah dalam jumlah besar. Memang sering kali optimisasi tidak memberi manfaat nyata, tetapi kebiasaan sekadar menambah server tetap disayangkan
Klaim bahwa ‘menambah fitur lebih penting’ itu tergantung kasus. Saya sendiri hampir tidak memakai sebagian besar fitur baru di macOS, Windows, atau Android terbaru; yang lebih penting buat saya adalah lingkungan yang efisien dan keamanan. Untuk software desain pun saya lebih berharap perbaikan efisiensi daripada fitur baru. Kadang saya malah menginginkan Illustrator/Photoshop 10 tahun lalu. Di software produksi musik, fitur baru memang kadang dibutuhkan untuk memperbaiki alur kerja, tetapi kalau itu mengorbankan efisiensi saya justru menolaknya. Untuk code editor, VSCode saja sudah cukup, saya hanya berharap ia bisa lebih cepat dan ringan
Dalam hidup saya, efisiensi sangat penting. Misalnya saat pergi ke dapur mengambil sesuatu, saya selalu sekalian membawa sampah atau piring agar tidak perlu dua kali jalan. Software pun mirip begitu. Tetapi antara ‘menghabiskan waktu engineer mahal untuk optimisasi’ dan ‘menambah RAM/sumber daya’, yang kedua hampir selalu lebih murah. Hanya ketika masalahnya cukup besar optimisasi mulai menguntungkan. Pasar yang pada akhirnya menentukan pilihan mana yang lebih bermanfaat. Jika keuntungan dari menambah hardware menurun, orang akan beralih ke optimisasi. Hukum Moore belum benar-benar mentok, jadi untuk saat ini belum sampai ke sana
Pada akhirnya ini soal permintaan. Kalau konsumen benar-benar menganggap software yang lebih cepat itu penting, mereka akan bersedia membayar lebih. Namun kenyataannya, sekalipun performanya lebih buruk, jika harganya lebih murah justru itulah yang mereka pilih
Inilah definisi ‘enshitification’
Banyak orang mengeluhkan performa aplikasi Electron, tetapi bagi laptop Linux itu justru inovasi kunci yang membuat lingkungan kerja tetap bisa dijalani. Misalnya, ikut meeting Teams jadi mudah tanpa perlu instalasi. Walaupun semua orang merindukan optimisasi kode ala Winamp, pada praktiknya aksesibilitas aplikasi Electron memang nyaman
Saat baru-baru ini memainkan game Balatro, saya sadar bahwa ini game yang bahkan sekarang pun hanya memproses operasi sederhana dan grafis ringan, tetapi spesifikasi minimum yang dimintanya terus meningkat, padahal rasanya game seperti itu mestinya bisa berjalan di hardware 90-an (Pentium II + 3dfx). Saya heran kenapa kebutuhan speknya berlebihan sampai terasa baru pantas di laptop modern