📚 Topik — Type Systems: static vs dynamic, soundness, dan dampaknya ke bug produksi

Sesi: Deep Learning 05:00 · Level: intermediate–advanced · Kategori: CS Fundamentals

🎯 Tujuan Belajar

Setelah sesi ini, keputusan berikut jadi lebih baik:

1. Memilih bahasa/tipe strategi per komponen (bukan per proyek): di mana type checker memberi leverage, di mana ia hanya menambah gesekan.
2. Menilai klaim "types prevent bugs" secara kuantitatif, bukan slogan.
3. Tahu persis lubang di type system yang dipakai (TS any, as, erasure, bivariance) dan menutupnya dengan boundary validation — bukan dengan harapan.
4. Merancang migrasi bertahap dari untyped → typed (JS→TS, Python→mypy) tanpa big-bang rewrite.

🧠 Penjelasan Inti

Static vs dynamic = KAPAN tipe diperiksa, bukan SEBERAPA KETAT.

Dua sumbu berbeda, sering dicampur:

Kenapa ada type system? Type = bukti parsial tentang bentuk data yang dijamin compiler, sehingga error kelas tertentu tidak bisa lolos ke runtime. Nilainya bukan "mencegah semua bug" — nilainya menggeser deteksi bug dari produksi ke editor, dengan biaya: anotasi, kompilasi, dan menolak program yang sebenarnya valid.

Soundness didefinisikan formal lewat dua teorema: progress (program well-typed tidak macet) + preservation (tipe tetap valid setelah step evaluasi). Konsekuensi praktis: soundness adalah properti all-or-nothing. Satu lubang (unsafe, any, downcast tanpa check) menghapus jaminan global untuk jalur yang melewatinya. Type system yang "99% sound" secara matematis sama dengan tidak sound — hanya secara statistik lebih baik.

Angka, bukan retorika (DIKETAHUI): - Gao, Bird, Barr (2017), To Type or Not to Type: Quantifying Detectable Bugs in JavaScript — menganalisis bug nyata di repo GitHub publik: ~15% bug dapat dideteksi Flow/TypeScript (subset yang bisa di-encode statis). Sisa 85% = logika, spesifikasi, state, integrasi. - Hanenberg (2010), eksperimen 49 subjek, task parser, 27 jam — type statis tidak mempercepat; pada beberapa task justru lebih lambat. Sampel kecil, task tunggal → jangan digeneralisasi; intinya: klaim "types = 2x velocity" tanpa bukti. - Takikawa et al. (2016), Is Sound Gradual Typing Dead? — sound gradual typing (Reticulated Python) bisa menambah overhead runtime hingga ~100%+ pada worst case, terutama untuk boundary checks di kode yang sering dipanggil lintas typed/untyped. Inferensi: inilah alasan praktis kenapa TS memilih unsound-by-design (Design Goal non-goal resmi TS: "apply a sound or provably correct type system" — ditolak demi produktivitas).

⚙️ Cara Kerja Internal

1. Static checking pipeline. Parse → build symbol table → inference (Hindley–Milner untuk ML/Haskell; bidirectional checking untuk TS/Kotlin/Swift) → constraint solving → error report. Yang penting: inferensi bekerja lokal per expression, jadi tipe fungsi lintas modul harus eksplisit atau di-infer dari semua call site (TS butuh deklarasi .d.ts, Go tanpa generics lama butuh duplikasi).

2. Erasure. TS, Java (generics), Python typing, Kotlin → tipe hilang setelah compile/bytecode. Runtime tidak tahu tipe generik. Konsekuensi: List<String> dan List<Int> sama saat runtime (JVM type erasure), JSON.parse() hasilnya any walau kamu tulis as User.

3. Variance — sumber unsoundness klasik.

Java:  String[] IS-A Object[]        (covariant, unsound)
       Object[] a = new String[1];
       a[0] = 42;   // compile OK, runtime ArrayStoreException
TS:    method params bivariant (kecuali strictFunctionTypes utk function props)
Rust:  &'a T covariant, &mut T invariant, fn(T) contravariant
Kotlin: out T covariant, in T contravariant, deklarasi-site

4. Structural vs nominal. TS structural (bebek: bentuk cocok = cocok) → mudah komposisi, tapi mudah juga "kebetulan cocok" (dua tipe berbeda bentuk identik saling tertukar, misal UserId vs OrderId keduanya string). Nominal (Java/Rust/C#) butuh explicit implement → aman, tapi lebih kaku. Solusi TS: branded/opaque type:

type UserId = string & { readonly __brand: 'UserId' }

5. Nullability sebagai bagian type system. strictNullChecks/Kotlin T?/Rust Option<T> memindahkan null dari "nilai ajaib di semua tipe" ke "tipe eksplisit yang harus di-destructure". Ini satu perubahan dengan ROI bug tertinggi di migrasi TS (Tony Hoare: null = "billion dollar mistake").

6. Making illegal states unrepresentable. Bukan soal anotasi, soal desain tipe:

// jelek: 4 state valid dari 8 kombinasi
type Req = { loading: boolean; data?: User; error?: string }
// baik: 3 state, exhaustive via switch → compiler paksa handle semua
type Req =
  | { s: 'idle' }
  | { s: 'ok'; data: User }
  | { s: 'err'; error: string }

Discriminated union + exhaustive check = bug "lupa handle error state" jadi compile error, bukan incident.

🏗️ Diagram — boundary model (pola yang dipakai di produksi)

  [ wire: JSON / DB row / HTTP header ]     ← UNTYPED, adversarial
              │
       parse & validate        ← zod / io-ts / pydantic / serde
              │                    (satu-satunya tempat runtime check)
              ▼
  [ domain type: User, Money, UserId ]      ← TRUSTED, typed, invariant dijaga
              │
        pure business logic                 ← no re-validation, no `any`
              ▼
  serialize (type-driven encoder)

Aturan: tipe hanya bernilai kalau ada satu titik di mana data tak bertipe dipaksa jadi bertipe lewat validasi runtime. Tanpa itu, anotasi cuma komentar yang tidak bisa dibaca manusia lain.

⚖️ Trade-off & Kapan JANGAN Dipakai

Kapan JANGAN pakai type statis ketat: - Spike/prototipe < 1 hari yang akan dibuang. Anotasi = biaya tanpa payoff. - EDA / data shape belum diketahui — pandas/polars tanpa schema; paksa tipe di sini = menebak tipe bisnis yang belum ada. - Plugin system / DSL / interpreter di mana "tipe" baru muncul saat runtime dari config user → butuh validasi runtime, bukan type system. - Hot path yang di-benchmark dengan sound gradual typing overhead — lebih baik untyped core + typed edge. - Tim kecil tanpa tooling disiplin: TS dengan strict: false + any di mana-mana = lebih buruk dari JS, karena memberi rasa aman palsu.

Kapan WAJIB pakai (jangan ditawar): - Kontrak lintas tim/service (API schema, event schema) — protobuf, OpenAPI, zod schema. - Uang, tanggal/waktu, ID entitas — branded types mencegah OrderId ↔ UserId tertukar. - State machine domain (order lifecycle, payment status) — sum types + exhaustive check. - Kode yang bertahan > 6 bulan dan dipegang > 1 orang.

🏭 Contoh Produksi & Failure Mode

1. as sebagai kebohongan. const user = await res.json() as User — compile bersih, user.address.city → TypeError: Cannot read properties of undefined di produksi. TS tidak memvalidasi runtime; as hanya mematikan compiler. Fix: userSchema.parse(await res.json()).

2. API drift tanpa kontrak. Backend rename user_name → username; TS interface manual tidak ikut berubah. Tidak ada compile error karena tidak ada shared schema. Fix: codegen dari OpenAPI/protobuf/GraphQL, atau satu package schema bersama.

3. Generics erasure menelan bug. Java: List<Order> di-cast ke List lalu isi String; error muncul jauh dari sumber. Fix: jangan raw type, gunakan Class<T> token untuk validasi runtime bila perlu.

4. Type-unsoundness tersembunyi di library. Java array covariance, TS method bivariance (callback (e: MouseEvent) => void lolos sebagai (e: Event) => void). Bug hanya muncul saat event yang salah dikirim.

5. any menyebar seperti wabah. Satu any di boundary → semua konsumennya kehilangan tipe. ESLint no-explicit-any, no-unsafe-* di typescript-eslint jadi kontrol wajib.

6. Python: mypy hijau, runtime meledak. def f(x: int) dipanggil dengan "3" dari kode yang tidak di-type-check (dependency tanpa stub, atau # type: ignore). Fix: disallow_untyped_defs, warn_unused_ignores, cek di CI semua modul.

7. Schema drift DB ↔ ORM. Kolom nullable di DB, non-null di model → crash saat data lama masuk. Type system tidak tahu DB constraint. Fix: generate tipe dari schema DB (prisma, sqlc, pgschema), satu sumber kebenaran.

⚠️ Miskonsepsi Umum

• ❌ "Static typing = aman." → TS unsound; Java punya null + array covariance. Soundness ≠ static.
• ❌ "Dynamic typing = tidak ada tipe." → Ada, hanya diperiksa runtime; dan banyak bahasa dinamis punya gradual typing (Python annotations, Ruby Sorbet, JS + JSDoc).
• ❌ "Strong = static." → Python strong + dynamic. C weak + static.
• ❌ "Types membuat kode lebih cepat." → Runtime perf datang dari optimisasi (JIT inline cache, monomorphization), tidak otomatis dari anotasi. V8 bisa mengalahkan Java di beberapa workload; sebaliknya type instability bikin deopt.
• ❌ "Type coverage 100% = bebas bug." → 85% bug JS di studi Gao bukan type-detectable. Type menutup satu kelas, bukan semuanya.
• ❌ "Generics lebih banyak = lebih baik." → Generic gymnastics (HKT emulation di TS, infer berlapis) menurunkan readability tanpa payoff proporsional. Kalau butuh 40 baris tipe untuk satu fungsi, tipe itu sendiri jadi bug source.
• ❌ "Migrasi harus big-bang rewrite." → Selalu inkremental; allowJs + checkJs + strict flag bertahap per folder.

✅ Cek Pemahaman

1. TS menolak let x: string = null dengan strictNullChecks, tapi menerima (obj as any).field dan menerima method param bivariance. Mana dari keduanya yang melanggar soundness, dan mengapa strictNullChecks tidak membuat TS sound?

2. Kamu punya service Go (typed) yang memanggil service Python (untyped, tanpa stub). Di titik mana type-safety hilang, dan kontrol apa yang harus dipasang agar boundary itu aman?

3. Tim mau adopsi TS pada codebase JS 80k LOC. Urutkan langkah migrasi dan jelaskan mengapa strict: true sejak commit pertama adalah pilihan buruk, sementara any sebagai strategi permanen juga buruk.

🔑 Poin Kunci

• Static/dynamic = waktu cek; strong/weak = coercion; soundness = jaminan formal — tiga hal berbeda, jangan dicampur.
• Nilai type system bersifat statistik + lokal: menangkap subset bug lebih awal, bukan menjamin kebenaran.
• Erasure berarti semua data dari luar (HTTP, DB, queue, env) tetap butuh validasi runtime. Parse di boundary, tipe di dalam.
• Unsoundness punya titik masuk spesifik: any, as, raw type, covariance, null, unsafe. Audit titik itu, bukan seluruh kode.
• Trade-off asli: anotasi + compile time + rigiditas vs test suite besar + bug produksi + refactor berisiko.
• Desain tipe > banyak tipe. Sum type + exhaustive check mengubah kelas bug jadi compile error.
• Migrasi selalu inkremental, dengan ratchet (strict bertambah, any melarang) — bukan big-bang, bukan status quo permanen.

➡️ Eksplorasi Lanjut

• Refinement types (Liquid Haskell) & dependent types (Idris 2, Lean 4) — encode invariant {v: Int | v > 0} di tipe. Frontier; biaya proof burden tinggi.
• Linear/affine types — Rust ownership: memory safety tanpa GC. Bandingkan dengan GC (throughput vs latency vs determinisme).
• Effect systems — Koka, OCaml 5 effects: track side effect di tipe, bukan di dokumentasi.
• Gradual typing di Python — mypy strict, pyright, beartype untuk runtime enforcement; bandingkan overhead.
• Schema-first stack — protobuf/Buf, OpenAPI → codegen, sqlc/Prisma: hilangkan interface manual sepenuhnya.
• Bacaan inti: Pierce Types and Programming Languages (ch. 1–9 untuk soundness), Cardelli "Type Systems" (ACM CSUR 1996), Gao et al. 2017, Takikawa et al. 2016.