Jelajahi gagasan utama Alan Kay di balik Smalltalk dan GUI awal—dan bagaimana itu membentuk pandangan masa kini tentang perangkat lunak sebagai sistem objek yang saling berinteraksi.
Alan Kay bukan sekadar nama dalam sejarah pemrograman. Banyak asumsi sehari-hari tentang komputer—apa itu “jendela”, mengapa perangkat lunak harus interaktif, bagaimana program bisa dibangun dari bagian-bagian yang bekerjasama—dibentuk oleh gagasan yang ia dorong (sering bersama tim di Xerox PARC).
Tulisan ini membahas konsep, bukan trivia. Anda tidak perlu bisa menulis kode untuk mengikutinya, dan Anda tidak akan menemukan tur detail teknis yang langka. Sebaliknya, kita fokus pada beberapa model mental yang masih muncul di alat dan produk yang kita gunakan: bagaimana perangkat lunak dapat dipahami, diubah, dan dipelajari.
Pertama, Smalltalk: bukan hanya bahasa pemrograman, melainkan seluruh lingkungan kerja yang mendorong eksplorasi dan pembelajaran.
Kedua, GUI (antarmuka pengguna grafis): jendela, ikon, menu—perangkat lunak interaktif sebagai sesuatu yang bisa Anda manipulasi langsung, bukan sekadar diperintahkan.
Ketiga, pemikiran sistem: melihat perangkat lunak sebagai sekumpulan bagian yang saling berinteraksi dengan loop umpan balik, bukan sekadar tumpukan file kode.
Tulisan ini tidak akan memperlakukan Kay sebagai jenius tunggal, dan tidak akan mengklaim bahwa satu paradigma “benar” menyelesaikan semuanya. Beberapa gagasan berhasil luar biasa, beberapa disalahpahami, dan beberapa tidak tersebar seluas yang seharusnya.
Tujuannya praktis: di akhir, Anda seharusnya bisa melihat aplikasi dan basis kode modern dengan rasa yang lebih jelas tentang mengapa mereka terasa seperti itu—dan apa yang bisa Anda pinjam untuk proyek berikutnya.
Alan Kay melangkah ke budaya komputasi yang kuat, mahal, dan pada umumnya kurang ramah bagi orang biasa. Komputer diperlakukan seperti infrastruktur bersama: Anda memesan waktu, mengajukan pekerjaan, dan menunggu hasil. Model itu membentuk segalanya—bagaimana program terlihat, siapa yang bisa menggunakannya, dan apa arti “sukses”.
Bagi banyak pengguna, komputasi berarti menyerahkan pekerjaan ke mesin (sering lewat kartu atau terminal antrian) dan menerima keluaran kemudian. Jika ada yang salah, Anda tidak bisa “mengutak-atik” dan belajar—Anda mengajukan ulang dan menunggu lagi. Eksplorasi lambat, dan komputer terasa lebih seperti layanan jauh daripada alat yang bisa Anda pikirkan bersama.
Target Kay bukan sekadar “komputer lebih kecil.” Ini soal hubungan yang berbeda: komputer sebagai medium personal untuk belajar, menulis, mensimulasikan, menggambar, dan membangun ide—terutama untuk anak-anak dan non-spesialis. Itu membutuhkan immediacy. Anda perlu melihat apa yang dilakukan aksi Anda, merevisi dengan cepat, dan tetap berada dalam alur kreatif.
Untuk mengejar perubahan semacam itu, Anda butuh ruang untuk bereksperimen dengan perangkat keras, perangkat lunak, dan desain interaksi secara bersamaan. Laboratorium riset seperti Xerox PARC membiayai taruhan jangka panjang: layar baru, perangkat input baru, model pemrograman baru, dan cara baru mengemasnya menjadi pengalaman yang koheren. Tujuannya bukan hanya menghadirkan fitur—melainkan menciptakan jenis penggunaan komputer yang baru.
Jika komputer akan menjadi mesin pembelajaran dan kreativitas, kegunaan tidak boleh menjadi pemikiran setelahnya. Antarmuka harus mendukung penemuan, umpan balik, dan tindakan yang dapat dipahami. Fokus itu mendorong Kay ke arah sistem di mana “rasa” interaksi—apa yang terjadi saat Anda mengklik, mengedit, atau mengeksplorasi—terkait erat dengan bagaimana perangkat lunak itu sendiri disusun.
Alan Kay tidak memulai dengan “Bagaimana kita mempercepat pekerjaan kantor?” Ia memulai dengan pertanyaan berbeda: bagaimana jika seorang anak bisa membawa komputer pribadi seperti buku, dan menggunakannya untuk mengeksplorasi ide, membuat hal, dan belajar sambil melakukan? Pemikiran itu menjadi Dynabook—bukan spes produk melainkan bintang utara untuk komputasi personal.
Dynabook dibayangkan ringan, bertenaga baterai, dan selalu tersedia. Tetapi kata terpenting bukan “portabel.” Kata itu adalah “personal.” Komputer ini akan menjadi milik penggunanya seperti buku catatan atau alat musik—sesuatu yang Anda bentuk seiring waktu, bukan sekadar Anda operasikan.
Sama pentingnya: komputer itu harus bisa dipelajari. Tujuan Kay bukan menyembunyikan komputasi di balik dinding menu; melainkan membiarkan orang perlahan menjadi penulis, bukan hanya konsumen.
“Aplikasi pembunuh” Dynabook adalah membaca, menulis, menggambar, menyusun musik, mensimulasikan eksperimen sains, dan membangun cerita interaktif. Ia memperlakukan pemrograman sebagai literasi—cara lain untuk mengekspresikan ide—bukan perdagangan khusus yang hanya untuk para profesional.
Fokus ini mengubah makna “perangkat lunak yang baik.” Alat pembelajaran harus mengundang oprek, memberikan umpan balik cepat, dan membuatnya aman untuk mencoba lagi.
Di sinilah Smalltalk dan GUI awal masuk. Jika Anda ingin orang mencipta, Anda butuh manipulasi langsung, hasil seketika, dan lingkungan di mana bereksperimen terasa alami. Sistem interaktif Smalltalk dan metafora visual GUI mendukung tujuan yang sama: memendekkan jarak antara ide dan artefak yang bekerja.
Dynabook bukan “meramalkan tablet.” Ia mengusulkan hubungan baru dengan komputasi: medium untuk berpikir dan berkarya. Banyak perangkat bisa mendekati itu, tetapi visi ini tentang memberdayakan pengguna—terutama pelajar—bukan tentang ukuran layar atau desain perangkat keras tertentu.
Saat orang mendengar “Smalltalk,” mereka sering membayangkan bahasa pemrograman. Tim Kay memandangnya lebih luas: sistem kerja lengkap di mana bahasa, alat, dan pengalaman pengguna dirancang sebagai satu kesatuan.
Dalam istilah sederhana, Smalltalk adalah sistem di mana segala sesuatu adalah objek. Jendela di layar, teks yang Anda ketik, tombol yang Anda klik, angka yang Anda hitung—masing-masing adalah objek yang bisa Anda minta melakukan sesuatu.
Smalltalk dibangun untuk belajar dengan praktik. Alih-alih menulis kode, mengompilasi, dan berharap itu bekerja, Anda bisa memeriksa objek saat sistem berjalan, melihat keadaan mereka sekarang, mengubahnya, dan segera mencoba gagasan baru.
Kehidupan sistem itu penting karena mengubah pemrograman menjadi eksplorasi. Anda tidak sekadar menghasilkan file; Anda membentuk dunia yang sedang berjalan. Ia mendorong rasa ingin tahu: “Apa benda ini?” “Apa isiannya?” “Apa yang terjadi jika saya mengubahnya?”
Alat pengembangan Smalltalk bukan tambahan terpisah. Browser, inspector, debugger, dan editor adalah bagian dari alam semesta berbasis objek yang sama. Alat-alat itu memahami sistem dari dalam, karena mereka dibangun di medium yang sama.
Integrasi yang erat itu mengubah perasaan “bekerja pada perangkat lunak”: kurang seperti mengelola kode jauh, lebih seperti berinteraksi langsung dengan sistem yang Anda bangun.
Bayangkan mengedit dokumen saat terbuka dan responsif—perubahan format langsung terlihat, Anda bisa mencari, menyusun ulang, dan membatalkan tanpa perlu “membangun ulang” dokumen terlebih dahulu. Smalltalk mengincar immediacy semacam itu, tetapi untuk program: Anda mengedit sesuatu yang sedang berjalan, melihat hasilnya langsung, dan terus bergerak.
Gagasan mental Kay yang paling berguna bukan “kelas dan pewarisan.” Melainkan gagasan bahwa objek adalah komputer kecil yang membungkus dirinya sendiri: menyimpan state (apa yang diketahuinya sekarang) dan menentukan bagaimana merespons saat Anda memintanya melakukan sesuatu.
Bayangkan setiap objek memiliki:
Pembingkaian ini praktis karena menggeser fokus Anda dari “Di mana data disimpan?” menjadi “Siapa yang bertanggung jawab menangani ini?”
Kekeliruan umum adalah memperlakukan objek sebagai catatan data canggih: sekumpulan field dengan beberapa fungsi pembantu. Dalam pandangan itu, bagian lain program bebas mengintip dan memanipulasi interiornya.
Pandangan Kay lebih dekat ke aktor dalam sebuah sistem. Anda tidak meraih ke dalam objek dan merapikan lacinya. Anda mengirim permintaan dan membiarkannya mengelola state sendiri. Pemisahan itu adalah intinya.
Pertukaran pesan hanyalah permintaan/response.
Bayangkan sebuah kafe: Anda tidak masuk ke dapur dan memasak sendiri. Anda memesan (“buatkan saya sandwich”), dan Anda menerima hasil (“ini sandwich Anda” atau “kami kehabisan roti”). Kafe memutuskan bagaimana memenuhi pesanan.
Objek perangkat lunak bekerja sama: Anda mengirim pesan (“hitung total”, “simpan”, “render dirimu”), dan objek merespons.
Saat bagian lain sistem hanya bergantung pada pesan, Anda bisa mengubah cara kerja internal objek—mengganti algoritma, mengubah penyimpanan, menambah caching—tanpa memaksa penulisan ulang di seluruh tempat lain.
Itulah cara sistem tumbuh tanpa merusak segalanya: kesepakatan stabil di batas-batas, kebebasan di dalam komponen.
Orang sering menyamakan “pemrograman berorientasi objek” dengan “menggunakan kelas.” Wajar—kebanyakan bahasa mengajarkan OOP lewat diagram kelas dan pohon pewarisan. Namun penekanan asli Kay berbeda: pikirkan dalam istilah bagian yang saling berkomunikasi.
Sebuah kelas adalah cetak biru: menjelaskan apa yang sesuatu tahu dan apa yang dapat dilakukannya.
Sebuah instance (atau objek) adalah benda konkret yang dibuat dari cetak biru itu—satu dari jenisnya.
Method adalah operasi yang bisa dijalankan objek ketika diminta.
State adalah data saat ini objek: apa yang diingatnya sekarang, yang bisa berubah seiring waktu.
Smalltalk membantu memopulerkan model objek yang seragam: segala sesuatu adalah objek, dan Anda berinteraksi dengan objek secara konsisten. Ia juga menekankan pertukaran pesan—Anda tidak meraih ke dalam internals objek lain; Anda mengirim pesan dan membiarkan objek memutuskan apa yang dilakukan.
Gaya itu berpasangan dengan late binding (sering lewat dynamic dispatch): program memutuskan saat runtime method mana yang menangani pesan, berdasarkan objek penerima. Manfaat praktisnya adalah fleksibilitas: Anda bisa mengganti perilaku tanpa menulis ulang pemanggil.
Pedoman praktis: rancang sekitar interaksi. Tanyakan “Pesan apa yang harus ada?” dan “Siapa yang harus memiliki state ini?” Jika objek berkolaborasi dengan rapi, struktur kelas biasanya menjadi lebih sederhana—dan lebih mudah diubah—sebagai efek samping.
Antarmuka grafis mengubah rasa “menggunakan perangkat lunak.” Alih-alih menghafal perintah, Anda menunjuk, memindahkan, membuka, dan melihat hasil langsung. Jendela, menu, kontrol, dan tombol membuat komputasi terasa lebih dekat dengan menangani benda fisik—manipulasi langsung daripada instruksi abstrak.
“Keterbellakangan” itu cocok secara alami dengan model objek. Di UI yang dirancang baik, hampir semua yang Anda lihat dan interaksikan bisa diperlakukan sebagai objek:
Ini bukan hanya kenyamanan pemrograman; ini jembatan konseptual. Pengguna berpikir dalam istilah objek (“pindahkan jendela ini”, “klik tombol itu”), dan perangkat lunak dibangun dari objek yang benar-benar bisa melakukan tindakan itu.
Saat Anda klik, ketik, atau seret, sistem menghasilkan event. Dalam pandangan berorientasi objek, sebuah event pada dasarnya adalah pesan yang dikirim ke objek:
Objek kemudian bisa meneruskan pesan ke objek lain (“beritahu dokumen untuk menyimpan”, “minta jendela untuk menggambar ulang”), menciptakan rantai interaksi yang dapat dipahami.
Karena UI terdiri dari objek persisten dengan state yang terlihat, ia terasa seperti memasuki ruang kerja daripada menjalankan perintah satu kali. Anda bisa meninggalkan jendela terbuka, menyusun alat, kembali ke dokumen, dan melanjutkan dari tempat terakhir. GUI menjadi lingkungan koheren—tempat di mana tindakan adalah percakapan antar objek yang bisa Anda lihat.
Salah satu gagasan khas Smalltalk bukan fitur sintaks—melainkan image. Alih-alih memandang program sebagai “kode sumber yang dikompilasi menjadi aplikasi,” Smalltalk menganggap sistem sebagai dunia objek yang berjalan. Saat Anda menyimpan, Anda bisa menyimpan seluruh lingkungan hidup: objek di memori, alat yang terbuka, state UI, dan pekerjaan Anda saat itu.
Sistem berbasis image seperti menjeda film dan menyimpan bukan hanya naskah, tetapi tepat pada frame, set, dan posisi setiap aktor. Saat dilanjutkan, Anda kembali ke tempat Anda berhenti—alat masih terbuka, objek masih ada, dan perubahan Anda sudah dalam gerak.
Ini mendukung loop umpan balik yang ketat. Anda bisa mengubah perilaku, mencobanya segera, mengamati apa yang terjadi, dan menyempurnakan—tanpa gangguan mental “bangun ulang, jalankan ulang, muat ulang data, navigasi kembali ke layar.”
Prinsip yang sama muncul dalam alur kerja “vibe-coding” modern juga: ketika Anda dapat menggambarkan perubahan dalam bahasa biasa, melihatnya diterapkan segera, dan mengiterasi, Anda mempelajari sistem lebih cepat dan mempertahankan momentum. Platform seperti Koder.ai mengeksploitasi ini dengan mengubah pembuatan aplikasi menjadi loop percakapan—rencanakan, sesuaikan, pratinjau—sementara masih menghasilkan kode nyata yang bisa diekspor dan dipelihara.
Anda bisa melihat gema gagasan image dalam fitur-fitur yang populer hari ini:
Mereka tidak identik dengan image Smalltalk, tetapi berbagi tujuan: memendekkan jarak antara ide dan hasil sebanyak mungkin.
Menyimpan dunia yang berjalan menimbulkan pertanyaan sulit. Reproducibility bisa terganggu jika “kebenaran” hidup dalam state yang mudah berubah alih-alih proses build yang bersih. Penyebaran (deployment) menjadi lebih rumit: mengirim image bisa mengaburkan batas antara aplikasi, data, dan lingkungan. Debugging juga bisa lebih kompleks ketika bug bergantung pada urutan interaksi tertentu dan state yang terakumulasi.
Taruhan Smalltalk adalah bahwa pembelajaran dan iterasi yang lebih cepat sepadan dengan komplikasi itu—dan taruhan itu masih memengaruhi bagaimana banyak tim memandang pengalaman pengembang.
Saat Alan Kay berbicara tentang perangkat lunak, ia sering memperlakukannya kurang seperti tumpukan kode dan lebih seperti sistem: banyak bagian yang berinteraksi dari waktu ke waktu untuk menghasilkan perilaku yang Anda pedulikan.
Sebuah sistem tidak ditentukan oleh komponen tunggal. Ia ditentukan oleh hubungan—siapa bicara dengan siapa, apa yang boleh mereka minta, dan apa yang terjadi saat percakapan itu berulang.
Beberapa komponen sederhana bisa menciptakan perilaku kompleks ketika Anda menambahkan pengulangan dan umpan balik. Timer yang berdetak, model yang memperbarui state, dan UI yang menggambar ulang masing-masing mungkin sederhana. Gabungkan mereka dan Anda mendapatkan animasi, undo/redo, autosave, alert, dan momen “kenapa itu berubah?”
Itulah mengapa berpikir sistem praktis: mendorong Anda mencari loop (“saat A berubah, B bereaksi, yang memicu C…”) dan aspek waktu (“apa yang terjadi setelah 10 menit penggunaan?”), bukan sekadar panggilan fungsi tunggal.
Dalam sebuah sistem, antarmuka lebih penting daripada implementasi. Jika satu bagian hanya bisa berinteraksi dengan bagian lain melalui pesan yang jelas (“increment count”, “render”, “record event”), Anda bisa mengganti internals tanpa menulis ulang semuanya.
Ini dekat dengan penekanan Kay pada pertukaran pesan: Anda tidak mengendalikan bagian lain secara langsung; Anda meminta, mereka merespons.
Bayangkan tiga objek:
Alur seiring waktu:
clicked.increment ke CounterModel.changed(newValue).changed dan menggambar ulang.record("increment", newValue).Tidak ada komponen yang perlu mengintip interior komponen lain. Perilaku muncul dari percakapan.
Alan Kay menekankan gagasan sederhana yang masih terasa radikal: perangkat lunak harus mudah dipelajari, bukan sekadar kuat. Desain “pintar” sering mengoptimalkan kepuasan pencipta—jalan pintas, trik tersembunyi, abstraksi padat—sementara meninggalkan pengguna biasa menghafal rutinitas.
Kay peduli pada kesederhanaan karena itu berskala: konsep yang bisa dipahami pemula dengan cepat adalah konsep yang bisa tim ajarkan, bagikan, dan kembangkan.
Banyak perangkat lunak memperlakukan pengguna seperti operator: tekan tombol yang benar, dapatkan keluaran. Tujuan Kay lebih mendekati alat berpikir—sesuatu yang mengundang eksplorasi, mendukung coba-coba, dan membiarkan orang membangun model mental.
Inilah mengapa ia menghargai sistem interaktif di mana Anda bisa melihat apa yang terjadi dan menyesuaikan seiring jalan. Saat sistem merespons dengan segera dan bermakna, pembelajaran menjadi bagian dari penggunaan.
Kay sering menggunakan pembelajaran—terkadang membayangkan anak sebagai pengguna—sebagai fungsi pemaksa untuk kejelasan. Jika sebuah konsep bisa dimanipulasi langsung, diinspeksi, dan dijelaskan tanpa basa-basi, besar kemungkinannya bekerja untuk semua orang.
Ini bukan berarti “desain hanya untuk anak.” Melainkan menggunakan kemampuan diajarkan sebagai tes kualitas: bisakah sistem memperlihatkan logikanya sendiri?
Keterpelajaran adalah fitur produk. Anda bisa mendesain untuk itu dengan:
Keuntungannya bukan hanya pengguna pemula yang lebih bahagia. Ini onboarding yang lebih cepat, lebih sedikit tiket dukungan, dan produk yang orang rasa percaya untuk kembangkan—tepat jenis “agensi pengguna” yang ingin diperkuat Kay.
Karya Kay tidak “menciptakan semua yang kita pakai sekarang,” tetapi sangat memengaruhi cara banyak orang berpikir tentang membangun perangkat lunak—terutama perangkat lunak yang ditujukan untuk manusia, bukan hanya mesin.
Banyak praktik modern menggaungkan ide yang Smalltalk dan budaya Xerox PARC konkretkan dan populerkan:
Beberapa bagian visi asli tidak terbawa lancar:
Jika Anda mengerling, banyak pola saat ini berima dengan pertukaran pesan: UI berbasis komponen (React/Vue), aplikasi event-driven, dan bahkan microservices yang berkomunikasi lewat HTTP atau antrean. Mereka bukan hal yang sama—tetapi menunjukkan bagaimana gagasan inti Kay (sistem sebagai bagian yang saling berinteraksi) terus ditafsirkan ulang di bawah keterbatasan modern.
Jika Anda ingin jembatan praktis dari sejarah ke praktik, bagian terakhir (lihat /blog/practical-takeaways) mengubah pengaruh ini menjadi kebiasaan desain yang bisa Anda gunakan segera.
Karya Kay bisa terdengar filosofis, tetapi ia diterjemahkan menjadi kebiasaan sangat praktis. Anda tidak perlu memakai Smalltalk—atau bahkan “melakukan OOP”—untuk mendapatkan manfaat. Tujuannya adalah membangun perangkat lunak yang tetap dapat dipahami seiring berkembang.
Saat memulai (atau merombak), coba gambarkan sistem sebagai sekumpulan peran yang bekerja bersama:
Ini menjaga fokus pada tanggung jawab, bukan pada “kelas karena kita butuh kelas.”
Sebelum berdebat tentang tabel database atau hierarki kelas, definisikan pesan—apa yang satu bagian minta ke bagian lain.
Latihan berguna: tulis “percakapan” singkat untuk satu aksi pengguna:
Baru kemudian tentukan bagaimana peran itu diimplementasikan (kelas, modul, layanan). Ini dekat dengan penekanan Kay pada pertukaran pesan: perilaku dulu, struktur belakangan.
Kay peduli pada sistem hidup di mana Anda bisa melihat efek perubahan dengan cepat. Di tim modern, itu biasanya berarti:
Jika Anda tidak bisa memberitahu apa yang berubah—atau apakah itu membantu—Anda terbang tanpa instrumen.
Jika Anda membangun dengan alur kerja berbasis chat (misalnya di Koder.ai), nasihat yang sama berlaku: perlakukan prompt dan output yang dihasilkan sebagai cara untuk beriterasi lebih cepat, tetapi pertahankan batas eksplisit, dan gunakan pengaman seperti snapshot/rollback dan ekspor kode sumber agar sistem tetap dapat dipahami dari waktu ke waktu.
Jika bagian ini beresonansi, jelajahi:
Topik-topik ini bukan tentang nostalgia, melainkan tentang mengembangkan selera: membangun perangkat lunak yang bisa dipelajari, mudah diadaptasi, dan koheren sebagai sebuah sistem.
Alan Kay berargumen untuk hubungan yang berbeda dengan komputer: bukan pekerjaan batch yang antre, melainkan medium personal interaktif untuk belajar dan berkarya.
Polanya ini langsung membentuk ekspektasi yang sekarang kita anggap normal—umpan balik seketika, antarmuka yang bisa dimanipulasi, dan perangkat lunak yang bisa dieksplorasi serta dimodifikasi saat Anda bekerja.
Dynabook adalah visi tentang komputer portabel dan personal yang dirancang terutama untuk belajar dan kreativitas (membaca, menulis, menggambar, simulasi).
Ini bukan sekadar “ramalan tablet”; lebih tepatnya ia mendefinisikan bagaimana komputasi yang memberdayakan seharusnya terasa: pengguna sebagai penulis/kreator, bukan sekadar operator.
Di Smalltalk, bahasa, alat, dan antarmuka pengguna membentuk satu lingkungan koheren.
Secara praktik, ini berarti Anda bisa memeriksa objek yang sedang berjalan, mengubah perilaku, melakukan debug secara interaktif, dan terus bekerja tanpa harus sering membangun ulang atau memulai ulang—memendekkan jarak antara ide dan hasil.
Inti gagasan Kay bukan “kelas dan pewarisan.” Melainkan objek sebagai agen mandiri yang berkomunikasi dengan mengirim pesan.
Dalam rancangan, ini mendorong Anda menetapkan batas yang jelas: pemanggil bergantung pada pesan yang diterima objek, bukan pada tata letak data internalnya.
Kesalahpahaman umum adalah melihat OOP sebagai taksonomi tipe: banyak kelas, pewarisan dalam, dan data mutable bersama.
Aturan praktis menurut sudut pandang Kay:
GUI membuat perangkat lunak terasa seperti Anda memanipulasi benda (jendela, tombol, ikon). Itu cocok dengan model objek di mana setiap elemen UI punya state dan perilaku.
Aksi pengguna (klik, seret, ketik) menjadi event yang pada dasarnya adalah pesan ke objek—yang kemudian bisa meneruskan permintaan ke bagian lain dari sistem.
Sebuah image Smalltalk menyimpan seluruh dunia yang berjalan: objek di memori, alat yang terbuka, keadaan UI, dan pekerjaan Anda saat itu.
Keuntungan:
Kompromi:
Berpikir sistem menekankan perilaku sepanjang waktu: loop umpan balik, reaksi berantai, dan siapa yang berkomunikasi dengan siapa.
Dalam praktiknya, itu mengarahkan desain ke antarmuka yang lebih jelas (pesan) dan mengurangi dependensi tersembunyi—karena Anda melihat aplikasi sebagai bagian-bagian yang saling berinteraksi, bukan hanya fungsi terisolasi.
Gunakan desain berorientasi pesan untuk satu alur kerja:
getTotal, isAvailable, authorize).Barulah kemudian pilih implementasinya (kelas, modul, layanan). Checklist di /blog/practical-takeaways adalah titik awal yang bagus.
Paralel modern sering berima dengan tujuan Kay meski implementasinya berbeda:
Mereka bukan Smalltalk image, tetapi mengejar hasil praktis yang sama: membuat perubahan dan pembelajaran menjadi murah.