Flix – Bahasa Pemrograman Berorientasi Efek yang Kuat

 (flix.dev)
2 poin oleh GN⁺ 2025-07-11 | 1 komentar | Bagikan ke WhatsApp
  • Flix adalah bahasa inovatif yang menggabungkan pemrograman fungsional dengan model berorientasi efek
  • Bahasa ini memudahkan pemodelan aturan logika dan ketergantungan data, serta unggul dalam representasi pengetahuan secara deklaratif
  • Relasi dependensi yang kompleks dan alur proses dapat ditulis secara ringkas dalam bentuk kode
  • Pendekatan ini memberikan efisiensi untuk pekerjaan perancangan algoritme dan penalaran
  • Melalui fitur kueri, data berbasis pengetahuan dapat dijelajahi dengan mudah

Gambaran Umum Bahasa Flix

  • Flix adalah bahasa fungsional baru yang memperkenalkan paradigma pemrograman berorientasi efek
  • Programmer dapat mendeskripsikan sistem bukan dengan kode prosedural, melainkan berpusat pada relasi dan aturan logis
  • Dengan aturan logika (dideklarasikan di dalam #{}), skenario manufaktur yang kompleks seperti komponen, dependensi, waktu perakitan, dan tanggal pengiriman dapat dinyatakan secara ringkas

Aturan Deklaratif dan Pemodelan Data

  • Dalam contoh kode, digunakan fakta dan aturan seperti PartDepends, AssemblyTime, DeliveryDate, ReadyDate
    • Mendefinisikan relasi dependensi antarproduk seperti PartDepends("Car", "Chassis")
    • Menetapkan waktu perakitan per komponen seperti AssemblyTime("Engine", 2)
    • Juga mencantumkan tanggal pengiriman komponen seperti DeliveryDate("Piston"; 1)
  • Melalui aturan logika bernama ReadyDate, tanggal kesiapan akhir untuk komponen dengan tanggal pengiriman yang telah ditentukan maupun komponen rakitan dapat dihitung
  • Dengan kata lain, siklus pasokan dan perakitan tiap komponen dapat diinferensikan secara sederhana

Penalaran Berorientasi Efek dan Kueri

  • Mesin aturan logika Flix menggabungkan orientasi efek dan transparansi referensial, sehingga mendorong perancangan program yang intuitif sekaligus minim kesalahan
  • Dengan sintaks kueri, tanggal kesiapan semua komponen yang termasuk dalam ReadyDate dapat diperoleh dengan mudah
  • Pendekatan ini dapat diterapkan di berbagai bidang seperti manufaktur, manajemen rantai pasok, dan otomatisasi berbasis penalaran

Ringkasan dan Keunggulan

  • Flix menggabungkan Effects dan penalaran berbasis aturan logika untuk memodelkan secara ringkas hubungan antara komponen dan proses dalam sistem yang kompleks
  • Dibandingkan bahasa yang sudah ada, Flix memiliki keunggulan yang berbeda dalam hal kejelasan logis dan keringkasan kode
  • Bahasa ini berpotensi menawarkan solusi yang cocok untuk berbagai masalah perangkat lunak modern seperti knowledge graph, workflow engine, dan inferensi data

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-11
Komentar Hacker News

  • Saya sangat terkesan dengan kedalaman dan keluasan bahasa ini
    Tipe data aljabar, pemrograman logika, varians, dan fitur-fitur esensial lainnya semuanya sudah tersedia sejak awal
    Dari tabel perbandingannya, bagian yang paling saya sukai adalah satu executable tunggal yang sekaligus berperan sebagai package manager, LSP, dan compiler
    Dalam kasus Haskell, LSP harus mengimplementasikan ulang banyak hal di antara ghc dan file cabal, dan juga ada stack, jadi status resmi package manager-nya agak ambigu
    Bukan bermaksud mengkritik Haskell; itu benar-benar bahasa yang luar biasa
    Hanya saja agak disayangkan karena fitur-fitur terbaiknya terasa sedikit tersembunyi
    Saya penasaran seberapa nyaman Flix terintegrasi dengan Java dan lainnya di atas JVM
    Karena compiler JVM menghapus sebagian besar informasi tipe, konsep regions di Flix yang mendukung interaksi imperatif sebagai warga kelas satu terasa positif
    Menggunakan JVM juga merupakan keunggulan besar karena kita bisa dengan mudah memanfaatkan standard library berkualitas tinggi bernilai miliaran dolar
    Karena itu, saya pikir JVM atau .NET Core adalah pilihan paling masuk akal untuk lebih dari 90% proyek
    F# tampak sebagai satu-satunya bahasa pembanding yang relevan
    Akan sangat bagus jika ada dokumen yang merangkum keterbatasan interoperabilitas antara Flix dan JVM
    Sebagai referensi, ada informasi terkait di sini
    Pada dasarnya, nilai Flix/Java melewati proses boxing/unboxing
    Selain itu, Record juga merupakan warga kelas satu

    • Jika Anda menyukai gagasan bahwa package manager, LSP, dan compiler semuanya adalah satu executable, Anda mungkin juga akan sangat menyukai Unison

    • Bagian pemrograman logika dan datalog terasa agak seperti tambahan
      Fitur-fitur lainnya jelas terlihat meningkatkan type safety codebase, tetapi pemrograman logika terasa seperti fitur yang cukup niche, jadi mungkin lebih baik jika berada terpisah dari bahasanya sendiri

    • Pernyataan bahwa compiler JVM menghapus semua informasi tipe tidak sepenuhnya benar (dalam kasus kelas anonim, parameter tipe tetap dipertahankan)
      Ada juga berbagai jalan memutar
      Dan sebenarnya, dari sudut pandang compiler, ini bukan masalah besar
      Cukup acak nama kelas yang telah menerapkan type constructor dan render seperti kelas biasa

    • F# (masih) tidak mendukung type class, jadi ada banyak keterbatasan pada pemrograman berbasis monad
      Jika F# melompati monad gaya Haskell dan langsung menuju algebraic effects, menurut saya itu akan lebih cocok dengan filosofi F#

    • Bagian StringBuilder agak disayangkan
      Dalam hal ini rasanya sedikit terlalu condong ke sisi Java, jadi saya belum yakin
      Selain itu, sekilas bagian lainnya tampak cukup bagus

  • Dari sisi semantik bahasa, semantik perluasan/pembatasan record polimorfik tampaknya mengikuti pendekatan scoped label milik Leijen (tautan makalah)
    Misalnya jika ada record r1 = { color = "yellow" }, kita bisa memperluasnya menjadi r2 = { +color = "red" | r1 }
    r2#color akan menghasilkan "red", lalu jika field "color" dihapus lagi menjadi r3 = { -color | r2 }
    r3#color akan kembali menghasilkan nilai asli "yellow"
    Menurut saya ini jauh lebih masuk akal daripada gaya sebelumnya, yang mengarah pada sistem tipe yang sangat rumit hanya agar field dengan label yang sama tidak bisa ditambahkan dua kali

  • Saya penasaran mengapa Aarhus (terutama universitas/tech hub-nya) punya pengaruh kuat dalam riset bahasa pemrograman
    C++, C#/Typescript, Dart, dan lainnya semuanya memiliki akar kuat di wilayah kecil Denmark ini
    Tempat ini bukan universitas elite khas seperti Ivy League atau Oxbridge, juga bukan seperti Delft atau INRIA
    Apa yang membuatnya begitu istimewa? Sekadar penasaran apakah airnya yang spesial, atau ada alasan lain

    • Satu hal yang perlu dicatat, C# dibuat oleh Anders Hejlsberg, dan dia belajar di DTU (Kopenhagen)
      Turbo Pascal juga dibuat olehnya, dan Borland adalah perusahaan yang didirikan oleh orang Denmark
      Secara umum, Denmark memang kuat dalam teori bahasa pemrograman
      Misalnya, buku teks pascasarjana standar di bidang analisis program statis (oleh Nielson & Nielson) juga berasal dari Denmark
      Mads Tofte memberi kontribusi besar pada Standard ML
      Aarhus memang bukan sekelas Ivy League atau Oxbridge, tetapi tetap universitas yang hebat
      Di Eropa ada puluhan universitas seperti ini: namanya mungkin tidak terlalu besar, tetapi kualitas pendidikan dan penelitiannya sangat tinggi

    • Aarhus punya tradisi kuat dalam logika, type theory, dan bahasa fungsional/berorientasi objek
      Banyak peneliti berpengaruh di bidang ini berasal dari Aarhus
      Selain itu, riset bahasa pemrograman terasa sangat bias ke AS di tingkat global
      Institusi seperti Aarhus cenderung jauh lebih hemat dalam pemasaran atau self-promotion, dan lebih fokus pada riset yang baik
      Bukan berarti lebih baik atau lebih buruk secara khusus, tetapi itu membuatnya lebih sulit mendapat sorotan global

  • Flix terus mengesankan saya sebagai bahasa yang paling dirancang dengan cermat di antara keluarga bahasa ML
    Kombinasi paradigma fungsional, imperatif, dan logika, plus dukungan warga kelas satu untuk sistem tipe & efek polimorfik serta constraint Datalog, benar-benar unik
    Pemisahan ketat antara kode murni/tidak murni pada level tipe terasa segar sebagai alternatif yang lebih mudah untuk inferensi efek dibanding Monad
    Filosofi "satu bahasa, tanpa perlu flag" dan hanya mengejar error saat compile time juga terasa sederhana dan bisa diprediksi
    Bahwa Flix berhasil mengimplementasikan penghapusan tail call penuh meski JVM sendiri tidak mendukung tail recursion elimination secara native adalah pencapaian teknis yang patut diperhatikan
    Saya penasaran dengan pengalaman orang-orang yang benar-benar memakai Flix di lingkungan produksi atau riset
    Khususnya, saya ingin mendengar kesulitan yang mereka alami saat memakainya untuk pemrograman logika atau konkurensi, seperti terkait closed-world assumption atau tidak adanya dukungan exception, serta perbedaan integrasi Datalog dibanding bahasa logika lain seperti Prolog

  • Saat dulu saya melihat Flix, saya merasa ini sangat menarik sampai saya menulis artikel berjudul "Flix untuk programmer Java"
    Sekarang memang sudah agak lama dan perlu diperbarui, tetapi...
    Kalau tertarik, bisa dilihat di sini

    • Tulisan blognya benar-benar keren
      Kalau diizinkan, akan bagus kalau itu ditambahkan ke kumpulan blog resmi Flix (tautan)
      Sejak tulisan itu, bahasa Flix sudah berkembang pesat
      Terutama sistem efeknya telah diperluas besar-besaran, interoperabilitas Java ditingkatkan, dan ada pembaruan sintaks

    • Blog itu terasa seperti harta karun
      Rasanya seperti versi yang lebih matang dari pemikiran-pemikiran yang sudah lama mengganggu saya
      Saya antusias membayangkan membaca semuanya

  • Keren juga karena mendukung HKT
    Tapi saya tidak melihat penjelasan tentang typeclass, jadi saya penasaran
    Kalau mendukung typeclass dan macro gaya Scala, saya ingin mencoba memindahkan library yang saya buat (distage, izumi-reflect, BIO) ke Flix dan mungkin serius mempertimbangkan berpindah dari Scala ke Flix
    Belakangan saya menemukan bahwa typeclass di sana disebut trait
    Saya juga penasaran bagaimana dengan macro
    Selain itu, agak disayangkan Flix juga tidak mendukung nominal inheritance eksplisit
    Jadi bahkan bentuk trait Scala yang paling tidak berbahaya pun tidak diizinkan
    Menurut saya, typeclass tidak bisa menggantikan interface, dan tanpa abstraksi itu banyak fitur berguna yang sama sekali tidak bisa diimplementasikan, atau hasil kodenya bisa jadi jelek dilihat

    • Flix mendukung typeclass (di sini disebut trait) bersama HKT, associated type, dan associated effect
      Trait juga bisa menyediakan implementasi fungsi default, tetapi dapat dioverride di instance
      Flix sama sekali tidak memiliki inheritance
      Trait hanya digunakan pada waktu kompilasi dan diproses melalui monomorphization, jadi tidak ada overhead runtime
      Inliner Flix juga mengoptimalkan bagian dalam trait, sampai secara agresif menghapus closure
      Misalnya, fungsi orde tinggi atau pipeline bisa berubah menjadi loop biasa di level bytecode, tanpa alokasi closure atau indirection sama sekali
      Flix masih belum mendukung macro
      Tampaknya mereka takut memperkenalkannya karena pengalaman (penyalahgunaan) di bahasa lain
      Mereka sedang mencari penulis library baru, jadi kalau tertarik, akan bagus jika mampir ke kanal Gitter

  • Terkait bagian "fitur yang tidak didukung Flix" di dokumentasi resmi Flix
    Ada item bernama "No Code Before Main"
    Namun penjelasan sebenarnya berbunyi "Flix tidak menjalankan kode apa pun sebelum main dan sama sekali tidak punya static initializer"
    Menurut saya nama fiturnya akan lebih akurat jika diubah menjadi "Code Before Main"

  • Saya penasaran mengapa Flix mengharuskan fungsi secara eksplisit ditandai sebagai murni
    Rasanya dalam hampir semua kasus ini bisa diinferensikan cukup lewat analisis statis, jadi saya ingin tahu alasannya

    • Setahu saya, jika Anda menandai sebuah fungsi sebagai murni, compiler akan menjaminnya

    • Jika melihat kalimat "Flix secara akurat melacak kemurnian setiap ekspresi dalam program" dan contoh definisi fungsi tanpa penanda murni/tidak murni
      tampaknya compiler memang mampu menginferensikan kemurnian secara otomatis dalam sebagian besar kasus
      Jadi saya mendapat kesan bahwa penanda murni/tidak murni mungkin bersifat opsional

  • FAQ Flix (tautan) mulai dengan biasa saja lalu makin lama makin lucu
    Beberapa contoh yang mengundang tawa:

    • T: Jika dibagi dengan 0, apakah hasil yang sebenarnya memang 0?<br> J: Ya. Tapi hanya memedulikan bagian itu sama seperti hanya mempermasalahkan warna kursi di pesawat luar angkasa
    • T: "Situs ini butuh JavaScript"<br> J: Orang-orang yang mengkritik penggunaan JavaScript: [1],[2],[3],[4],[5], orang yang benar-benar menawarkan bantuan untuk merefaktornya ke HTML: 0
    • T: Saya kecewa karena fitur X dimasukkan, bukan fitur Y yang saya sukai<br> J: Turut prihatin
    • T: Ini sintaks terburuk dari semua bahasa fungsional yang pernah saya lihat. Titik koma, kurung kurawal, dan kekacauan simbol bercampur jadi satu. Rasanya seperti Scala, Java, dan Haskell melakukan one-night stand di tengah Chernobyl<br> J: Bukankah itu justru pencapaian yang luar biasa?

  • Saya penasaran apakah code agent yang kompatibel dengan bahasa ini bekerja dengan baik, atau kita tetap harus benar-benar berpikir sendiri
    Saya mengatakannya setengah bercanda, tetapi sebenarnya saya sedih karena bahasanya terlihat keren
    Jika LLM justru menghambat adopsi bahasa baru, saya penasaran bagaimana masalah ini akan dipecahkan

    • Saya justru punya firasat bahwa LLM akan menurunkan hambatan adopsi bahasa baru
      Kode standard library sudah cukup bagi LLM untuk mempelajari sintaks baru, dan kalaupun tidak, agent bisa belajar dengan mengamati output compiler
      Pekerjaan porting kode sendiri bukanlah hal yang butuh kreativitas tinggi; itu pekerjaan yang definisinya jelas, jadi akan menjadi salah satu area otomatisasi pertama bagi LLM
      Ke depan, menurut saya kita justru perlu serius memakai otak kita untuk memikirkan 'mengapa kita melakukan ini' dan 'dampak apa yang ditimbulkannya pada dunia'

    • Saya mendapat hasil yang lumayan dengan menulis di prompt agar wajib memakai indexed/dependent types milik Idris
      (tanpa instruksi seperti itu, biasanya mentok di level GADT)