Selamat siang Baru-baru ini, saya sangat sering mendengar bahwa matahari terbenam di PLO telah tiba. Saat ini, semakin banyak orang yang bergerak ke paradigma fungsional. Segera, orang yang menulis dalam C ++ / C # / Java tidak akan ditinggalkan sama sekali. Benarkah begitu? Saya kira tidak. Menurut pendapat saya, penggunaan FP (pemrograman fungsional) yang tidak bijaksana dapat menjadi menyita waktu dan sakit kepala tambahan, yang sepenuhnya tidak sesuai dengan keputusan desain saat ini. Mari kita pastikan!
Saya ingin mencatat: ini bukan tentang ekspresi lambda di Java / Python, tetapi tentang FP yang lebih maju seperti Haskell atau Scala dengan kucing / scalaz.
Jadi, saya menegaskan bahwa:
- AF jauh dari berlaku di mana-mana.
- Ini membawa sakit kepala ketika terintegrasi dengan solusi yang sudah jadi.
- Menghabiskan waktu untuk AF tidak selalu bijaksana.
Kami akan menganalisis poin-poin ini secara lebih rinci dan mengevaluasi skala tragedi tersebut.
1. AF jauh dari berlaku di mana-mana
Ini tampaknya mengejutkan, tetapi tidak semua orang mengerti hal ini. Terlebih lagi, bahasa seperti C sangat jauh dari matahari terbenam. Jauh lebih jauh dari Haskell atau Scala. Lihatlah mesin permainan apa pun. Dengan probabilitas 90%, sebagian besar ditulis dalam huruf C. Lihatlah firmware perangkat rumah tangga apa pun di apartemen Anda. Kemungkinan besar ini lagi C! Sistem operasi? Tentu saja C.
Mengapa ini terjadi? Faktanya adalah semua hal di atas bekerja secara langsung dengan besi. Besi tidak tahu fungsi dari tatanan yang lebih tinggi. Besi adalah seperangkat register (yang sudah merupakan keadaan bisa berubah), menyela (lagi, yang mengubah keadaan) dan memerintahkan yang mentransfer nol dan yang dari satu sel ke sel lainnya.
Tentu saja, Anda dapat menggunakan abstraksi dan melupakan semua benda besi ini. Tapi pertama-tama, ini tidak selalu masuk akal. Jika program kami cukup sederhana, maka tidak ada gunanya menutup dengan beberapa lapisan abstraksi. Kedua, seringkali dalam program semacam itu, kecepatan kerja diletakkan pada salah satu posisi kunci. Karena itu, biaya tambahan untuk "menjelaskan" kelenjar FP sepenuhnya akan menghancurkan manfaat perkembangan Anda. AF tidak dapat memanifestasikan dirinya di sini.
2. Ini membawa sakit kepala saat berintegrasi dengan solusi turnkey
Setiap bahasa pemrograman yang menghargai diri sendiri memiliki sejumlah besar solusi siap pakai. Dalam C #, misalnya, Entity Framework dan .Net. Di Jawa, ini adalah Hibernate dan Spring. Dan hampir setiap kerangka kerja ditujukan untuk bekerja dengan gaya OOP kami yang biasa. Hampir selalu, solusi ini memiliki keadaan variabel dan sama sekali tidak cocok untuk bekerja dengan transisi fase murni.
Setiap programmer fungsional hard-core akan mengatakan bahwa Anda perlu membuang solusi ini dan bekerja tanpanya. Baiklah Mari kita cari referensi apa yang akan kita kehilangan dari keputusan seperti itu:
- Hampir selalu, keputusan seperti itu menghasilkan kode boilerplate.
- Kami kehilangan banyak fungsi. Tentu saja, kita dapat mengambil perpustakaan yang sudah jadi untuk bekerja dalam paradigma fungsional. Tetapi hampir selalu solusi semacam itu jauh kurang populer, yang berarti tidak dapat menawarkan setengah dari semua kemungkinan solusi populer.
- Produk jadi yang menggunakan solusi ini perlu hampir sepenuhnya di-refactored.
- Kami kehilangan solusi yang teruji dan sangat deterministik. Sebaliknya, kami bergerak ke arah yang tidak diketahui. Apakah ada masalah dalam solusi populer? Tentu saja! Tetapi tentang mereka, sebagai suatu peraturan, semuanya telah lama diketahui. Dalam pendekatan baru kami, ini pasti tidak akan terjadi.
Faktanya, daftar ini berjalan untuk waktu yang lama. Menurut pendapat saya, totalitas kerugian membuat AF, setidaknya, tidak di mana-mana dan tidak selalu cocok.
3. Menghabiskan waktu di AF tidak selalu bijaksanaNamun yang mengejutkan, seringkali programmer tidak melihat apa yang ada di balik kode tersebut. Tidak selalu bahasa pemrograman dan paradigma menentukan kualitas suatu produk. Di belakang, semuanya berjalan ke containerization. Hampir tidak penting apa yang Anda tulis di: Python, Java, Scala. Kode dalam salah satu bahasa ini dapat dibungkus dalam gambar dan dikirim sebagai wadah.
Di dunia seperti itu, tidak terlalu penting apa yang ada di dalam wadah jika memenuhi semua persyaratan yang ditetapkan. Lebih penting di sini bagaimana keseluruhan sistem diatur. Muncul pertanyaan: apakah Anda benar-benar yakin bahwa waktu Anda harus diinvestasikan untuk mempelajari FP dengan teori kategorinya? Mungkin bernilai investasi dalam pengembangan arsitektur sistem secara keseluruhan. Selain itu, jauh lebih mudah untuk menemukan orang-orang tanpa pengetahuan KB yang siap memberi Anda wadah tersebut.
Bayangkan situasi ini. Anda duduk di malam hari dan mempelajari seluruh teori. Anda menonton video di YouTube, membaca buku, mempelajari perhitungan matematika. Seiring waktu, Anda sudah dapat membangun aplikasi kecil, tetapi tidak semuanya jelas. Anda mulai berlatih lebih lanjut: mengambil buku-buku yang lebih maju, pergi ke pertemuan, melakukan percakapan dengan kolega tentang tingginya. Tapi kemudian proyek nyata muncul. Dengan pengetahuan Anda, Anda jatuh ke peran utama dalam proyek ini. Hidup itu baik! Jadi Anda menulis layanan yang sempurna. Hanya satu masalah yang tersisa. Apa yang harus dilakukan selanjutnya? Bagaimana cara mengkonfigurasi proses otomasi? Bagaimana cara mengatur keseimbangan pintar? Bagaimana menemukan layanan Anda yang lain? Anda mungkin tidak punya jawaban untuk pertanyaan-pertanyaan ini! Apakah Anda masih yakin bahwa AF sangat diperlukan untuk Anda?
Kesimpulan
Bahkan, saya memiliki sikap yang sangat positif terhadap AF. Yang ingin saya katakan adalah alat yang jauh dari selalu dan di mana-mana. Menurut pendapat saya, seorang insinyur tidak boleh berpikir dalam kategori suka / tidak suka. Sebaliknya, harus ada alasan paling objektif untuk menggunakan solusi ini atau itu.
Sebelum mempelajari / memperkenalkan paradigma fungsional, seseorang harus mengajukan setidaknya tiga pertanyaan: kemungkinan penerapan di bidang profesional Anda, seberapa besar hal itu dapat memengaruhi ketika diintegrasikan dengan solusi yang sudah jadi, dan apakah waktu dan sumber daya yang dihabiskan akan terbayar. Jika Anda tidak memiliki serangan panik dari semua masalah ini, maka Anda bisa membawanya ke layanan.
Terima kasih atas perhatian anda!