Tidak, ini bukan upaya lain untuk menjelaskan monad. Saya tidak tahu bagaimana melakukan ini dan tidak bisa membayangkan bagaimana, misalnya, dari sekarang, saya bisa menjelaskan ini kepada diri saya sendiri dari masa lalu.
Hal yang sama berlaku untuk konsep FP lainnya. Saya mengerti nilai mereka, bagaimana menggunakannya. Tapi saya tidak tahu bagaimana menyampaikan ini kepada orang-orang yang awalnya cenderung negatif terhadap pendekatan fungsional. Saya tidak berpikir ini mungkin sama sekali. Berlatih dengan mudah menyelesaikan masalah ini, tetapi orang jarang mencapainya.
Saya bahkan tidak tahu bagaimana menjawab pertanyaan yang lebih sederhana. Terlepas dari kenyataan bahwa saya telah menulis di Scala selama lebih dari 3 tahun, saya tidak dapat menjelaskan dengan jari keunggulan bahasa untuk seseorang dari luar. Sebagai contoh, beberapa bulan yang lalu saya berdiskusi dengan baik.
Semuanya dimulai dengan pertanyaan:
"Dan untuk siapa bahasa Anda ditulis?" .
Semua kekebalan ini, fungsi tingkat tinggi, sistem tipe hebat, efek samping, dan monad lain berputar di kepalaku, tetapi aku mengerti bahwa ini tidak semuanya. Klarifikasi berikutnya akhirnya mengirim saya sebuah knockout:
"Di sini, misalnya, Jawa adalah bahasa untuk pekerja kerah putih .
" Dialog itu berakhir dengan omong kosong tentang ketidakmampuan untuk menjelaskan perbedaan tanpa latihan.
Kami tidak tahu cara menjual FP
Ini bukan hanya menceritakan kembali pengalaman pribadi. Kita semua, pengguna bahasa fungsional, berada dalam situasi yang kira-kira sama. Kami sangat memahami perbedaan besar dibandingkan dengan bahasa
Blub , tetapi orang-orang lain di dunia tidak ingin mendengarkan kami. Tentu saja, orang bisa marah pada kaum konservatif terbatas yang menjajakan "G", dengan tenang membawa omong kosong, menceritakan kembali mitos dan dongeng satu sama lain, dengan tegas dan percaya diri berdiskusi tentang hal-hal yang mereka bahkan tidak menghabiskan beberapa jam. Anda juga dapat menyalahkan perusahaan besar dengan tim pemasar mereka.
Tapi menurut saya, pertama-tama, masalahnya adalah bahwa kita sendiri tidak tahu cara menjual FP. Ya, ini bukan tugas yang mudah. Meskipun, ketika saya ingat bagaimana orang membuat keputusan, bagaimana dan hal-hal apa saja yang termasuk dalam tren, saya mulai berpikir bahwa ini mungkin.
Selalu ada yang salah dengan perkembangan.
- Prosesnya lambat! Dan sekarang, setelah beberapa tahun, setiap pagi, di semua kantor negara, orang-orang yang berdiri di papan tulis menyeret stiker dari satu kolom ke kolom lainnya.
- Menyebarkan lambat! Dan dipersenjatai dengan nilai-nilai devops, kami membuat 10 rilis sehari, sementara generasi admin baru membanjiri dengan ton ruby, python dan yaml.
- Aplikasi rumit! Maka tim dari 2-3 pengembang membangun arsitektur layanan mikro baru, memikirkan tanggung jawab masing-masing layanan secara terperinci dan melakukan 10 permintaan gabungan untuk satu revisi kecil.
Bukannya saya menganggap semua industri ini menggila. Mereka juga memiliki banyak kekurangan. Dan tidak semua orang tahu bagaimana cara memasaknya dengan benar. Tidak ada atau tidak ada penyetelan yang nyaman. Namun, pendekatan ini telah menjadi standar "de facto" untuk industri. Dan meskipun diskusi tentang buruh pelabuhan dalam produksi untuk beberapa tampaknya seperti pertanyaan terbuka, semuanya sudah terjadi.
Saya yakin hal yang sama dapat terjadi dengan bahasa fungsional. Ya, ini tidak sepenuhnya benar - untuk membandingkan bahasa pemrograman dengan metodologi dan pendekatan. Tetapi kami memiliki sesuatu untuk dipinjamkan pada posisi mereka untuk diri kami sendiri. Mereka semua memiliki
masalah yang
didefinisikan secara ketat yang mereka pecahkan. Dan ini kecepatan: pengembangan, komunikasi, perencanaan, penyebaran, membuat perubahan ...
Mengapa kita lupa mengatakan hal yang paling penting?
Pada saat yang sama, dari sudut pandang penentuan posisi bahasa pemrograman fungsional, sulit untuk mengatakan bahwa mereka memiliki tujuan yang jelas dan dapat dimengerti. Sarjana linguistik "
FP vs OOP " biasanya dengan cepat beralih ke ukuran fitur dan konsep yang nilainya tidak dipahami dengan baik oleh kamp OOP. Artikel dan laporan format "
Anda melihat bagaimana monad ini disusun dengan luar biasa " sering kali menguatkan pendapat bahwa mereka tidak membutuhkan ini, daripada yang diilhami untuk dicoba. Semua interaksi ini jarang menjawab pertanyaan, “
Mengapa ini semua? " Cantik dan ringkas? Yah, paling-paling, lebih sedikit kesalahan akan disebutkan.
Hal terpenting dalam menggunakan bahasa fungsional adalah kecepatan pengembangan yang sama! Dan kecepatan ini dicapai oleh semua istilah, konsep, dan sifat yang membosankan dan menakutkan yang muncul darinya. Komposisi yang lebih ringan karena fungsi urutan yang lebih tinggi - ditambah dengan kecepatan pengembangan. Kekebalan, selain reliabilitas dan kesalahan yang lebih sedikit, setara dengan memberi lebih banyak waktu untuk hal-hal yang bermanfaat, daripada menghabiskannya untuk debugging, perbaikan terbaru, dan dukungan. Baik dan seterusnya, saya pikir logikanya jelas.
Ya, itu terdengar terlalu sederhana dan bahkan jelas.
Ya, saya tidak mengatakan sesuatu yang baru di sini. Tetapi pentingnya kata-kata dan penekanan itu penting. Sayangnya, beginilah cara berpikir kita bekerja. Untuk meruntuhkan penghalang, penjelasan saja tidak cukup. Perlu latihan! Penting bahwa seseorang atau perusahaan ingin menghabiskan waktu untuk hal ini. Referensi ke "akademis" atau kecantikan relatif akan menginspirasi beberapa orang untuk menghabiskan beberapa hari merasa seperti orang idiot.
Penting untuk berhenti membangun diri Anda sebagai orang bijak, segera menyebarkan istilah kiri dan kanan, membuktikan superioritas YP favorit Anda daripada
Blub . Alih-alih membuktikan kegunaan fitur X, lebih mudah untuk menggunakannya sebagai penjelasan tentang beberapa properti yang lebih dimengerti. Jika teknisi lain berhasil, mungkin sudah waktunya bagi kita untuk mengambil tanggung jawab dengan baik dan tegas dengan hal-hal yang jelas dan sederhana.
Jadi lain kali, dengan kesulitan menjawab pertanyaan "
Mengapa? ", Jangan ragu untuk menggunakan kartu truf, seperti:
kecepatan pengembangan yang lebih tinggi ,
dukungan yang lebih murah ,
lebih sedikit pengembang .
Ah, dan banyak lagi. Acara komunitas juga memainkan peran penting dalam penentuan posisi!
Oleh karena itu, kami menunggu semua yang tidak acuh pada FP di satu-satunya konferensi fungsional di Rusia - FPURE - Kazan - 24-25 Mei .
Program ini meliputi: Haskell, Scala, Elixir, Clojure, teori dan praktik, dan tentu saja banyak orang yang berpikiran sama dengan siapa ada sesuatu untuk dibicarakan!