- "Pemrograman fungsional (FP) sulit dipelajari, tetapi akan membuat kode Anda menghasilkan lebih sedikit kejutan yang tidak menyenangkan"
- Dalam FP, "less is more"
- Menyelesaikan masalah Null Reference (dengan Maybe/Option)
- FP memiliki kurva pembelajaran yang curam
- Masa depan FP
- Jika ingin membangun lebih banyak dengan jumlah pengembang yang lebih sedikit, kita harus menggunakan setiap alat yang tersedia, dan FP adalah tiket untuk itu
- Perusahaan seperti kami yang tidak terlalu glamor kesulitan merekrut pengembang. Namun, menjadi mungkin untuk merekrut pengembang papan atas yang ingin bekerja pada codebase FP
- Mengadopsi FP akan meningkatkan kualitas dan ketangguhan, serta mengurangi waktu yang dihabiskan untuk bug yang tidak muncul dalam FP
- Fakta bahwa fitur-fitur FP mulai semakin sering terlihat di bahasa-bahasa arus utama menunjukkan bahwa industri perangkat lunak sedang bersiap untuk pergeseran paradigma
- Masih banyak pekerjaan yang diperlukan sampai industri sepenuhnya beralih, tetapi karena manfaat melakukannya begitu jelas, tidak ada keraguan tentang ke mana arahnya
13 komentar
Sepertinya benar bahwa kurva belajarnya tinggi. Bahkan di komentar juga ada isi yang menunjukkan bahwa penulisnya benar-benar belum sepenuhnya memahami pemrograman fungsional. Tentu ada juga komentar yang ditulis oleh orang yang memang paham. Pemrograman fungsional itu sulit. Saya juga masih terus belajar, huhuhu
Baru ketika muncul kasus di mana bahasa pemrograman tidak lagi menjadi soal selera tim pengembang, melainkan soal kelangsungan hidup perusahaan, barulah kita bisa membicarakan lagi perlunya FP.
Saya akan merangkum. Dalam manajemen memori dan beberapa algoritme, pemrograman fungsional masih belum melampaui pemrograman berorientasi objek. Gunakan secara tepat sesuai situasi dan biayanya.
Hmm.. saya kurang setuju dengan klaim bahwa kurva belajarnya curam.
Pertama-tama, ini просто mudah, ruang untuk melakukan kesalahan berkurang, dan karena itu produktivitas meningkat.
Kalau begitu saja sudah cukup, kan
Sulit untuk memformulasikan pemikiran dan pekerjaan manusia secara sempurna seperti bahasa pemrograman fungsional murni. Kalau melihat hal seperti free monad, rasanya batas maksimal yang masih bisa diterima cuma sampai sekitar
rxjs. Dalam FP juga ada saatnya ongkosnya jadi lebih besar daripada manfaatnya.
Bahkan efek FP yang sudah ada pada dasarnya cuma sebatas memisahkan data dan metode,
dan kalau melihat betapa
Optionalternyata tidak terlalu banyak dipakai, abstraksi tipe itu adalah abstraksi yang tidak perlu (produktivitas malah banyak terkikis karena harus mencocokkan tipe).Kecuali arahnya mengabstraksikan data dan operasi lebih jauh seperti closure, ada batasnya dalam memanfaatkan bahasa yang sudah ada
Imutabilitas hanyalah alat yang sering digunakan dalam paradigma pemrograman fungsional.
Setahu saya, paradigma pemrograman fungsional adalah paradigma pemrograman yang berupaya mengendalikan "efek samping" (side effect) semaksimal mungkin.
Karena berusaha mengendalikan efek samping, secara alami paradigma ini menekankan hal-hal seperti transparansi referensial, imutabilitas, dan fungsi murni.
Dari sudut pandang itu, saya rasa meskipun tidak menggunakan bahasa pemrograman fungsional, tetap ideal jika kita memahami dengan jelas efek samping dari fungsi atau metode yang kita tulis dan dapat mengendalikannya dengan tepat. Ini punya banyak kelebihan, seperti mengurangi bau kode (
code smell) dalam kode dan mempermudah penulisan unit test.Ada juga tulisan terjemahan yang menjelaskan hal ini dengan lebih rinci.
Dari perspektif seperti ini, ada buku yang berfokus pada refaktorisasi untuk meminimalkan efek samping, yaitu Functional Thinking: Mengendalikan software kompleks dengan kode sederhana. Karena pendekatannya lebih praktis dan berorientasi kerja nyata daripada teoretis, buku ini cukup layak dibaca dan dipelajari bagi siapa pun yang ingin menulis kode yang baik. Menurut saya, bahkan jika setelah membacanya Anda hanya menjadi jauh lebih sadar terhadap efek samping saat menulis kode dibanding sebelumnya, buku ini sudah sangat sepadan dengan harganya.
Terima kasih, sepertinya saya harus mencarinya lalu membacanya.
Ah! Ternyata buku terjemahannya sudah terbit! Saya harus membacanya!
Terima kasih atas rekomendasi bukunya!! Saya akan langsung membelinya dan membacanya!
Buku itu benar-benar bagus!
Dari sudut pandang refactoring, ini juga sangat nyaman untuk ditulis.
Tentu saya juga berpikir pemrograman fungsional adalah pendekatan yang baik, tetapi tampaknya tidak banyak orang yang bisa menyampaikan kelebihannya dengan cara yang meyakinkan. Kalau cuma dibilang bagus, rasanya memang kurang terasa, kan?
Berikut ini pendapat pribadi saya: karena semua program modern pada dasarnya dibangun di atas mesin Turing, secara abstrak besar ia bisa dibagi menjadi fungsi dan data, sehingga menurut saya pemrograman prosedural pun pada akarnya adalah fungsional. Kalau begitu, apa keunggulan nyata pendekatan fungsional dibanding prosedural? Menurut saya, itu sesederhana "tidak menggunakan variabel global atau area yang setara dengannya". Keunggulan ini membuatnya efisien juga untuk "isolasi antar fungsi" dan "komputasi multithread".
Namun, apakah ini keuntungan yang hanya bisa didapat dari pemrograman fungsional? Tidak juga. Dalam bahasa prosedural pun, isolasi pada tingkat kelas dan fungsi dianjurkan melalui konsep dependency injection (dan semua framework modern pada dasarnya sudah mengadopsinya), sementara dalam bahasa Rust, pembatasan pada level bahasa dibuat agar bisa mengejar komputasi konkurensi yang nyaman.
Singkatnya, bahasa fungsional adalah bahasa dan metodologi yang baik, tetapi alih-alih "lebih unggul dalam makna evolusioner", saya menganggapnya seperti bahasa Go atau Rust: bahasa yang "berusaha menyingkirkan kemungkinan gagal pada level bahasa", namun sulit digunakan.
Apakah maksud Anda bahwa hal seperti komposisi fungsi juga bisa dilakukan dalam bahasa prosedural?
Jika definisi "komposisi fungsi" dipersempit, kita bisa saja mengira itu hanya mungkin dalam bahasa fungsional. Tetapi jika dipikir-pikir, eksekusinya toh tetap berjalan di atas bahasa mesin atau assembly yang merupakan bahasa prosedural. Artinya, ini bukan persoalan "bisa atau tidak bisa", melainkan persoalan "fokus bahasa, selera, dan filosofi". Jika definisi "komposisi fungsi" diperluas, bukan sebagai "fitur tertentu dari bahasa tertentu" melainkan sebagai "komposisi antar fungsi logis", maka hal itu sangat mungkin dilakukan. Dan karena kelebihan bahasa fungsional memang jelas ada, lahirlah hal-hal seperti rxjs atau spark yang secara aktif mengadopsi pendekatan tersebut.
Seperti yang kita semua pelajari di jurusan komputer, contoh di bawah menghasilkan hasil yang sama, hanya bentuk ekspresinya saja yang berbeda. Dan notasi prefix sering disebut sebagai gaya fungsional.
Notasi prefix : + 1 1
Notasi infix : 1 + 1
Notasi postfix : 1 1 +