Krisis Perangkat Lunak

 (wryl.tech)
1 poin oleh GN⁺ 2024-07-07 | 1 komentar | Bagikan ke WhatsApp
  • Istilah “software crisis” yang muncul pada NATO Software Engineering conference tahun 1968 kini lebih jarang digunakan, tetapi beban yang ditimbulkan oleh kompleksitas dan abstraksi perangkat lunak masih tetap ada
  • Dalam kuliah Turing Award tahun 1972, Edsger Dijkstra menilai bahwa kinerja dan kompleksitas hardware meningkat pesat, sementara metode organisasi untuk menanganinya tidak mampu mengimbangi
  • Komersialisasi personal computing dan siklus rilis yang cepat membuat pengguna menginginkan kapasitas yang lebih besar sebelum sempat benar-benar menguasai alatnya, dan “abstract it away” menjadi respons bawaan
  • Lapisan abstraksi yang bertumpuk menciptakan biaya performa dan model mental yang terdistorsi, serta membuat akses ke fungsi dasar mesin seperti grafis dan suara menjadi sulit
  • Solusinya bukan kembali ke platform lama yang serba terbatas, melainkan mengurangi lapisan abstraksi dan mempertahankan informasi di antara lapisan agar kendali dikembalikan kepada pengguna alat

Kesadaran masalah dari 1968 belum berakhir

  • Pada NATO Software Engineering conference pertama tahun 1968, istilah “software crisis” diciptakan
    • Konferensi-konferensi ini merupakan salah satu upaya awal untuk merapikan dan mensistematisasi praktik pemrograman mesin komputasi otomatis
    • Pada 16 Juli 1969, misi Apollo 11 diluncurkan, dan pada Oktober tahun yang sama NATO Software Engineering conference terakhir diselenggarakan
  • Dalam kuliah Turing Award tahun 1972, Edsger Dijkstra mencari penyebab krisis pada mesin yang semakin kuat dan ketiadaan metode organisasi untuk menanganinya
    • Ia meninggalkan pernyataan yang intinya: “ketika tidak ada mesin, pemrograman bukan masalah; ketika ada beberapa komputer lemah, itu masalah ringan; dan ketika komputer raksasa hadir, pemrograman pun menjadi masalah raksasa”
  • Saat ini, istilah “software crisis” tidak sering muncul dalam praktik pemrograman
    • Perkembangan bahasa baru dan metode organisasi, serta jarak waktu dari masalah masa lalu, membuat industri merasa agak lega seolah sebagian masalah telah terpecahkan
    • Namun rasa lega itu tetap lebih dekat pada kekalahan dan penerimaan daripada kenyamanan yang sebenarnya

Abstraksi menjauhkan kendali dari pengguna

  • Perkembangan komputasi awal dan bidang-bidang yang berdekatan terjadi pada mesin dan lingkungan di mana membangun menara abstraksi memiliki biaya langsung
    • Ketika keterbatasan tidak bisa dielakkan, ada siklus pertumbuhan yang diikuti oleh upgrade hardware
    • Dalam praktiknya, orang mulai menginginkan kapasitas yang lebih besar sebelum benar-benar memahami keterbatasan saat ini
  • Setelah komersialisasi personal computing, perusahaan yang menjual perangkat tidak menunggu sampai pengguna benar-benar menguasai produk, dan siklus pertumbuhan terus makin cepat
    • Bersamaan dengan siklus rilis hardware yang cepat, “abstract it away” menjadi pola pikir bawaan
    • Jika detail yang tidak disukai didorong ke dalam struktur yang dapat dikendalikan, kita memperoleh tingkat independensi tertentu, tetapi ada biaya performa yang menyertainya
  • Banyak lapisan abstraksi dan penyembunyian informasi memindahkan masalah pembangunan software ke tingkat yang lebih tinggi
    • Lapisan-lapisan ini terintegrasi ke dalam software yang diperlukan untuk menggunakan komputer dan software yang menggerakkan kehidupan
    • Industri software yang lebih luas mempercepat pengaruh siklus rilis dan modal, sementara ruang yang mudah diakses oleh developer individu semakin melemah
  • Krisis perangkat lunak bukan hanya masalah developer, tetapi juga berlanjut ke pengguna software
    • Pengguna hampir tidak memiliki kendali di luar fungsi yang diizinkan oleh pembuatnya
    • Fakta bahwa membuat dan menggunakan software sama-sama merupakan aktivitas manusia menjadi kabur

Tempat yang dituju bukan masa lalu, melainkan lapisan yang dangkal

  • Solusi yang diajukan bukan kembali ke platform yang lebih terbatas
    • Jumlah lapisan abstraksi yang diizinkan perlu dibatasi
    • Informasi di antara lapisan perlu dipertahankan
    • Model pemrograman, antarmuka pengguna, dan hardware dasar harus dangkal dan dapat dikombinasikan
    • Gerakan seperti komunitas Handmade, Permacomputing, dan retrocomputing berlanjut sebagai arus yang meningkatkan kesadaran terhadap krisis perangkat lunak

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-07
Komentar Hacker News

  • Halo, penulis di sini. Sepertinya penting untuk merapikan beberapa bagian yang sering disalahpahami dari tulisan ini. Saya bukan menentang abstraksi itu sendiri, melainkan menentang penerapannya tanpa batas.
    Ini juga bukan solusi yang mengajak kembali ke platform yang lebih membatasi, dan juga bukan argumen bahwa pengguna seharusnya “berhenti merujuk dan jadi lebih teknis”. Kunci untuk memahami krisis perangkat lunak adalah kurva “kemahiran terhadap platform” dan “siklus pertumbuhan/rilis”. Selama lebih dari 40 tahun terakhir, kecuali di beberapa bidang, kurva-kurva ini makin menjauh. Kita gagal menyelesaikannya saat keduanya masih berdekatan, tetapi waktu terbaik kedua adalah sekarang.
    Ada juga reaksi yang menyebut tulisan ini clickbait, tetapi ini adalah tulisan pertama di log saya dan berisi pemikiran saya tentang kondisi yang saya hadapi sebagai pengembang. Sentimen serupa juga tampak dalam berbagai bentuk di banyak komunitas, terutama beberapa komunitas yang berbasis kontra-budaya. Saya juga berniat menulis lanjutan yang “akan menunjukkan bagaimana melakukannya” karena saya ingin memperlihatkan sebagian dari solusinya. Ini saya kerjakan sendiri, jadi mohon waktu dan kelonggarannya.

    • Secara pribadi saya kurang paham apa sebenarnya yang ingin ditegaskan. Saya setuju bahwa ada banyak abstraksi yang buruk atau bahwa masalah bisa terlalu diabstraksikan, tetapi menurut saya itu bukan hal yang kontroversial sama sekali.
      Selama ada jutaan orang yang membuat perangkat lunak, masalah ini tidak mungkin diperbaiki sepenuhnya. Kita pasti akan berbeda pendapat dengan sebagian dari mereka, dan tidak semua orang juga bisa menjadi seahli penulis. Jadi pada akhirnya tulisan ini terbaca sebagai argumen bahwa standar untuk “abstraksi yang dapat diterima” perlu dinaikkan dibanding sekarang.
      Mudah untuk berbicara besar, tetapi saat benar-benar meneliti area tertentu yang dianggap “terlalu diabstraksikan”, kita mungkin akan jadi lebih rendah hati. Biasanya ada alasan yang cukup bagus di balik “abstraksi berlebihan” itu, dan para engineer di bidang tersebut juga merasa situasi abstraksinya berantakan, tetapi menganggapnya perlu atau tidak realistis untuk diperbaiki.
      Misalnya, banyak perangkat lunak dibuat dengan menumpuk abstraksi yang baik di atas abstraksi perantara yang digunakan luas. Kubernetes berdiri di atas Linux, container runtime, serta arsitektur tradisional control plane/configuration layer/data plane. Semua logika ini memang bisa diimplementasikan langsung ke sistem operasi baru, tetapi akan menimbulkan masalah kompatibilitas bagi pengguna. Anda mungkin bisa membuatnya, tetapi belum tentu ada pengguna, dan kalau begitu Anda akan kembali mengimplementasikan abstraksi buruk yang tadi ingin dihindari. Selain itu, solusi seperti itu jauh lebih sulit diimplementasikan. Saya juga tidak suka desain Kubernetes dan ingin masalah ini terselesaikan, tetapi hasil akhirnya sering kali adalah bahwa melakukannya dengan “cara yang benar” terlalu sulit atau mahal sampai tidak lagi sepadan.
    • Kita perlu mengingat tiga hukum Clarke.
      1. Jika seorang ilmuwan terkemuka namun sudah tua mengatakan sesuatu itu mungkin, hampir pasti dia benar; jika dia mengatakan itu mustahil, besar kemungkinan dia keliru.
      2. Satu-satunya cara menemukan batas kemungkinan adalah dengan melangkah sedikit melampaui wilayah yang tampak mustahil.
      3. Teknologi yang cukup maju tidak dapat dibedakan dari sihir.
        Bergantung pada kapan Anda masuk ke bidang ini dan latar belakang Anda, ada kemungkinan besar bahwa abstraksi generasi sebelumnya sudah terserap menjadi praktik yang diterima begitu saja. Misalnya, dulu memakai sistem operasi dengan sistem berkas serbaguna pernah menjadi asumsi yang begitu mendasar.
        Menurut saya, masalah yang dibicarakan di sini lebih dekat dengan kesulitan yang dialami saat masuk ke bidang ini sekarang. Jika diasumsikan bahwa untuk bisa berkontribusi seseorang harus memahami semua abstraksi yang digunakan secara rinci, maka pengetahuan awal yang dibutuhkan sangat besar. Itu memang bisa terasa sangat membebani, tetapi sampai bisa memahaminya lebih dalam, menerima abstraksi juga merupakan salah satu jalan.
        0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
    • Saya suka cara tulisan ini menunjukkan bahwa masalah tersebut terus berlanjut sepanjang sejarah. Istilah “krisis perangkat lunak” juga tepat karena merujuk pada titik ketika situasi ini pertama kali dirumuskan dengan jelas.
      Namun, menurut saya alasan situasi ini tidak berubah jelas bersifat ekonomi. Bukan berarti perangkat lunak yang buruk itu lebih murah. Tetapi dengan mengambil jalan pintas, individu atau organisasi bisa menghemat biaya sekarang, sementara biaya yang lebih besar nanti ditanggung oleh organisasi itu sendiri, pelanggan, dan masyarakat secara keseluruhan, sehingga ada insentif kuat untuk praktik yang murah dan buruk. Selain itu, perangkat lunak sulit dikenai standar seperti bidang rekayasa lain, jadi juga sulit membuat kontrak atau regulasi yang menuntut perangkat lunak dengan standar atau kualitas tertentu.
      Satu-satunya solusi yang bisa dibayangkan mungkin adalah revolusi teknologi yang memungkinkan pembuatan perangkat lunak yang lebih murah dan lebih baik dengan teknologi yang sama, sambil pada saat yang sama membuat perangkat lunak yang lebih murah dan lebih buruk menjadi tidak mungkin dibuat.
    • Menurut saya ini lebih mirip kelebihan perangkat lunak daripada krisis perangkat lunak.
      Ada terlalu banyak perangkat lunak di terlalu banyak platform, dan lanskapnya terlalu terfragmentasi sehingga sulit membuat generalisasi. Beberapa proyek goyah dan runtuh, sementara yang lain berjalan baik.
      Ada juga perangkat lunak yang memusuhi pengguna, tetapi itu memang disengaja dalam desainnya. Di baliknya ada sinisme dan keserakahan. Bukan karena programmer tidak tahu apa yang mereka lakukan, melainkan karena mereka mengerjakan apa yang diperintahkan.
      Pengguna sendiri juga ikut mendorong hal ini. Anda bisa membuat perangkat lunak yang baik, tetapi mereka tidak peduli; pengguna justru menuntut hal lain yang bukan perangkat lunak yang baik. Satu pengguna yang menginginkan perangkat lunak bagus menjadi korban dari lima puluh pengguna yang tidak menginginkannya. Perangkat lunak pasar massal sekarang sudah menjadi budaya massa.
    • Windows 3.1 dan Word muat dengan sangat cukup dalam hard disk 40MB. Word berjalan di RAM 2MB dan 80386 single-core 16MHz, dan mikrokontroler modern jauh melampaui itu.
      Word saat itu juga tidak terlalu kurang dibandingkan versinya sekarang. Tetapi sekarang Windows dan Office membutuhkan 50~100GB ruang disk hanya untuk bisa berjalan. Apa yang kita dapatkan sampai ukurannya menjadi 1000 kali lipat?
      Ini benar-benar gila, tetapi kita membiarkannya begitu saja. Sistem modern punya disk, RAM, dan CPU yang meningkat sekitar 5000~10000 kali, dan internet rumahan secara harfiah sejuta kali lebih cepat daripada modem awal.

  • Tulisan ini berangkat dari asumsi bahwa krisis perangkat lunak benar-benar ada atau merupakan masalah besar. Unsur krisis yang disebut antara lain pembengkakan anggaran, keterlambatan jadwal, inefisiensi, kualitas rendah, tidak terpenuhinya kebutuhan, proyek yang tidak bisa dikelola, kode yang sulit dipelihara, dan kegagalan pengiriman
    Namun jika kata “perangkat lunak” dihapus dari sini, ada berapa banyak aktivitas manusia yang tidak mengalami setidaknya satu dari masalah-masalah ini? Sebaliknya, ada juga cukup banyak perangkat lunak yang benar-benar bagus. Kita cenderung hanya melihat kegagalan dan cacat, sementara keberhasilan diabaikan seperti garis dasar yang wajar meski terus membaik
    Saat menekan tombol daya komputer hingga mencapai desktop, kita sudah melewati ratusan abstraksi. Desktop itu sendiri pun adalah salah satu benda paling kompleks yang akan kita interaksikan sepanjang hari. Hal seperti ini terjadi miliaran kali setiap hari di seluruh dunia, dan umumnya berjalan tanpa masalah. Ini pun hanya contoh yang sangat kecil

    • Tulisan itu tidak berhasil menjelaskan dengan baik apa sebenarnya krisisnya. Kompleksitas itu sendiri bukan masalah, tetapi masalah-masalah yang disebut sebelumnya memang masalah nyata
      Namun saya rasa motivasi sebenarnya dari tulisan seperti ini bukanlah daftar item tersebut, melainkan perasaan bahwa semuanya terasa di luar kendali. Programmer berpengalaman perlu menyeimbangkan rasa kewalahan itu dengan pekerjaan yang harus dilakukan. Saya butuh waktu untuk sampai pada titik ini, tetapi saya yakin ini penting. Tidak ada yang akan pernah sepenuhnya rapi, dan kita harus menerima fakta itu
    • Alasan perangkat lunak itu unik adalah karena tidak ada batasan fisik yang berfungsi sebagai paksaan atau filter alami terhadap kualitas. Jembatan pada tingkat tertentu harus memenuhi standar minimum integritas struktural dan kualitas material, kalau tidak ia akan runtuh karena beratnya sendiri. Masakan juga harus melampaui standar minimum kualitas bahan dan keterampilan memasak agar layak dimakan
      Perangkat lunak hampir tidak punya batas seperti itu selain kendala performa dan memori. Namun keduanya cukup longgar sehingga kita bisa terus menumpuk sampah dan tetap lolos. Kita semua pernah berpikir atau berkata, “Ini sebenarnya kok bisa jalan?” Sampai pengguna menyentuh kondisi batas yang salah, kita tidak tahu seberapa rapuh kode di bawahnya
      “Sudah coba dimatikan lalu dinyalakan lagi?” adalah buktinya. Sistem perangkat lunak sering masuk ke keadaan buruk yang begitu halus dan tak diketahui, sehingga satu-satunya solusi adalah menghapus semuanya dan memulai ulang dari awal. Misalnya ponsel tetap bergetar terus sampai ada panggilan atau pesan berikutnya setelah kita menerima telepon, sebagian web app tidak termuat 100% sehingga opsi menghilang, atau pairing Bluetooth yang kadang berhasil kadang tidak
    • Sebagian besar masalah yang disebutkan, mungkin bahkan semuanya, bisa ditelusuri kembali ke dua konsep dasar: komunikasi dan pemahaman
      Komunikasi adalah cara menyebarkan pemahaman dan memperbaiki kekurangannya, sedangkan pemahaman adalah dasar keberhasilan dalam hal apa pun. Tanpa pemahaman, satu atau lebih gejala di atas akan muncul. Bahkan dengan pemahaman pun itu masih bisa terjadi, tetapi setidaknya ada jalur menuju keberhasilan
      Dalam pengalaman saya, sebagian besar masalah di industri rekayasa perangkat lunak adalah masalah manusia. Bukan teknologi, bukan teknologi itu sendiri, dan bukan proses. Karena itu komunikasi dan pemahaman sangat penting bagi keberhasilan
    • Soal “berapa banyak aktivitas manusia yang mengalami satu atau lebih masalah ini”, apakah yang diinginkan adalah jawaban dikotomis bahwa di bidang tertentu hal itu sama sekali tidak pernah terjadi? Dalam kebanyakan proyek, jika 1–2 saja dari masalah itu muncul, proyek dianggap tidak berjalan baik, tetapi di perangkat lunak, kalau berhasil menghindari 2 saja dari daftar itu, sudah dinyatakan menang
    • Saya penasaran apa kriteria untuk perangkat lunak yang “cukup bagus”. Tentu ini subjektif, tetapi kebanyakan orang mungkin tidak akan melihat perangkat lunak yang benar-benar mereka gunakan lalu menyebutnya hebat
    • Benar bahwa desktop adalah mesin paling kompleks yang kita interaksikan dalam sehari, tetapi otak yang mengoperasikan komputer itu, menerima sinyal, dan bernalar adalah pengecualiannya

  • Jika melihat riwayat karier kepemimpinan di perusahaan rekayasa atau perusahaan otomotif, terlihat tahapan ketika mereka memikul tanggung jawab yang makin besar dalam perancangan suku cadang, komponen, produk, atau pengoperasian fasilitas produksi. Bahkan CEO tetap menekankan pengetahuan teknis, dan personel nonteknis pun setidaknya berpura-pura memilikinya
    Sebaliknya, dalam pengembangan perangkat lunak agile, kemampuan teknis biasanya berakhir di lapisan paling bawah. Dalam tim scrum ada orang-orang yang membuat perangkat lunak, dan hanya itu. Banyak scrum master dan analis bisnis kemungkinan besar hampir tidak pernah banyak melakukan coding, dan atasan nyata pertama dalam hierarki biasanya lebih banyak mengerjakan tugas sekretarial dan manajerial sehingga hampir tidak pernah melihat kode
    Intinya bukan cuma bahwa pengembangan perangkat lunak dilakukan dalam satuan ukuran tiket sehingga sulit merenungkan secara filosofis berapa banyak lapisan abstraksi yang kita buat dan pelihara. Pengembang perangkat lunak bahkan tidak punya tempat di meja pengambilan keputusan. Mereka diasuh scrum master, berkompromi saat code review, ditekan agar tidak memikirkan hal di luar tiket, dan biasanya juga tidak punya jalur promosi untuk membawa kemampuan teknis ke kepemimpinan
    Karena itu, gerakan untuk membunyikan alarm tentang “krisis perangkat lunak” tampaknya besar kemungkinan akan tetap berada di ranah hobi seperti Handmade, Permacomputing, komputasi retro, seperti ungkapan di akhir tulisan. Saya juga merasa Hollywood ikut bertanggung jawab karena terus-menerus menggambarkan orang software/IT secara merendahkan, sementara dokter dan pengacara tanpa henti dijadikan tokoh utama dan jargon profesional yang rumit dirangkai menjadi cerita menarik. Apakah di bidang kita ini benar-benar mustahil? Mungkin AI penulis skenario sebentar lagi akan menghasilkan sesuatu

    • Dokter dan pengacara mudah dijadikan cerita menarik karena mereka berurusan dengan manusia dan masalah sehari-hari. Tidak banyak karya yang menjadikan pengacara kontrak atau dokter radiologi sebagai tokoh utama; yang biasanya muncul adalah dokter UGD dan pengacara pidana
      Pengembangan perangkat lunak adalah pekerjaan berbicara dengan komputer secara ketat sepanjang hari. Kita menyelesaikan hal-hal biasa yang sudah pernah diselesaikan dalam aplikasi baru, atau menangani masalah yang bahkan sulit dipahami tanpa latar belakang teknis. Saya pengembang yang sudah memrogram untuk senang-senang lebih dari 20 tahun, tetapi sebagian besar pekerjaan ini membosankan sampai rasanya gila. Saya bahkan tidak mencoba menjelaskannya kepada nonpengembang. Ini sama tidak menariknya dengan akuntansi, dan banyak orang mungkin akan mendapat informasi yang lebih berguna dari cerita lain
    • Klaim ini masuk akal. Kalau saya adalah junior di era agile, mungkin saya tidak akan tumbuh secepat dan sejauh sekarang
      Perusahaan yang paling tenggelam dalam agile tempat saya pernah bekerja memperlakukan junior dan senior seperti roda gigi yang bisa saling ditukar. Bedanya hanya senior harus menyelesaikan lebih banyak poin per sprint. Ada penekanan aktif agar tidak memikirkan hal di luar cakupan tiket, dan suasananya adalah tunduk dan diam
    • Di big tech, ada cukup banyak manajer teknis sampai level yang cukup tinggi
      Namun ada dua masalah. Mereka tidak bisa masuk terlalu dalam ke detail implementasi, dan mereka juga terikat pada insentif yang menyimpang, yaitu diberi imbalan ketika menciptakan kompleksitas. Tentu ada orang yang melawan itu, tetapi orang seperti itu kecil kemungkinan dipromosikan. Tidak ada imbalan karena mengurangi jumlah bawahan atau menghilangkan peran sendiri
    • Kemalangan yang digambarkan ini terasa sebagian besar diakibatkan sendiri. Banyak pengembang “di bawah” saya sudah terpisah sepenuhnya dari kebutuhan pelanggan, sehingga hanya bisa fokus pada masalah pengembangan yang “menarik”
      Singkatnya, alasan pengembang hanya menangani kebutuhan nyata dalam satuan ukuran tiket adalah karena mereka terlalu bodoh. Mereka tidak bisa menampung gambaran besarnya di kepala dan tidak memahaminya. Terdengar menjengkelkan? Memang. Ini benar-benar sangat sulit dipahami. Maaf
    • Contoh tandingan: Boeing

  • Tulisan ini menggambarkan abstraksi sebagai kejahatan, padahal itu adalah alat yang tak terhindarkan jika kita ingin membuat perangkat lunak buatan manusia yang memiliki kemampuan di atas tingkat tertentu
    Rich Hickey pernah mengatakan kurang lebih begini: “Penjuggling pemula bisa menangani dua atau tiga bola, tetapi bahkan penjuggling terbaik di dunia mungkin batasnya sekitar sembilan. Dalam kemampuan manusia tidak ada perbedaan orde besaran, dan kita cepat mencapai plafon.” Untuk melampaui batas itu, kita tidak punya pilihan selain abstraksi
    Tentu dalam kasus tertentu bisa ada abstraksi yang buruk atau abstraksi yang terlalu banyak, dan saya rasa bagian itulah yang membuat penulis marah. Tetapi pembedaan itu penting
    Bagian yang mengatakan “sekarang membuat perangkat lunak tidak mudah, dan tidak ada apa pun yang datang bersama dokumentasi” jelas salah. Pembuatan perangkat lunak lebih mudah daripada sebelumnya, dan dokumentasinya juga lebih baik

    • Yang terutama ia usulkan dalam ceramah itu bukan abstraksi, melainkan kesederhanaan, yaitu dekomposisi
      Untuk memahami keseluruhan yang rumit, tidak selalu diperlukan indireksi. Untuk menangani kompleksitas, kita harus bisa mengurai hal-hal yang saling terikat agar tiap bagian bisa dipahami secara mandiri. Jika kompleksitas disembunyikan lewat indireksi, maka tercipta jarak antara apa yang harus kita nalar dan diri kita
      Abstraksi bagus bagi pengguna. Baik pengembang maupun bukan, mereka tidak perlu memikirkan detailnya. Tetapi abstraksi tidak membuat pekerjaan membangunnya menjadi lebih mudah

  • Berlawanan dengan pernyataan “sekarang membuat software itu tidak mudah,” jika Anda tahu alat yang tepat untuk pekerjaan yang tepat, itu sebenarnya sangat mudah. Hanya saja informasi tentang alat-alat semacam itu ditekan sehingga kita hampir tidak pernah mendengarnya
    Ekosistem alat teknis yang dibayangkan kebanyakan orang sangat berbeda dari kenyataannya. Sebagian besar alat yang kita kenal itu buruk. Alat-alat itu berusaha terlihat seperti solusi serbabisa, tetapi kenyataannya tidak terlalu bagus untuk pekerjaan apa pun. Meski begitu, justru itulah alat yang paling populer. Seperti yang disiratkan tulisan ini, saya rasa itu karena pengaruh modal
    Sebagai contoh, dengan alat yang saya pakai sekarang, saya merekam video membuat dari nol aplikasi marketplace yang agak kompleks lengkap dengan login, kontrol akses, validasi skema, dan tampilan filter yang rumit hanya lewat browser, tanpa mengunduh software apa pun, secara serverless, dalam 3 jam. Seluruh aplikasi itu kurang dari 700 baris markup HTML dan 12 baris JavaScript. Penontonnya sekitar 10 kali

    • Koreksi: itu bukan “alat yang saya pakai sekarang,” melainkan alat yang dia buat sendiri dan sekarang sedang dia promosikan dengan cara yang cukup tidak terselubung. Ada biaya langganan 18 dolar per bulan, tidak ada pengguna, dan tentu saja juga ditemani kripto yang ditopang janji dan hiperbola
      Terlepas dari sentuhan teori konspirasinya, alat modern sekarang lebih fleksibel dan lebih mudah dipakai daripada sebelumnya. Ada kekurangannya, tetapi itu bukan apa-apa dibandingkan dengan yang harus dihadapi pengembang beberapa dekade lalu. Tidak ada persekongkolan besar yang berusaha menenggelamkan alat Anda
    • Web3 atau kripto populer bukan bidang saya. Saya suka matematika, jadi saya menyukai teknik kriptografi yang tidak populer. Tapi saya tidak akan menonton video 3 jam itu sampai habis. Saya sudah merasa itu tidak akan memberi saya sesuatu yang bisa saya pakai hari ini, minggu depan, atau bulan ini. Bukan bermaksud merendahkan, hanya saja 3 jam itu lama
      Saya sangat percaya pada no-code/low-code dan alat yang bisa berjalan di mana saja. Hanya saja, bisa jadi yang saya maksud berbeda dari yang Anda bayangkan. Bagaimanapun, saya akui Anda memang berhasil membuatnya
      Pertanyaan pertama yang muncul saat saya mulai menonton videonya adalah ini: apa itu Codespaces? Bagaimana keamanannya? Aplikasi akhirnya berjalan di mana? Bisakah dijalankan di hardware saya? Bisakah dijalankan tanpa akses cloud? Cloud yang mana? Apakah itu masih akan ada minggu depan, bulan depan, tahun depan, 10 tahun lagi? Tentu saja, jangan terlalu terpaku pada satu sampel
      Situasi no-code/low-code bisa dianalogikan dengan desktop publishing. DTP tidak punya pipeline CI/CD. Anda tinggal menekan print. Itu lingkungan yang sepenuhnya terintegrasi. Sebaliknya, secara harfiah semua lingkungan “integrasi berkelanjutan” tampak seperti terlalu sibuk berteriak sampai memakan dirinya sendiri. Di suatu tempat pasti ada alat untuk separasi warna, pengaturan margin, impor font, atau pembuatan pustaka header PostScript maupun output LaTeX, tetapi kebanyakan orang tidak pernah melihat atau memakainya. Di suatu tempat juga mungkin ada orang yang melakukan pencetakan multi-plate dengan pigmen yang jauh lebih beragam daripada CMYK dan hanya tampak hidup di bawah cahaya alami, tetapi kebanyakan orang hanya melihat snapshot buruk dari ponsel mereka sehingga tidak merasa itu berarti
      Ini bukan cuma masalah para kreator. Konsumen tidak tahu apa yang mungkin dilakukan, dan mereka juga tidak punya mekanisme untuk melihat keseluruhan rentang kemungkinan itu. Perangkat konsumen secara aktif merusak rentang itu karena berbagai alasan ekosistem tertutup serta kelalaian dan ketidaktahuan biasa
      Beberapa tahun lalu saya mendapat Cadillac dari rental mobil, dan saya tidak akan pernah membeli Cadillac modern, dan kalau bisa juga akan menghindari mengendarainya. Saya tidak bisa mengendalikan wiper, dan layar konsol berkali-kali menampilkan peringatan yang paling mencolok bahwa saya tidak sedang melihat jalan. Mungkin mobil itu tidak bisa mendeteksi bahwa saya memakai kacamata. Karena saya sedang berada di lalu lintas cepat di jalan yang tidak familiar, saya memang tidak melihat layarnya, dan saya bertanya kepada penumpang saya, “sebenarnya layar yang berkedip itu bilang apa?” Bagus sekali, Cadillac
    • Tolong beri tautannya!

  • Struktur yang dangkal dan dapat dikomposisikan adalah sesuatu yang dialami semua orang saat menggunakan alat UNIX
    GUI runtuh di sini. GUI secara harfiah adalah pulau-pulau yang tidak berkomunikasi dengan cara yang bisa saling dikomposisikan
    Saya sedang bereksperimen mencampurkan GUI dan gagasan pipeline shell lewat alat bernama guish
    https://github.com/williamcotton/guish
    Saya penasaran apakah ada yang tahu alat serupa atau pendekatan GUI yang dapat dikomposisikan

    • Ini proyek-proyek di area yang mirip
      https://hisham.hm/userland/
      https://arcan-fe.com/2021/04/12/introducing-pipeworld/
      http://conal.net/papers/Eros/
    • Saya melihat jawaban untuk GUI yang dapat dikomposisikan adalah arsitektur emacs. emacs bukan murni CLI dan bukan juga murni GUI. Ini gabungan yang hebat tapi tua, dengan integrasi mulus antara keduanya
      Saya juga sedang mengerjakan ide yang berkaitan dengan ini, dan dari luar mungkin tampak mirip dengan milik Anda. Namun saya sarankan melihat bagaimana ini bekerja di emacs. Saya belum mendalaminya, tetapi pendekatan Anda tidak terlalu tampak “dapat dikomposisikan”
      Jika belum tahu, ini juga mungkin memberi inspirasi: https://gtoolkit.com/ lingkungan Smalltalk yang, seperti emacs, secara harfiah membuat segalanya bisa diprogram, tetapi arahnya hampir kebalikan. GUI bukan hasil dari perintah, melainkan bahasanya sendiri
    • Betul. Ini harus dangkal, lebar, dan dapat dikomposisikan. Abstraksi kita juga harus begitu
      Tetapi masalah yang lebih besar bukan GUI. GUI memang juga masalah, tetapi ia tak punya pilihan selain berada di puncak stack abstraksi, sehingga masalah lain terus menumpuk padanya dan tidak dapat dikomposisikan. Menariknya, ini masalah yang begitu besar sampai-sampai pada akhirnya terasa bukan masalah lagi
      Gajah besar di ruangan saat ini adalah sistem terdistribusi
    • Untuk pipeline gaya “Sunday driving”, yaitu pekerjaan yang dipakai intensif selama beberapa hari atau seminggu lalu didiamkan berbulan-bulan, saya suka KNIME(https://www.knime.com/). Untuk lapisan kodenya saya memakai Python/Pandas
    • Terlihat cukup keren. Saya setuju bahwa salah satu alasan besar saya menyukai Unix dan merasa produktif dengannya adalah karena sifatnya yang “dangkal dan dapat dikomposisikan”
      Namun GUI memang sudah lama menjadi titik lemahnya. Sepertinya karena ada banyak pertimbangan yang “global” dalam menentukan apakah sebuah UI itu baik, jadi ini bukan sifat yang modular
      Secara pribadi saya ingin ada lebih banyak UI sambil tetap mempertahankan otomatisasi. Sifat di mana apa yang Anda ketik di shell bisa disimpan ke file lalu dijalankan lagi nanti, diubah lalu dijalankan ulang, dan perintahnya disalin lalu dikirim ke teman lewat email
      Sebagai konteks, saya telah bertahun-tahun membuat shell dari nol, dan ada headless mode untuk GUI. Ada demo nyata yang dibuat orang lain, tetapi sekarang tidak ada yang sedang mengerjakannya
      Tangkapan layar:
      https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
      https://www.oilshell.org/blog/tags.html?tag=headless#headles...
      Lebih banyak tautan ada di sini - https://github.com/oilshell/oil/wiki/Interactive-Shell - juga ada proyek tidak aktif yang menarik seperti Xiki
      Jika Anda butuh shell kompatibel yang terlepas dari terminal, atau shell baru semacam itu, beri tahu saya lewat email atau https://oilshell.zulipchat.com
      Pada dasarnya saya butuh orang yang mau menguji protokol headless dan memberi tahu apa yang bisa diperbaiki. Menurut saya kita perlu membuat GUI shell yang “memiliki” terminal, tetapi bukan terminal itu sendiri. Ini tampaknya juga berkaitan dengan apa yang Anda buat
      Saat ini saya terutama mengerjakan bahasa YSH baru, tetapi saya juga ingin menghidupkan kembali pekerjaan GUI. Saya tidak punya banyak pengalaman sebagai programmer UI, jadi akan bagus mendapat sudut pandang lain
      Dan saya senang Anda memasukkan ggplot karena saya juga menyukainya. Sebenarnya ggplot justru menunjukkan titik di mana saya berharap ada grafik di shell

  • Kalimat penutup, “Bisa dibuat lebih baik. Saya akan menunjukkan caranya,” hanya terlihat seperti pembuka clickbait

    • Kriteria utama clickbait adalah apakah itu sensasional, menipu, atau sengaja mengarahkan pada salah paham. Yang ini tampaknya bukan salah satunya. Itu cuma kalimat terakhir dari sebuah tulisan blog
    • Itu adalah tulisan blog pertama dan satu-satunya di situs tersebut: https://wryl.tech/log/index.html
    • Apakah ini serangan pribadi? Atau hanya menyatakan fakta sambil tidak mempertanyakan benar-tidaknya argumen?

  • Pernyataan “sangat jarang model-model ini mencerminkan kenyataan. Jika itu terjadi, itu kebetulan yang bagus; jika tidak, itu bencana” tidak sesuai dengan pengalaman saya
    Secara umum, sebagian besar perangkat lunak yang beredar tidak bersifat fatal. Banyak web app besar yang berantakan menyedot sumber daya secara sia-sia sepanjang hari, memunculkan bug acak di sana-sini, namun tetap bisa melakukan apa yang diharapkan pengguna meski dengan buruk. Semua itu benar
    Tapi itu tidak sefatal perangkat lunak yang menangani alat pacu jantung atau roket luar angkasa. Sebagian besar perangkat lunak boleh saja berantakan. Sebab sebagian besar proyek berkaitan dengan ketidakkonsistenan manusia, dan akibat terburuk dari kurangnya kualitas biasanya hanya sedikit frustrasi, bukan malapetaka atau kematian
    Lagi pula, kebanyakan pengembang perangkat lunak juga tidak bekerja dengan motivasi uang ala Silicon Valley, dan mungkin tidak mencari nafkah dari proyek yang benar-benar ingin mereka buat karena passion. Sebagian besar perangkat lunak di pasar dibuat melalui struktur insentif eksternal yang buruk. Dari proses seperti itu, apa lagi yang kita harapkan selain sampah?

    • Saya setuju bahwa tingkat risikonya tampak tidak sepadan, tetapi saya sedang berbicara tentang semua perangkat lunak, dan juga mempertimbangkan fakta bahwa frustrasi seperti ini sangat banyak. Kalau hanya beberapa retakan kecil di tangga mungkin lain cerita, tetapi rata-ratanya seperti setengah anak tangga hilang
      Saya benar-benar benci anak tangga yang hilang
      Kita sangat jauh dari penggunaan nyata perangkat lunak yang kita buat, dan yang kita alami hanya sinyal eksekusi singkat yang memberi tahu proses pengembangan. Kecuali kita bisa bertukar tubuh dengan pengguna baru, sulit benar-benar merasakan penderitaan nyata dari “kematian karena seribu sayatan” ini
      Saya memandang pemrograman sebagai sebuah profesi, dan saya yakin kita punya kekuatan untuk mengendalikan kualitas perangkat lunak. Hanya saja ada insentif, finansial maupun nonfinansial, yang membuat kita memilih untuk berpaling

  • Saya tidak melihat adanya krisis perangkat lunak. Jutaan programmer di seluruh dunia membuat program yang cukup berguna, dan hampir semuanya—termasuk toaster—menjalankan perangkat lunak dengan cukup berhasil. Komunitas juga telah membuat program yang dapat diakses oleh semua orang, dari anak usia 5 tahun sampai kakek-nenek. Di mana krisisnya di sini?
    Tetapi memang ada krisis manajemen proyek. Ini tidak terbatas pada perangkat lunak; ini soal jauhnya pihak yang merencanakan dan pihak yang mengirimkan hasil. Dan kita tampaknya tidak mampu menjembatani kesenjangan itu. Agile, Scrum, dan sebagainya adalah penanda kesenjangan ini, tempat para “guru” memperlakukan kita semua seperti orang bodoh, dan kita sendiri juga belum berhasil menciptakan sesuatu yang lebih baik
    Komoditisasi pengembangan perangkat lunak juga ikut menyumbang kekacauan ini. Karena sifat bidang ini yang mudah dimasuki, orang di semua tingkat kemampuan dapat ikut serta dengan tingkat keberhasilan yang beragam. Ini bukan soal baik atau buruk, melainkan sifat dasarnya. Tidak jauh berbeda dari industri makanan yang punya restoran berbintang Michelin dan MacDonalds, dan keduanya sama-sama punya konsumen. Tapi kita tidak lantas menyebutnya krisis restoran

    • Contoh toaster justru merupakan contoh krisis perangkat lunak yang nyata dan spesifik. Toaster menjalankan kode yang buruk. Kode buruk yang tidak mempertimbangkan ketahanan atau keamanan itu terhubung ke internet
      Akibatnya, umur toaster menjadi lebih pendek. Dulu mungkin ada toaster yang bisa bertahan 10 tahun. Sekarang, karena perangkat lunak yang buruk dan mungkin koneksi WiFi atau Bluetooth yang dipaksakan, ketika pemasok berhenti memberi pembaruan, dua tahun kemudian benda itu menjadi sampah. Bisa juga memang tidak pernah ada pembaruan sejak awal. Krisis ini tidak selalu terlihat, hanya karena tidak kasatmata, atau karena konsumsi berlebihan saat ini dan pembelian produk baru tanpa henti
      Jika toaster berhenti bekerja setelah 2 tahun, kita mungkin menganggap itu wajar, tidak peduli atau tidak tahu kenapa. Padahal bisa saja itu pernah menjadi bagian dari botnet Mirai https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
      Mungkin tidak, karena toaster memakai chip yang lebih sederhana, tapi siapa yang tahu
    • Ungkapan “bahkan toaster menjalankan perangkat lunak” bukankah justru mendukung klaim penulis bahwa perangkat lunak terlalu banyak?
      Sebagai catatan, toaster Dualit saya tidak menjalankan perangkat lunak
    • Apakah sekarang ini benar-benar mudah dimasuki? Masuk ke pengembangan perangkat lunak modern terasa sangat sulit saat ini. Pengetahuan yang dibutuhkan terlalu banyak

  • Bagian “kita menumpuk lapisan abstraksi yang saling bertumpuk dan mengembangkan cara untuk menyembunyikan informasi di berbagai level. Masalah membangun perangkat lunak diubah menjadi lapisan-lapisan menjulang tinggi” mengingatkan saya pada abstraksi yang bocor dan Menara Babel
    https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
    https://en.wikipedia.org/wiki/Tower_of_Babel
    https://en.wikipedia.org/wiki/Hierarchy
    https://en.wikipedia.org/wiki/Abstraction
    https://en.wikipedia.org/wiki/Abstraction_(computer_science)
    Layak dibandingkan satu sama lain.