Notation sebagai Alat Berpikir (1979)
(jsoftware.com)- Notasi (Notation) adalah alat penting yang membantu proses berpikir, dan memainkan peran inti baik dalam matematika maupun bahasa pemrograman
- Bahasa APL dikembangkan sebagai upaya menggabungkan keunggulan notasi matematis dengan eksekutabilitas dan universalitas bahasa pemrograman
- Ciri notasi yang baik mencakup keringkasan, kejelasan, daya sugesti, subordinasi detail, dan kemungkinan pembuktian formal
- Berbagai struktur matematis (polinom, transformasi, graf, dll.) dapat diekspresikan dan ditransformasikan secara efisien dengan APL
- Pengenalan dan pembelajaran notasi harus berlangsung secara alami dalam konteks, dan struktur serta sifat serbagunanya juga penting
Notasi sebagai alat berpikir
- Di bidang sains seperti kimia dan botani, tata nama yang sistematis juga mendorong perkembangan disiplin ilmu
- George Boole menekankan bahwa bahasa itu sendiri adalah sarana berpikir
- Notasi matematis adalah contoh representatif dari bahasa yang mendukung pemikiran, mengurangi beban berpikir dan meningkatkan daya pikir
- A.N. Whitehead dan Charles Babbage menekankan pentingnya notasi matematika
Potensi bahasa pemrograman sebagai alat berpikir
- Bahasa pemrograman memiliki keunggulan berupa universalitas dan kejelasan
- Komputer memungkinkan eksperimen ide dan eksperimen berpikir yang jelas
- Namun, sebagian besar bahasa pemrograman berperan lebih lemah sebagai alat berpikir dibanding notasi matematis
- APL dirancang sebagai notasi yang mendukung pemikiran dengan mengutamakan kejernihan dan ketelitian
Karakteristik utama notasi yang baik
- Kemudahan mengekspresikan masalah: harus dapat dengan mudah menyatakan struktur yang langsung diturunkan dari masalah
- Daya sugesti: bentuk yang diekspresikan harus menyiratkan masalah yang serupa atau perluasannya
- Subordinasi detail: menyediakan struktur yang membantu berpikir dengan menyederhanakan detail yang kompleks
- Keringkasan: harus memungkinkan ekspresi yang luas dengan simbol dan aturan seminimal mungkin
- Kemungkinan pembuktian formal: notasi harus memudahkan pembuktian formal dan penalaran deduktif
Pengantar teknik notasi dasar APL
- Struktur berbasis array seperti vektor dan matriks digunakan secara alami
- Fungsi dan operator diterapkan otomatis ke vektor/matriks per elemen
- Komposisi fungsi diekspresikan dengan operator seperti reduksi(
/), scan(\), dan inner product(.) - Simbol dasar seperti
⍳,⌽,⍴,+,×,*memungkinkan penyusunan ekspresi yang kaya - Semua fungsi mengikuti aturan prioritas kanan sehingga ekspresi dapat ditulis secara alami tanpa tanda kurung
Contoh pemecahan masalah dan dorongan terhadap pemikiran
- Barisan matematis seperti bilangan segitiga dan faktorial dapat dinyatakan dengan rumus sederhana
- Representasi polinom serta operasi seperti perkalian dan diferensiasi ditangani secara ringkas dengan aturan yang konsisten
- Teori graf (pohon, transitive closure, spanning tree) juga dapat dinyatakan dengan jelas melalui operasi array
- Dapat diperluas ke berbagai bidang seperti permutasi, aljabar Boolean, dan konversi sistem bilangan (faktorisasi prima)
Pembuktian formal dan pemikiran terstruktur
- Karena semua operasi dan ekspresi dinyatakan dalam bentuk yang dapat dieksekusi dengan jelas, verifikasi otomatis melalui komputer dimungkinkan
- Disajikan berbagai contoh pembuktian formal melalui induksi matematika, pencarian menyeluruh, dan enumerasi identitas
- Pembuktian formal atas identity pembagian dari reduksi dan scan serta asosiativitas dan distributivitas operasi inner product
- Pembuktian langsung untuk fungsi simetris Newton, perkalian polinom, dan rumus diferensiasi
Perbandingan APL dan notasi matematika tradisional
- APL menyediakan definisi fungsi yang jelas, operasi array yang konsisten, dan sistem simbol yang kaya
- Untuk semua operasi, digunakan aturan eksekusi dari kanan ke kiri alih-alih aturan prioritas
- Mengurangi kerumitan penggunaan simbol matematika dan mendukung manipulasi formal (formal manipulation)
- Sintaksnya ringkas dan aturannya konsisten, sehingga menguntungkan bagi pemula maupun pengguna mahir
Cara memperkenalkan dan mempelajari notasi
- Ditekankan pendekatan memperkenalkan notasi yang diperlukan secara alami dalam konteks, tanpa "kuliah bahasa" terpisah
- Simbol baru dipelajari secara intuitif di dalam situasi masalah yang konkret
- Yang penting bukan tingkat kesulitan notasinya sendiri, melainkan mengenali berbagai kemungkinan dan daya perluasan yang disiratkan notasi tersebut
Kemungkinan perluasan dan usulan untuk APL
- Diusulkan perluasan fungsi termasuk penanganan bilangan kompleks
- Perlu standardisasi fungsi elemen unik (unique elements) dan ringkasan (summary)
- Dengan pengenalan operator yang lebih digeneralisasi, topik tambahan seperti kalkulus vektor dapat didukung
- Bertujuan meningkatkan kejelasan desain bahasa dan kemampuan penalaran
Keseimbangan antara efisiensi dan kejelasan
- Disarankan untuk terlebih dahulu mendefinisikan notasi yang jelas dan dapat dianalisis, lalu meningkatkan efisiensi melalui optimisasi
- Penjernihan algoritme juga membantu optimisasi lanjutan dan optimisasi kompiler
- Ekspresi dasar yang ditulis dalam APL berpotensi berkontribusi baik pada eksplorasi akademis maupun penerapan industri
1 komentar
Komentar Hacker News
Notasi mudah dianggap sekadar “mengganti satu ekspresi dengan ekspresi lain”, seperti ekspansi shell, tetapi sebenarnya jauh lebih mendalam.
Profesor saya pernah menjelaskan bahwa penemuan besar sering muncul bersama notasi baru, dan notasi baru berarti “cara baru untuk memikirkan masalah ini”.
Menurut saya, banyak masalah terbuka saat ini juga bisa diselesaikan jika muncul notasi yang kuat.
Ini benar-benar kuat, tetapi lebih dekat ke gaya Lisp; sedangkan gaya APL atau Clojure lebih ke arah membuat tipe dasar menjadi sangat berguna.
Alih-alih punya 10 struktur data masing-masing dengan 10 fungsi, pendekatannya adalah 1 struktur data dengan 100 fungsi. Jadi di APL, bukannya membuat DSL, Anda merancang dan menata data dengan sangat cermat, lalu sisanya akan mengikuti dengan pas.
Richard Feynman, saat remaja belajar trigonometri, tidak menyukai notasi sinus dan kosinus, sehingga ia membuat simbol matematika sendiri untuk menyederhanakan rumus dan mengurangi noise.
Belakangan, ia juga menciptakan cara baru untuk memikirkan dan mengekspresikan fisika, seperti diagram Feynman dan notasi slash.
Contoh kecilnya, ketika CoffeeScript muncul, singkatan lambda dan berbagai kemudahan sintaksnya banyak mengubah cara orang menulis JavaScript, serta membuatnya lebih mudah dipikirkan, dibaca, dan diperbaiki.
Rumpun SML/Haskell dan Lisp juga terasa serupa.
Mungkin Anda juga akan menyukai klip pendek Brian Greene dan Barry Mazur ini: https://youtu.be/8wQepGg8tHA
Secara historis, yang menyingkirkan APL bukan hanya keyboard yang aneh, tetapi juga Lotus 1-2-3 dari IBM dan MS Excel yang segera menyusul.
Para insinyur, akademisi, akuntan, dan MBA membutuhkan alat yang lebih baik daripada TI-59 atau HP-12C, sementara bidang ilmu komputer sedang terpaku pada pemrosesan simbol, AI, dan LISP; akhirnya industrilah yang mengisi celah itu.
APL seharusnya bisa punya pengaruh jauh lebih besar daripada spreadsheet dan menyelesaikan lebih banyak masalah; ini sebuah kebetulan yang disayangkan.
Visi aslinya adalah notasi matematika tulisan tangan yang konsisten dan dapat dieksekusi, tetapi itu pada akhirnya tidak pernah tercapai.
Jika tertarik, tulisan ini layak dibaca: https://mlajtos.mu/posts/new-kind-of-paper
Anda bisa menyelesaikan masalah tanpa membayar, dan biaya muncul saat Anda mendistribusikan hasil kompilasi kepada pelanggan berbayar.
Jika solusinya cocok dengan subset tertentu, Anda juga bisa memindahkannya ke April dan menyediakannya dari Common Lisp.
Namun orang-orang di komunitas APL umumnya sangat akademis; mereka memang bisa menyelesaikan pekerjaan engineering dengan cepat dan ringkas, tetapi jika di perusahaan software biasa Anda mulai bicara tentang ranking fungsi atau funktor Naperian, rekan kerja mungkin akan curiga apakah Anda membutuhkan bantuan medis.
Sebagian besar pengembangan software adalah pekerjaan menciptakan bahasa teknis yang agak formal untuk mengekspresikan cara pelanggan dan pengguna berbicara serta berpikir, dan ini tidak mudah dalam bahasa-bahasa turunan Iverson.
Java selama lama memaksa orang menyatakan kata-kata bisnis apa yang masuk dan keluar dari tiap metode, dan dalam hal itu memudahkan pemetaan konsep organisasi ke dalam kode.
Di APL pun data dan fungsi bisa diberi nama, tetapi begitu Anda membawa nama panjang dan struktur namespace untuk memetakan organisasi eksternal ke kode, keringkasan dan keanggunannya hilang.
Bahkan dalam sistem tipe canggih rumpun ML, developer kesulitan menghubungkan ontologi semibahasa yang mereka ciptakan secara langsung dengan organisasi dan proses, dan lebih sering memilih konsep yang matematis atau akademis.
Jika ada orang yang bisa melakukan keduanya, tentu mungkin; tetapi biasanya, cukup sering sudah memadai bila seseorang hanya pandai menerjemahkan ke dunia pelanggan.
Tahun lalu The Array Cast menerbitkan ulang wawancara Iverson tahun 1982: https://www.arraycast.com/episodes/episode92-iverson
Cukup menarik dan lebih mudah didekati daripada kuliah Turing.
APL pada tahun 1979 bukanlah bahasa yang aneh dan pinggiran seperti sekarang.
Saat itu bahasa pemrograman belum menjadi fenomena massa global seperti sekarang, jadi hampir semuanya aneh dan cenderung pinggiran; C pun waktu itu masih cukup baru.
Jika dilihat dengan sedikit kelonggaran, APL tampak seperti abstraksi yang tidak terlalu jauh dari C yang padat, dan memungkinkan orang memprogram komputer tanpa mengimplementasikan sendiri manipulasi pointer di atas array.
Ada cukup banyak buku ajar untuk belajar matematika dengan sintaks APL [1] atau J [2].
Iverson awalnya menggunakan APL sebagai sintaks yang lebih baik untuk matematika, dan implementasi pemrogramannya baru muncul beberapa tahun kemudian.
[1] https://alexalejandre.com/about/#apl
[2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
Dulu saya pernah mendengarkan podcast teori tipe yang sekarang sudah berhenti, dan isinya sangat sulit dipahami.
Konsep dasarnya terhubung dengan konsep-konsep berguna lainnya
Hipotesis Sapir-Whorf juga mirip, tetapi lebih menarik jika dipikirkan secara terbalik
Dalam bahasa yang tidak sempurna, ada hal-hal yang tidak bisa dipikirkan atau sulit dipikirkan; kalau begitu, kita jadi bertanya apakah ada hal-hal yang tidak bisa kita ungkapkan maupun pikirkan dengan bahasa yang kita gunakan
Di sini, “bahasa” dan “pikiran” dapat dipahami lebih luas daripada biasanya
Misalnya, apakah aturan interaksi sosial menentukan cara kita berinteraksi? Dalam “Twitter and Teargas”, Zeynep Tufekci mengatakan bahwa Twitter memungkinkan flash mob, tetapi membuat perubahan sosial yang berkelanjutan menjadi sulit
Apakah mekanisme sosial seperti mengikuti seseorang, berkomentar, atau menekan suka menentukan atau memungkinkan cara kita saling berinteraksi? Mekanisme lain mungkin dapat memungkinkan pemikiran kolektif yang lebih baik
Ada juga musik. Bukan notasi, tetapi apakah musik mengekspresikan sesuatu yang sulit diekspresikan dengan cara lain?
Sebagai seseorang yang mempelajari beberapa bahasa asing, ada banyak hal yang hanya bisa saya pikirkan dalam bahasa tertentu dan sulit dipikirkan dalam bahasa Inggris, bahasa ibu saya
Misalnya, “гулять” dalam bahasa Ukraina dan Rusia memiliki banyak makna yang tidak tertangkap oleh bahasa Inggris, sehingga sebelum mempelajari bahasa-bahasa itu saya tidak pernah memikirkan makna-makna tersebut
“Гулять” secara harfiah berarti “berjalan”, tetapi juga digunakan untuk berarti mencari pengalaman, termasuk pengalaman seksual
Seseorang bisa mengeluh bahwa orang lain menikah terlalu cepat dengan mengatakan “не нагулялся”, yaitu “belum cukup berjalan”
Dalam bahasa Inggris ada ungkapan serupa seperti “sow his wild oats”, tetapi ketika begitu banyak makna terkandung dalam satu verba “berjalan”, cara berpikir tentang menjalani hidup itu sendiri menjadi berbeda
Ketika saya belajar bahasa Arab pun ada banyak makna dan pikiran yang hanya muncul dalam bahasa itu; bukan karena mustahil dijelaskan dalam bahasa Inggris, melainkan karena tidak ada notasi untuk mengungkapkannya secara ringkas, sehingga diperlukan tulisan panjang
Sebagian orang senang bepergian ke pikiran lain melalui bahasa, sementara sebagian lain menjadi lumpuh di hadapan kemungkinan itu
Seperti biasa, keberhasilan ada pada keseimbangan dan pada keduanya
Meski ini adalah fakta yang sangat jelas bagi matematikawan atau ilmuwan komputer, gagasan ini sangat kontroversial di kalangan linguis dan “pendidik”
Padanan linguistiknya adalah hipotesis Sapir-Whorf, yaitu klaim bahwa bahasa yang dipelajari seseorang menentukan cara berpikirnya
Bahasa alami adalah objek budaya, dan memetakan budaya bahkan sebagai urutan parsial yang lemah pun dianggap seperti tabu di dunia akademik
Ini juga punya konsekuensi besar bagi pendidikan: ada kalanya siswa tidak belajar notasi yang memungkinkan mereka benar-benar menalar masalah yang mereka hadapi
Sejujurnya, bagian ini tidak terlalu saya pahami
Fakta bahwa penutur bahasa apa pun dapat mempelajari matematika atau program komputer yang sama menunjukkan hal itu
Apakah bahasa lisan atau tulisan benar-benar diperlukan untuk berpikir juga patut dipertanyakan
Setidaknya ada wilayah besar pemikiran yang mungkin tanpa bahasa, dan manusia pun pernah tidak memiliki ujaran atau memilikinya sangat sedikit; pikiran dan niat untuk berkomunikasilah yang menciptakan kata dan bahasa
Karena itu, terasa aneh melihat bahasa yang dipelajari sebagai model dasar pemikiran
Misalnya, jika suatu masyarakat menyebut warna laut dan warna rumput dengan kata yang sama, ada yang menyatakan bahwa mereka tidak dapat mengalami perbedaan antara kedua warna itu
Bukan sekadar bahwa pengalaman itu dienkode ke dalam ingatan dengan cara yang mirip, melainkan seolah-olah mereka tidak dapat melihat perbedaannya
Klaim bahwa bunyi yang tidak ada dalam suatu bahasa sama sekali tidak bisa didengar juga serupa
Pembahasan notasi di sini lebih dekat pada gagasan bahwa kosakata dapat digunakan untuk eksplorasi
Misalnya, bukan hanya mengatakan bahwa seseorang mendengar suatu bunyi, tetapi bahwa ia mendengar musik, dan mendengar progresi akor tertentu, dan seterusnya
Saat ini saya sedang mengembangkan proyek dengan APL
Ini sudah lama ada di backlog, tetapi sekarang saya benar-benar sedang menulis kodenya
Ada jeda yang cukup panjang antara saat saya mulai tertarik dan saat saya bisa menulis lebih dari sekadar satu baris
Pada awal proses itu saya menemukan makalah ini dan membacanya seperti menyerapnya, dan kini konsep-konsepnya telah menjadi fondasi penuh bagi cara berpikir saya
Saya bahkan mengajarkan NAATOT dalam program arsitektur
Maksudnya desain arsitektur, bukan arsitektur perangkat lunak
Saya menggunakan versi yang disunting agar inti gagasan Iverson tetap hidup, dan matematika serta pemrograman nyatanya hanya disisakan secukupnya untuk menunjukkan poinnya dan menantang mahasiswa agar memikirkan desain serta kemungkinan alat ekspresi secara berbeda
Dengan kata lain, ini membahas proses membentuk gagasan, cara mengekspresikannya kepada diri sendiri dan orang lain, dan hal-hal semacam itu
Jika ada kesempatan melakukannya dalam program yang lebih longgar dan terbuka, saya ingin mencoba menjalankan kelas tempat mahasiswa membuat sistem simbol dan notasi mereka sendiri untuk diterapkan pada ranah desain arsitektur
Saya menyesal tidak menyelesaikan aplikasi catatan Freeform yang dulu saya buat
Itu adalah aplikasi yang dikompilasi menjadi halaman web mandiri melalui SVG, dan menurut saya itu ide yang benar-benar keren untuk konten teknis yang umum di bidang STEM
Contoh catatan kimia lama ada di sini: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html
Saya penasaran sistem apa yang digunakan sekarang
Selama beberapa tahun saya melihat APL seperti semacam sihir, lalu awal tahun ini saya menyempatkan diri untuk mempelajarinya
Saya terkejut karena dengan APL kita bisa memasukkan kode yang luar biasa banyak hingga cukup dalam satu tweet
Menarik, tetapi sulit digunakan
Setelah menulisnya, hampir selalu terpikir, “Masa selama ini hanya untuk menulis ini?” lalu saya bertanya-tanya apakah seharusnya memakai alat lain
Namun kenyataannya, agak tidak intuitif bahwa alat lain kemungkinan besar akan memakan waktu jauh lebih lama
Bagian yang terasa sulit dan menyita waktu sebenarnya adalah proses dipaksa merumuskan spesifikasi masalah dengan cara yang lebih ringkas
Mirip seperti mendaki jalur yang lebih curam tetapi jauh lebih pendek, sehingga terasa lebih berat, padahal sebenarnya pekerjaannya lebih sedikit
Karena itu saya merasa harus belajar dan memakai APL
Secara pribadi saya tidak setuju dengan premis makalah bahwa “notasi matematika kurang universal, dan harus ditafsirkan secara berbeda bergantung pada topik, penulis, dan konteks”
Menurut saya, notasi yang terpisah dari visualisasi masalah dan ergonomi memiliki biaya besar
Sebagian akademisi menyukai notasi yang menyembunyikan banyak kompleksitas sehingga bisa memunculkan pencerahan ala “eureka” atau kesetaraan yang tak terduga, tetapi dalam beberapa kasus itu justru kabur dan mudah menimbulkan kesalahan
Meski begitu, notasi memang alat penting untuk menyampaikan proses berpikir
Menurut saya, menetapkan hanya satu notasi standar untuk suatu bidang atau bidang-bidang yang berdekatan cukup menekan aspek kreatif, artistik, dan eksploratif dalam penalaran serta pemecahan masalah
Ada juga penjelasan bagus dari Terry Tao tentang notasi: https://news.ycombinator.com/item?id=23911903
Dalam matematika ada upaya membuat sistem penalaran “enterprise” seperti Lean dan Coq, dan dalam kasus seperti itu sistem notasi universal memang masuk akal
Namun untuk eksplorasi pribadi, mungkin lebih baik memasang apa pun yang cocok
Secara pribadi saya merasa hal ini lebih berat dalam pendidikan
Dalam kelas aljabar dan semacamnya, saya kesulitan ketika pengajar tidak menangani keputusan dan preferensi pribadi soal notasi secara konsisten atau terus terang, dan kemampuan matematika saya meningkat pesat setelah mempelajari teori tipe dan teori pembuktian mekanis
Saya rasa konsep “ketergantungan detail” dalam makalah itu belum digali cukup dalam
Setelah lama membaca dan menulis aplikasi APL, saya menyadari bahwa konsep ini menunjuk pada cara mengelola kompleksitas yang pada dasarnya berbeda dari abstraksi
Kita dikelilingi oleh penghalang abstraksi seperti API, library, modul, paket, dan interface, dan hasilnya adalah masalah-masalah yang sudah akrab: menara abstraksi yang tinggi, developer yang hanya menempelkan API, keterputusan dari hardware, serta sulitnya menalar performa
APL membuat pendekatan lain terasa sangat nyaman
Alih-alih merancang abstraksi, kita merancang data dengan cermat agar mudah dimanipulasi lewat ekspresi sederhana
Biasanya ini berarti menulis operasi primitif secara langsung di tempat yang biasanya diisi fungsi library atau istilah DSL
Misalnya, dengan tabel string, array key, dan array nilai, kita bisa membuat struktur mirip hashmap yang memiliki nilai vektor dan key yang diinternalkan, lalu menangani insert, output, dan delete langsung dengan ekspresi APL
Kelebihan cara ini adalah setiap ekspresi bukan black box, sehingga bisa disesuaikan secara alami untuk kebutuhan tertentu
Jika ini insert hashmap biasa, kita perlu kode untuk menambahkan key baru, tetapi di sini kita memanfaatkan invariant umum bahwa cukup menambahkan nilai ke key yang sudah ada
Kalau memakai API library, kita mungkin membutuhkan jalur kode yang tidak terpakai, beberapa variasi fungsi insert, atau inferensi tipe yang canggih untuk eliminasi dead code
Pendekatan semacam itu membuat concern yang tidak terkait domain merembes ke codebase
Dengan membuat detail menjadi bergantung alih-alih menyembunyikannya, kita bisa mengakses detail spesifik domain sebanyak yang diperlukan, sementara detail yang tidak relevan tetap diam di latar sampai dibutuhkan
Tentu kita harus sangat terbiasa dengan ekspresi APL, tetapi menurut saya bebannya tidak jauh lebih besar daripada mempelajari sesuatu seperti ekosistem Python secara mendalam
Dalam praktiknya, simbol-simbol APL menghilang ke latar, dan mulai terlihat sebagai sintaks bermakna, seperti kita membaca kata-kata bahasa Inggris per kata atau frasa, bukan per huruf
Di sebagian besar bahasa ini mustahil, tetapi jika bahasanya cukup ringkas dan ekspresif, hal itu kembali mungkin dalam cakupan yang cukup besar
Saya selalu teringat bahwa Arthur Whitney benar-benar membenci scrolling
Tidak perlu membuka 20 file dan mengikuti “go to definition” ke mana-mana
Kalau seluruh program muat dalam satu halaman, hal-hal seperti itu hilang, dan kita menavigasi dengan gerakan mata
Saya benar-benar merasa harus meluangkan waktu untuk mempelajarinya
Ini juga sangat berkaitan dengan kesulitan yang saya alami beberapa minggu terakhir
Saya sedang melihat kode Python legacy yang terlalu erat terkopel, dan semua upaya “perbaikan” sebelumnya hanya menambahkan abstraksi di atas model data yang keliru
Dengan membaca kode secara linear, kita tidak bisa tahu metode mana yang mengubah objek input
Ada yang mengubah, ada yang tidak, dan kadang mengembalikan argumen input yang sama persis tanpa perubahan
Daripada lautan jalan memutar berupa factory yang mengembalikan berbagai calculator yang bahkan tidak berbagi interface yang sama, saya lebih memilih magic string yang bisa dianalisis dan dipahami
Karena semua operasinya O(n)
Memang bisa memakai operator umum, tetapi kita tetap harus memahami dengan cermat apa arti pasangan nilai dalam logika domain, dan bagaimana menjaga struktur yang benar di setiap operasi
Orang yang membaca program itu untuk pertama kali akan sama-sama kesulitan memahami makna domain bisnis, bukan operasi primitifnya
Kalau ada perbaikan, menurut saya itu bukan karena kompleksitas diletakkan di tempat lain, melainkan karena kode dan nilai aktual terlihat bersamaan
Yang membuat pemrograman kompleks menjadi lebih mudah adalah data saat runtime dan operasi kode terlihat berdampingan; karena itu tool IDE terus meningkatkan debugger dan inspector untuk menunjukkan apa yang dilakukan program pada setiap tahap
Dalam konteks ini, baik kita mengabstraksikan sebagian operasi maupun sebagian struktur data, membuat abstraksi baru yang baik dan ringkas tetap merupakan hal yang baik
Kode insert pada contoh sebagian besar bukan operasi penambahan yang diinginkan, melainkan perapian data untuk mengubah bentuk yang bisa dimasukkan oleh interpreter menjadi bentuk yang dibutuhkan
⍪←adalah penambahan yang sebenarnya, sedangkan↓⍉↑()()()lebih mirip parsing input dan transformasi untuk mengakali keterbatasan APL dan parser input interpreterKode delete juga harus membuat array Boolean yang tidak terkait dengan ranah masalah, misalnya membungkus
'buggy'agar ditemukan sebagai satu elemen dalam array bersarangPernyataan “membuat hashmap berisi nilai vektor” juga menyesatkan karena sebenarnya tidak ada hashing
Tidak ada pengecekan key duplikat, tidak bisa memilih hash atau menyesuaikan kecepatan dan distribusi, dan karena key ditambahkan berurutan, pencarian juga menjadi lambat
Dyalog APL memang memiliki I-Beam 1500, perintah interpreter ajaib yang menandai array sebagai target hashing internal untuk lookup cepat, tetapi kita harus terus ingat bahwa abstraksi internalnya bocor
Ide-ide bagus dalam desain bahasa dan tool seperti “pit of success”, “hanya ada satu cara”, “cara pertama yang terpikir haruslah cara yang benar”, dan “pekerjaan yang berbeda harus terlihat berbeda” tidak ada di APL
Di Python atau C#, sintaks seperti
kv={'a':1, 'b':2}langsung bekerja, dan jika kurung atau titik dua terlewat, itu tampak jelas salah serta editor dan compiler membantuImplementasi APL bergantung pada fungsi interpreter ajaib seperti
⎕NGET,⎕CSV, dan⎕JSONuntuk input/output, dan penanganan error, logging, serta debugging juga lemahSeluruh ekspresi dieksekusi sebagai satu kesatuan, dan karena hook serta fork, ekspresi juga sulit dipecah
Pada akhirnya, eksperimen dan pembelajaran pun baru mungkin jika kita benar-benar punya intuisi yang tepat tentang berbagai bentuk array, mengapa
⊂3tampak seperti tidak melakukan apa-apa, perbedaan⊆dan⊂, scalar extension, dan seterusnyaBahkan pola yang mestinya langsung dapat diakses seperti “jika key ada, perbarui; jika tidak, tambahkan” di APL membuat kita harus memikirkan ulang dari cara branching-nya
Di Python cukup memakai
if/elsedankey in map, di C# cukupif/elsedanmap.Contains(key), tetapi di APL kita terseret ke dalam pemikiran untuk mengimplementasikan ulang fitur dasarIni mirip dengan klaim Aaron Hsu, tetapi rasanya seperti Up-Goer 5 atau Toki Pona, ketika kita tidak boleh mengatakan “mobil pemadam kebakaran” dan harus mengatakan “mobil milik orang yang melakukan pekerjaan menghentikan api”
[1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
[3] https://aplwiki.com/wiki/Scalar_extension
[4] https://xkcd.com/1133/