- Berkat agen AI, kini aplikasi native personal bisa dibuat dalam hitungan jam, sehingga perangkat lunak bergerak ke ranah kustomisasi ala Emacs
- MDV.app adalah penampil Markdown untuk macOS, dan fitur pencarian, indeks SQLite FTS, bookmark, daftar isi, serta pengingat posisi berhasil diimplementasikan hanya dalam beberapa jam
- Masalah aplikasi Electron yang masing-masing membawa salinan Chromium sendiri dan tingkat kesulitan pengembangan UI native memang besar, tetapi Claude sangat mahir menangani SwiftUI
- Seperti budaya Emacs, semakin banyak alat yang sangat spesifik untuk mengatasi ketidaknyamanan masing-masing orang, dan nilai ide, observasi, serta prompt menjadi lebih besar daripada produk jadi
- Coding dengan agen memudahkan penambahan UI yang enak dipakai pada proyek sampingan dan alat terminal, serta mengubah pembuatan UI native menjadi sesuatu yang menyenangkan
Alasan membuat penampil Markdown sendiri
- Dalam pengembangan perangkat lunak, Markdown sudah lama dipakai seperti bahasa bersama bahkan sebelum era LLM, dan setelah munculnya agen, alat TUI kembali bertambah sehingga pengalaman terus menggulir Markdown di terminal jadi makin sulit ditoleransi
- Untuk penampil Markdown TUI, ada glow dari Charm dan Markless buatan Josh; Markless juga mendukung penelusuran daftar isi, tetapi terminal umumnya memakai font lebar tetap sehingga melelahkan untuk dibaca dalam waktu lama
- Di macOS ada editor Markdown GUI seperti Obsidian, Typora, dan Bear yang nyaman dibaca, tetapi semuanya adalah editor, sehingga saat file
.md dibuka, lingkungan penyuntingan dan susunan jendela yang sudah ada langsung terganggu
- Penampil Markdown di App Store awalnya terlihat meyakinkan, tetapi saat benar-benar dipakai muncul masalah seperti tidak ada pencarian, ada pembelian dalam aplikasi, atau teks yang dipilih tidak bisa disalin ke clipboard
- Pada 2026, alih-alih terus mencari penampil yang cukup bagus, arahnya berubah ke keputusan bahwa penampil Markdown yang diinginkan bisa dibuat dengan agen AI
MDV.app yang dibuat dengan Claude
- MDV.app dibuat hanya dalam beberapa jam hingga mencapai tingkat yang lebih baik daripada penampil Markdown khusus yang ditemukan di App Store, dan waktu interaksi langsung yang dibutuhkan hanya sekitar 30 menit
- Persiapan seperti menyiapkan Xcode dan git di MacBook lama, mengatur lingkungan Claude, serta mencari bantuan terkait Swift dan desain macOS sudah dilakukan sejak beberapa minggu sebelumnya
- MDV bukan aplikasi macOS terbaik atau perangkat lunak yang luar biasa cakap, tetapi sebagai penampil Markdown khusus untuk macOS, hasilnya sudah cukup baik dan sangat meningkatkan kualitas hidup
- Fitur utama MDV mencakup pemilihan dan penyalinan teks dari dokumen, pencarian string tetap, pengindeksan SQLite FTS untuk semua file Markdown dalam riwayat yang bisa diedit, bookmark dengan pintasan, serta penelusuran daftar isi
- Saat berpindah antar dokumen, posisinya diingat dan tetap berlanjut setelah dijalankan ulang; juga tersedia tema warna dan tipografi yang nyaman dibaca, sehingga saat mengklik file
.md, lingkungan baca yang diinginkan langsung terbuka
Keterbatasan Electron dan perubahan pada UI native
- Setiap kali pesan Signal datang, layar berkedip dan tidak berhenti sampai aplikasi Signal disembunyikan secara eksplisit, sehingga kedipan halus itu terus berlanjut sampai hampir memicu migrain
- Fenomena ini terjadi karena Signal adalah aplikasi Electron; dari luar tampak seperti aplikasi macOS native, tetapi sebenarnya berupa salinan Chromium yang merender halaman web rahasia
- Hampir semua aplikasi UI yang muncul selama 10 tahun terakhir tampak seperti masing-masing membawa salinan Chromium sendiri, dan meskipun Electron tidak ideal, selama ini ia bertahan sebagai pilihan yang cukup memadai
- Membuat UI native sungguhan secara historis adalah pekerjaan yang sulit, bahkan sulit menemukan tenaga dengan kemampuan rata-rata untuk menanganinya, dan pengembang UI native macOS yang benar-benar cakap memang langka
- Claude bukan sekadar pengganti pengembang SwiftUI tingkat rata-rata, tetapi benar-benar bisa dianggap sebagai pengembang yang mahir menggunakan SwiftUI
Cara budaya Emacs merembes ke seluruh perangkat lunak
- MDV lebih tepat dipandang bukan sebagai produk jadi yang direkomendasikan untuk dipasang dan dipakai, melainkan sebagai sesuatu yang bisa dicuri idenya untuk membuat versi yang lebih baik, seperti saat pengguna Emacs melihat konfigurasi
.emacs yang mengilap
- Dalam budaya Emacs, pengguna jangka panjang membuat aplikasi dengan elisp untuk menyelesaikan ketidaknyamanan pribadi yang bermula dari penyuntingan teks, dan alat-alat itu meluas melampaui batas wajar dari apa yang seharusnya dilakukan editor teks
- /r/emacs lebih dekat ke budaya pamer hasil daripada promosi produk ala Product Hunt; memang ada paket elisp yang dipakai luas, tetapi selain Magit, kecenderungannya adalah masing-masing orang membuat ulang dengan versi yang menurut mereka lebih keren
- Kelemahan budaya Emacs adalah, selain Magit, paket-paketnya umumnya jelek, lambat, dan memiliki pengalaman pengguna yang buruk yang baru terasa setelah lama berkutat dengan elisp
- Agen AI mendorong budaya ini keluar dari Emacs; selama ia bisa mengakses layar dan input, UI native kini bisa dibuat secara andal, sehingga UI native berpindah dari ranah program yang dikemas secara profesional ke ranah kustomisasi personal
Kemungkinan alat native personal
- Perangkat lunak yang ter-Emacsifikasi kebanyakan adalah perangkat lunak personal yang hanya berguna bagi pembuatnya sendiri, dan seperti program elisp tua yang tertinggal di dalam
.emacs, akan ada makin banyak alat yang terlupakan
- Kadang-kadang program seperti ini bisa melampaui batas dan menjadi cukup berguna hingga dipasang oleh banyak orang, tetapi bahkan saat itu pun yang paling penting belum tentu artefak distribusi atau kode sumbernya
- Jika agen telah menulis seluruh kode SwiftUI, maka dibanding membaca kode sumber secara rinci, ide dan observasi bahwa “hal seperti ini bisa dibuat dan berjalan dengan baik” menjadi lebih penting
- Dalam jenis perangkat lunak seperti ini, prompt bisa lebih bernilai daripada kode sumber; bagi orang yang terbiasa membuat perangkat lunak dengan langsung menjalankannya, semuanya menjadi dapat diprogram bukan hanya secara teknis tetapi juga secara praktis
- Upaya yang dikeluarkan terasa terlalu kecil untuk menyebut perangkat lunak buatan agen ini sebagai sesuatu yang “dibangun”; sensasi nyatanya lebih dekat ke mengonfigurasi di atas platform yang tiba-tiba menjadi jauh lebih mudah disetel
- Para pengembang yang memakai AI akhirnya menyelesaikan proyek sampingan acak yang sudah menumpuk selama bertahun-tahun
- Kini alat yang sangat spesifik itu tidak hanya bisa selesai dibuat, tetapi juga bisa memiliki UI yang enak dipakai, dan ini melemahkan sebagian alasan lama untuk menerima UI Emacs yang canggung apa adanya
- Peluang untuk meningkatkan aplikasi terminal menjadi jauh lebih besar, dan alat seperti
iostat, iostat lintas banyak host, atau bpftrace juga bisa dibuat dalam bentuk yang lebih mudah dipahami
- Kerumitan yang dulu harus diterima Brendan Gregg untuk visualisasi terminal
bpftrace kini tidak perlu ditoleransi begitu saja, dan bahkan sudah ada contoh buatan langsung
- Sebagai peneliti kerentanan, perkembangan exploit development berbasis agent coding pada paruh pertama 2026 memang menarik, tetapi bagi kebanyakan orang perubahan itu juga menakutkan; sebaliknya, perubahan bahwa membuat UI native kini menjadi menyenangkan terasa sebagai kabar yang murni baik
- Disarankan untuk membuat alat yang terlalu spesifik sesuai masalah sendiri, menikmatinya sebentar, lalu membagikannya, atau lebih baik lagi membagikan tangkapan layar beserta prompt yang dipakai
1 komentar
Komentar Hacker News
Menurut saya, sekarang para nerd boleh mengambil kembali ranah-ranah yang kebanyakan sudah menjadi perangkat lunak khusus yang dipaketkan sebelumnya: aplikasi podcast, aplikasi pemutar musik, pembaca feed, klien Bluesky, aplikasi catatan, aplikasi bookmark desktop/baca nanti, chat dan messenger, pelacak waktu, pengelola resep, dan semacamnya
Dengan Claude, hasil yang didapat bisa cukup lebih baik daripada alternatif yang ada. Mungkin bukan aplikasi terbaik atau yang kompetitif secara global, tetapi bisa jadi aplikasi yang jauh lebih cocok dengan cara kerja unik kita sendiri
Music.app menyiksa untuk dipakai, tetapi Apple sudah lama memisahkan fungsi intinya ke MusicKit. Sekarang produk yang sebenarnya adalah MusicKit, jadi saya tidak tahu kenapa kita masih memakai Music.app, dan ini adalah perubahan baru
Eksperimen ke arah itu adalah https://github.com/dharmatech/9social
Klien pertamanya ditulis untuk plan9, dan memang harus begitu agar desainnya tetap jujur. Jika bisa berjalan di plan9/rc/acme, berarti masuk akal
Demo videonya ada di https://youtu.be/q6qVnlCjcAI, dan implementasinya saat ini kurang dari 3000 baris kode
Bicara soal Emacs, 9social banyak terinspirasi oleh proyek Emacs bernama Org Social: https://github.com/tanrax/org-social
Ini antarmuka berbasis spreadsheet yang belum selesai untuk memasukkan waktu. Dibuat untuk konsultasi, tetapi belum sampai ke penyimpanan data. Ada algoritme kecil yang lucu yang bisa menangani hampir semua cara alami orang memasukkan waktu, dan saya membuatnya karena tidak suka pelacak waktu yang memaksa input terstruktur: https://stackoverflow.com/a/49185071/59087
Pengelola resep: https://repo.autonoma.ca/repo/recipe-fiddle
Di era LLM, mengklasifikasikan bahan dan memformatnya ke TeX untuk penerbitan PDF akan jauh lebih mudah. Ide proyek ini adalah membuat resep web atau hasil scan tulisan tangan hampir cukup di-copy/paste lalu diformat otomatis
Tidak ada aplikasi di F-Droid yang memenuhi semua syarat itu, jadi saya langsung membuat APK sendiri
Berkat era LLM, produksi perangkat lunak jadi terlalu mudah, sehingga semuanya terasa seperti file .emacs. Artinya, tiap orang punya kepompong perangkat lunak yang sepenuhnya personal dan bisa dikustomisasi tanpa batas
Seperti kata OP, sekarang lebih mudah membuat solusi sendiri daripada memasang atau mempelajari yang sudah ada
Lisp juga analogi yang bagus. Kritik lama terhadap macro Lisp adalah semua programmer akan mengubahnya menjadi bahasa privat mereka sendiri sampai tak bisa dibaca orang lain
Saya juga teringat tulisan Mark Tarver tahun 2007, "The Bipolar Lisp Programmer": https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Ia berbicara tentang "brilliant bipolar mind", yang sekarang menariknya terasa nyambung dengan AI psychosis yang sering muncul, baik secara ironis maupun serius
Dalam tulisan Tarver https://www.marktarver.com/bipolar.html, disebutkan bahwa "throw-away design" di komunitas Lisp sangat cocok dengan BBM. Lisp membuat sesuatu terlalu mudah untuk dilempar jadi, sehingga tiap orang membuat solusi sendiri dan merasa cukup selama solusi itu kembali berguna untuk dirinya
Sebaliknya, di C/C++ membuat sesuatu yang berarti itu begitu sulit sehingga menjadi pencapaian, dan muncul dorongan untuk mendokumentasikan serta berkolaborasi. Dari sudut pandang pemberi kerja, 10 orang yang bisa berkomunikasi, mendokumentasikan, dan bekerja bersama lebih menarik daripada 1 hacker Lisp yang sulit digantikan
Saat produksi jadi mudah, konsumsi menjadi bottleneck, dan berbagi jadi sulit. File .emacs bersifat personal seperti sidik jari, jadi kita mungkin mengambil potongannya, tetapi tidak ingin memakai milik orang lain secara utuh
Semakin dikustomisasi kepompong ini, semakin sulit pula bagi orang lain untuk memahami atau ingin memakainya. Biaya kognitifnya besar, tetapi juga terasa tidak nyaman seperti mengenakan pakaian orang lain. Mungkin ini lebih tepat disebut AI solipsisme daripada AI psychosis
Dalam perangkat lunak, manajemen konfigurasi sedang menjadi bagian yang sulit. Bagaimana cara berbagi sumber dan mengelola versinya? Apa itu sumber? Prompt-kah? OP di akhir juga condong ke arah berbagi screenshot dan prompt daripada kode
Di Show HN juga sempat ada balon uji bahwa karena kode yang dihasilkan bukan lagi sumber, sebaiknya prompt yang dibagikan, tetapi itu mendapat banyak penolakan dari orang yang paham: https://news.ycombinator.com/item?id=47213630
Tekanan yang diterima GitHub pun tak terhindarkan datang dari arus semacam ini. Seperti apa penerusnya belum jelas, tetapi pada akhirnya akan dibutuhkan. Saat ini masih terlihat seperti tahap kereta tanpa kuda
Yang lebih penting adalah kerja tim. Jika semua orang menjadi BBM, atau masing-masing dari kita punya pasukan BBM gila yang menghasilkan sesuatu 24 jam hanya untuk kita sendiri, bagaimana kita bekerja bersama? Bagaimana kepompong-kepompong itu berkomunikasi dan saling interoperabel? Tim para solipsis AI terdengar seperti kontradiksi
Tim dan startup yang berada di garis depan pengembangan berbasis AI dan agen pasti sedang benar-benar mengalami masalah ini sekarang. Misalnya, bagaimana menggabungkan kode hasil generasi saya dengan kode hasil generasi Anda. Ada kemungkinan besar sebagian keuntungan produktivitas dari kode generatif akan kembali hilang karena gesekan semacam ini
Sayang sekali hal seperti ini belum banyak dibicarakan secara terbuka. Tak seorang pun ingin jadi yang pertama duduk saat semua orang sedang wajib tepuk tangan berdiri, tetapi kalau terus pura-pura ini makan siang gratis tanpa kekurangan, diskusinya jadi membosankan dan evolusinya pun melambat
Jika orang-orang yang melakukan pekerjaan paling serius dan paling maju dengan alat baru ini tidak membicarakan kekurangannya, maka pembicaraan tentang sisi negatif AI dalam pengembangan perangkat lunak hanya akan tersisa pada kubu sinis yang menganggap AI tak ada gunanya. Rasanya lebih sulit membicarakan peningkatan jumlah bug atau stagnasi produktivitas daripada kepunahan manusia
Saya ingin tahu apa yang sebenarnya sedang terjadi, bagaimana orang menanggapinya, dan bagaimana semuanya berubah seiring waktu. Rasanya jadi ingin pergi ke meetup atau semacamnya
Judul paper terkait juga adalah "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Kenapa saya harus membaca hasil percakapan spesifik seseorang dengan LLM? Kalau saya tahu topik percakapannya, saya bisa melakukan percakapan yang lebih baik sendiri
Perangkat lunak seperti ini juga mirip. Ada sedikit unsur selera, tetapi yang paling penting biasanya adalah ide dan resep-nya
Akan menarik kalau ada thread bulanan "Vibe HN"
Saya penasaran apakah ada yang bisa membagikan video membuat WhatsApp kustom dalam waktu yang lebih singkat. Itu pun belum mulai menyentuh masalah menarik orang lain ke messenger rakitan dadakan
Sekarang jadinya seperti "saya masukkan tiket ini ke Claude, kamu coba pakai Copilot lalu kita bandingkan hasilnya" atau "saya bikin PR dari hasil kasar saya, lalu kamu review pakai alatmu". Jujur saja ini terasa hampir tak bermakna dan pair programming benar-benar sudah mati
Siapa yang mau melihat beberapa agen berjalan, memperbaiki masalah di worktree yang berbeda, lalu membetulkan ketidaksesuaian di agents.md
Ada dorongan untuk membuat pipeline cloud otonom penuh yang berjalan sendiri, tetapi manajemen sepertinya diam-diam menahannya. Tampaknya ada pemahaman sederhana bahwa begitu terbukti itu benar-benar bisa terbang, beberapa orang pasti akan kehilangan posisi nyaman mereka
UNIX bukanlah produk, melainkan lingkungan yang dioptimalkan untuk membuat alat dan memecahkan masalah nyata, dan alat-alat itu ditulis dalam C. Selama itu BBM mungkin sibuk dengan Lisp di Boston
C++ adalah cerita yang sama sekali berbeda, dan di sana memang perlu IDE
Emacs punya sifat seperti itu karena memakai Lisp. Kecenderungan umum bahwa para programmer mulai membangun semuanya sendiri memang diamati di Lisp, dan itu disebut The Lisp Curse
Disebut kutukan karena programmer berhenti berkolaborasi. Semua menjadi penyihir yang terkurung di menara masing-masing, kemajuan kolektif berhenti, dan datanglah zaman kegelapan
Berkat era LLM, benar bahwa kita membuat perangkat lunak personal
Tetapi sejujurnya, waktu yang saya habiskan memakai Emacs tidak mengajari saya cara membuat perangkat lunak personal. Konfigurasi Emacs saya sangat rapuh, dan ketika saya mencoba memakainya bersama di Windows dan macOS, itu jadi mimpi buruk
Proyek kuliah saya ditulis dengan kombinasi aneh antara org-mode dan semacam workflow untuk menghasilkan file LaTeX yang indah, dan sekarang saya tidak bisa menjelaskan cara mengompilasikannya lagi. Kalau mencoba, saya mungkin akan meminta LLM menerjemahkannya langsung ke LaTeX
Dalam hidup saya, saya ingin pemeliharaan sesedikit mungkin, dan membuat semuanya sendiri tidak selalu sejalan dengan tujuan itu
Saya pernah menulis ulang aplikasi NETFX ke Rust. Soalnya saya kesal proses instalasinya memakan 20 menit: https://github.com/bevan-philip/wlan-optimizer
Pekerjaan harian programmer adalah mengubah perilaku sistem komputer, baik lokal, remote, cloud, embedded, maupun lainnya. Kebutuhan berubah, ruang lingkup bergeser, ruang masalah berevolusi, dan sedimentasi tak bisa dihindari
Kita harus terus berpindah di antara tumpukan bahasa, tipe data, format, alat CLI dan web, protokol, paradigma, open source dan aplikasi proprietary
Jadi kita harus terus beradaptasi, dan control plane pribadi kita pun harus mengikuti perubahan. Kuncinya adalah otomatisasi. Semua gangguan kecil bisa dan harus diotomatisasi. Itu berarti terus-menerus membentuk ulang workflow, yaitu pemeliharaan alat yang berkelanjutan, tetapi bukan pemeliharaan reaktif yang menyiksa
Menjadi programmer tetapi tidak ingin terus membuat perangkat lunak untuk diri sendiri adalah ilusi. Itu seperti koki yang menyalakan api di restoran tetapi di rumah bahkan tidak mau memegang pisau
Emacs adalah dapur rumah sang koki. Ada pemeliharaan reaktif seperti memperbaiki kerusakan dan mengikuti perubahan, dan ada pemeliharaan generatif yaitu membentuk alat agar sesuai dengan pemahaman yang terus berkembang. Programmer membenci yang pertama dan seharusnya tertarik pada yang kedua
Emacs hampir unik cocok untuk pemeliharaan generatif karena alat dan pekerjaannya berbagi temperamen yang sama
Keluhan bahwa Emacs "terlalu banyak pekerjaan di bagian konfigurasi" memang umum, tetapi biasanya maksudnya adalah "saya tidak ingin berinvestasi sebelum mendapat nilai". Itu bukan strategi yang bijak dalam jangka panjang. Lebih tepat melihat Emacs sebagai alat universal untuk mengurangi total beban pemeliharaan sepanjang karier dan hidup
Konfigurasi Emacs atau VIM hanyalah file teks biasa, jadi bisa dibuka dengan editor biasa dan diperbaiki sesuai kebutuhan, dan kita tahu apa ada di mana. Konfigurasi VIM saya sudah 20 tahun, dan 1~2 tahun lalu saya cuma berhenti mengelola paket secara manual lalu mulai memakai plugin manager
Tidak ada gatekeeper, tidak ada dependensi
Sebaliknya, cara sekarang menuntut membayar perusahaan pihak ketiga 20~200 dolar, atau butuh GPU yang cukup kuat untuk menjalankan lokal, dan kita harus menaruh instruksi di file teks lalu terus mengutak-atiknya sampai hasilnya sesuai keinginan
Itu berarti menambahkan dependensi sendiri, dan jika akhirnya jadi begitu kusut sampai manusia sulit me-review-nya, dependensi itu akan menjadi dependensi yang kuat. Entah itu GPU mahal atau mengirim data ke perusahaan yang harus memuaskan pemegang saham, sama saja
Kita perlu membedakan bagaimana kedua hal ini berbeda, dan apa biaya nyata yang kita bayarkan
Gagasan tentang perangkat lunak personal, yaitu menulis program untuk diri sendiri, adalah visi asli komputasi rumahan pada tahun 1960-an
PC tidak diprediksi secara persis, tetapi ada gagasan bahwa semua orang akan punya terminal komputer di rumah dan menulis program untuk melakukan hal-hal yang mereka butuhkan. Dibayangkan bahwa pemrograman akan menjadi cukup mudah untuk dipelajari siapa saja
Kita belum sampai sana, tetapi berkat LLM kita semakin mendekat
Gagasannya adalah bahwa nonprofesional bisa membuat perangkat lunak yang menarik di lingkungan authoring dengan komponen yang dirancang baik dan metafora yang mudah dipahami. Lapisan kompleksitas yang kebetulan muncul atau berlebihan harus disingkirkan
Bahkan dalam visi ini, perangkat lunak tetap membutuhkan pemikiran logis yang cermat, tetapi kerepotan menerjemahkan pemikiran itu menjadi kode yang dapat dijalankan jauh berkurang. Tidak ada juga mimpi buruk toolchain dan build system
Sebaliknya, kita malah membuat model yang terlalu kuat agar bisa mengulang dan menyusun ulang mantra kompleks sebagai gantinya. Tetapi kompleksitasnya masih tetap ada, dan bagi nonprofesional tetap tidak transparan
Meski begitu, LLM mungkin tetap bisa membantu menghilangkan sebagian kompleksitas itu. Arah di mana orang dapat dengan mudah memahami perangkat lunak hasil generasi LLM dan memodifikasinya sendiri masih mungkin, dan bisa sangat saling melengkapi dengan dunia LLM
Ini bukan soal mungkin atau tidak, tetapi soal kapan, paling lama 10 tahun lagi, mungkin bahkan jauh lebih cepat. Saudara saya yang tidak bisa coding pun sudah melakukan hal seperti ini
Arah masa depan komputasi ini benar-benar indah dan sangat memberdayakan
Saat ini aplikasi Swift itu 15 ribu baris, dengan 5000 baris test dan 10 ribu baris implementasi. Sekarang hampir selesai dan melakukan apa yang saya butuhkan. Butuh 20 jam
Karena saya belum pernah memakai Swift, kalau saya membuatnya sendiri secara manual mungkin akan makan 500 jam
Karena kebanyakan dari kita malas, mungkin tidak akan sampai sejauh itu, tetapi tetap layak dipikirkan
Konsep aplikasi itu sendiri akan menjadi jauh lebih cair
Jika aplikasi dibuat dalam bahasa dinamis, tidak ada alasan mengapa pengguna tidak bisa menulis ulang kodenya sendiri dan menambahkan fungsi yang benar-benar baru
Tidak berhubungan langsung dengan isi artikel, tetapi saya tidak setuju bahwa terminal yang hampir selalu fixed-width membuat membaca teks panjang jadi melelahkan. Secara pribadi, saya jauh lebih nyaman membaca teks panjang dengan font monospace
Penulis menyinggung poin yang menarik. Variabel yang bekerja di sini adalah tingkat kesulitan membuat alat, tingkat kesulitan menerbitkannya, seberapa berguna bagi orang lain, imbalan sosial saat dipublikasikan, dan insentif negatif dari penambahan dependensi
Tingkat sulitnya menemukan solusi yang sudah ada akan naik sesuai biaya yang harus ditanggung seseorang untuk membuatnya dan biaya yang harus ditanggung orang lain untuk mencari tahu cara mempublikasikannya. Sebaliknya, semakin berguna bagi komunitas, semakin mudah ditemukan karena orang-orang akan saling memberi tahu
Jika tingkat kesulitan membuat dan mempublikasikan sangat berbeda, terutama jika membuat jauh lebih tinggi, orang cenderung membuat sesuatu lalu melupakannya. Jika sisi publikasi rendah, solusi masalah akan jadi lebih sedikit
Jika keduanya rendah, dan kegunaan bagi orang lain serta imbalan sosial lebih tinggi daripada biaya dependensi, maka muncullah situasi seperti leftpad. Banyak paket di NPM terdiri dari kegunaan tinggi, imbalan tinggi, dan biaya dependensi rendah
Di Emacs Lisp, dulu tingkat kesulitan membuat itu tinggi tetapi sekarang rendah, dan setelah melewati kurva belajar, tingkat kesulitan publikasi juga rendah. Kegunaan, imbalan, dan biaya dependensi pun tidak tinggi ke salah satu arah
Maka muncullah skenario di mana orang langsung membuatnya bahkan sebelum mencari tahu apakah alat itu sudah ada. VSCode atau Eclipse lama berbeda karena tingkat kesulitan publikasinya tinggi
Sepertinya akan ada seseorang yang lebih muda dari saya yang menjadikan ini topik paper dan melemparkannya ke dunia
Tulisan ini menyiratkan satu perubahan yang belum terwujud dari coding dengan LLM. Sekarang, tidakkah kita bisa membuang Electron/React Native, lalu membiarkan LLM mengubah Figma, wireframe, dan spesifikasi perilaku menjadi aplikasi native sungguhan untuk tiap platform?
Untuk aplikasi CRUD, hanya dengan spesifikasi API dan mockup UI, bahkan foto layar dari platform lain yang sudah diimplementasikan, kita sudah bisa melangkah cukup jauh. Pekerjaan yang terdefinisi jelas seperti ini adalah jenis hal yang dikerjakan LLM dengan baik. Pengujian kesetaraan pun seharusnya bisa cukup banyak diotomatisasi
Apakah alasan seperti "mungkin suatu hari kami juga akan menambah Android" atau "pengguna Mac/Linux tidak cukup banyak" masih akan tersisa? Apakah masih masuk akal di aplikasi iOS untuk tidak mengimplementasikan alur yang jarang dipakai seperti reset password lalu sekadar membuka WebView sembarangan?
Bahkan untuk aplikasi dengan logika yang tidak sepele di dalam perangkat, LLM sudah menunjukkan potensi yang cukup baik untuk menulis ulangnya dalam bahasa yang mudah cross-compile seperti Go atau Rust
Kalau mau lebih provokatif, pada titik ini untuk apa belajar SwiftUI? Untuk sebagian besar pekerjaan, keahlian SwiftUI masuk kategori yang mirip dengan "mendalami Microsoft Word sampai sangat dalam"
Saya menghormati orang yang meluangkan waktu untuk itu, tetapi entah dilakukan atau tidak, perbedaan hasilnya hampir setingkat milimeter
Saya tidak berpikir begitu untuk pemrograman secara umum. Hanya saja sekarang alasan untuk mendalami bahasa tertentu menjadi lebih rumit untuk beberapa kasus