Mengapa antusiasme saat ini untuk Pemrograman Fungsional? [Tutup]


50

Saya telah mendengar banyak antusiasme tentang bahasa pemrograman fungsional belakangan ini, berkaitan dengan Scala, Clojure, dan F #. Saya baru-baru ini mulai mempelajari Haskell, untuk mempelajari paradigma FP.

Saya menyukainya, sangat menyenangkan, dan sesuai dengan latar belakang matematika saya.

Tetapi apakah itu benar-benar penting? Jelas, ini bukan ide yang baru.

Inilah pertanyaan saya:

  1. Apa yang berkontribusi pada antusiasme KB baru-baru ini? Apakah hanya kebosanan dengan OO, atau ada sesuatu yang berubah untuk membuat FP lebih dibutuhkan daripada sebelumnya?
  2. Apakah ini indikasi masa depan FP? Atau ini mode, seperti database berorientasi objek?

Dengan kata lain, adakah yang bisa membantu saya memahami dari mana ini berasal dan ke mana perginya?



13
Bukan duplikat - ini bertanya mengapa orang tiba-tiba membuat keributan, karena itu bukan ide baru, (sementara pertanyaan itu meminta lebih banyak perbedaan obyektif).
Peter Boughton

2
Orang-orang mempermasalahkan FP belakangan ini? Berita untuk saya, saya pikir ini selalu menjadi kasus bahwa beberapa kelompok membuat keributan tentang bagaimana FP akan mengambil alih dunia pemrograman imperatif.
Chris

1
Saya pikir saya sudah menjawab pertanyaan ini di StackOverflow sebelumnya.
Ken Bloom

1
Ya - FP sudah tua saya pikir ketika saya menggunakan Skema sebagai mahasiswa di Columbia pada tahun 1989. Kurasa hal baru yang mengkilap.
Tim

Jawaban:


33

Salah satu inovasi utama dalam FP yang menghasilkan "ledakan" minat adalah monad.

Pada Januari 1992, Philip Wadler menulis sebuah makalah berjudul The Essence of Functional Programming yang memperkenalkan monads ke dalam pemrograman fungsional sebagai cara untuk berurusan dengan IO.

Masalah utama dengan bahasa pemrograman murni, malas, fungsional adalah utilitas dalam berurusan dengan IO. Ini adalah salah satu anggota "Awkward Squad" dalam pemrograman, karena "kemalasan dan efek samping, dari sudut pandang praktis, tidak sesuai. Jika Anda ingin menggunakan bahasa malas, itu haruslah bahasa murni fungsional; jika Anda ingin menggunakan efek samping, Anda sebaiknya menggunakan bahasa yang ketat. " Referensi

Masalah dengan IO sebelum monad adalah bahwa menjaga kemurnian tidak dimungkinkan untuk program yang sebenarnya berguna untuk apa pun. Dengan IO, kami berarti segala sesuatu yang berhubungan dengan perubahan status, termasuk mendapatkan input dan output dari pengguna atau lingkungan. Dalam pemrograman fungsional murni, semuanya tidak berubah, untuk memungkinkan kemalasan dan kemurnian (bebas dari efek samping).

Bagaimana monad memecahkan masalah IO? Nah, tanpa membahas terlalu banyak monads, mereka pada dasarnya mengambil "Dunia" (lingkungan runtime) sebagai input ke monad, dan menghasilkan "Dunia" baru sebagai output, dan hasilnya: ketik IO a = World -> (a, Dunia).

Oleh karena itu FP telah semakin masuk ke arus utama, karena masalah terbesar, IO (dan lainnya) telah diselesaikan. Integrasi ke dalam bahasa OO yang ada juga telah terjadi, seperti yang Anda tahu. LINQ adalah monads, misalnya, melalui dan melalui.

Untuk informasi lebih lanjut, saya sarankan membaca tentang monad dan makalah yang dirujuk dalam jawaban saya.


Sangat informatif, terima kasih. Saya menerima jawaban ini, bukan karena itu benar dan yang lain salah (saya telah meningkatkan beberapa) tetapi karena saya pikir itu layak mendapatkan visibilitas yang dihasilkan.
Eric Wilson

Contoh yang lebih relevan akan menjadi type IO a = UI -> (a, UI)jawaban yang fantastis.
ChaosPandion

@ Richard: "ketik IO a = Dunia -> (a, Dunia)" terdengar hampir terlalu bagus untuk menjadi kenyataan (saya pikir saya tidak akan pernah mendapatkan monad). Saya kira Anda menyamakan LINQ dengan monad karena ketika Anda memasukkan lambda ke operator LINQ, lambda "melihat" seluruh lingkungannya, benarkan?
Stefan Monov

@Stefan: Kedengarannya agak akurat untuk mengatakan lambda melihat lingkungannya, tapi saya tidak 100% jelas tentang itu, jadi saya ragu untuk menjawab sampai saya belajar lebih banyak sendiri. Namun, saya dapat mengatakan dengan kepastian 100%, bahwa LINQ adalah monad, karena pencipta telah mengatakannya pada banyak kesempatan. SelectMany persis sama dengan Bind di Haskell. Jika Anda belum membaca "The Marvels of Monads" ( blogs.msdn.com/b/wesdyer/archive/2008/01/11/... ) Saya sangat merekomendasikannya ... ini akan mengungkapkan bagaimana LINQ benar-benar monad. Tepuk tangan.
Richard Anthony Hein

1
@Job, Lihat blogs.msdn.com/b/wesdyer/archive/2008/01/11/… sebagaimana dirujuk dalam komentar di atas.
Richard Anthony Hein

30

Salah satu masalah utama ketika memprogram bahasa tradisional seperti C, Java, C #, assembler dll. Adalah bahwa Anda memiliki urutan langkah yang canggung yang harus Anda ambil untuk menyelesaikan tugas yang diberikan karena Anda harus menyiapkan semua dependensi terlebih dahulu dan Ketergantungan mereka MEREKA sebelumnya

Contoh: Untuk melakukan A, Anda harus memiliki B dan C sekarang, dan B tergantung pada D dan E, menghasilkan sesuatu seperti

  • D
  • E
  • C
  • B
  • SEBUAH

karena Anda harus menyiapkan bahan sebelum dapat menggunakannya.

Bahasa fungsional, terutama yang malas, membalikkan yang satu ini. Dengan membiarkan A mengatakan perlu B dan C, dan biarkan runtime bahasa menentukan kapan untuk mendapatkan B dan C (yang pada gilirannya membutuhkan D dan E) yang semuanya dievaluasi saat diperlukan untuk mengevaluasi A, Anda dapat membuat sangat kecil dan ringkas blok bangunan, yang menghasilkan program kecil dan ringkas. Bahasa-bahasa malas juga memungkinkan menggunakan daftar yang tidak terbatas karena hanya elemen yang benar-benar digunakan yang dihitung, dan tanpa perlu menyimpan seluruh struktur data dalam memori sebelum dapat menggunakannya.

Trik yang sangat bagus, adalah bahwa mekanisme "oh, saya butuh B dan C" otomatis ini dapat diskalakan karena tidak ada batasan - seperti dalam program berurutan - tentang di mana dan kapan evaluasi ini bisa terjadi, sehingga bisa terjadi di waktu yang sama dan bahkan pada prosesor atau komputer yang berbeda.

Itulah sebabnya bahasa fungsional menarik - karena mekanisme "apa yang harus dilakukan ketika" diambil alih oleh sistem runtime sebagai lawan dari programmer yang harus melakukannya secara manual. Ini adalah perbedaan yang sama pentingnya dengan pengumpulan sampah otomatis untuk Java ke C, dan salah satu alasan utama mengapa lebih mudah untuk menulis perangkat lunak multi-threaded yang kuat dan dapat diskalakan di Jawa daripada di C. Bahkan lebih mudah untuk menulis dengan kuat, perangkat lunak multi-utas skalabel dalam bahasa fungsional ...


3
Ini benar pada tahun 1950, tentu saja.
Eric Wilson

1
@FarmBoy, tidak juga, tapi hari ini

5
Apa bedanya dengan Injeksi Ketergantungan?
Bill K

2
@ Bill K, pengamatan yang bagus - Saya belum membuat koneksi itu sendiri. Perbedaannya adalah bahwa objek yang akan disuntikkan - setidaknya di Jawa - dievaluasi dengan penuh semangat, dan tidak malas dievaluasi. Anda tidak dapat menyuntikkan daftar yang tak terbatas.

1
@ Thorbjørn Ravn Andersen Saya tidak yakin saya mengerti mengapa daftar yang tak terbatas akan berguna, bisakah Anda benar-benar melakukan penjumlahan dari jenis operasi (daftar tak terbatas)? Tampaknya sangat tidak mungkin. Kalau tidak, itu hanya terdengar seperti cara Jawa menggunakan iterator, Anda hanya kode iterator sedemikian rupa sehingga hanya instantiates objek ketika Anda meminta mereka - tidak cukup tak terbatas, tetapi tidak pernah berakhir (ada perbedaan besar, eh? )
Bill K

21

Pada akhir 80-an / awal 90-an komputer menjadi cukup kuat untuk OOP gaya Smalltalk. Saat ini komputer cukup kuat untuk FP. FP memprogram pada level yang lebih tinggi dan seringkali - sementara lebih menyenangkan untuk diprogram - bukan cara yang paling efisien untuk menyelesaikan masalah tertentu. Tetapi komputer begitu cepat sehingga Anda tidak peduli.

Prorgamming multi-core bisa lebih mudah dengan bahasa pemrograman murni fungsional karena Anda dipaksa untuk mengisolasi kode yang mengubah keadaan.

Perbatasan bahasa pemrograman juga kabur hari ini. Anda tidak harus menyerah pada satu paradigma jika ingin menggunakan yang lain. Anda dapat melakukan FP dalam kebanyakan bahasa populer sehingga penghalang entri rendah.


6
Akan menambahkan jawaban, tetapi Anda tepat pada kalimat terakhir Anda; Pemrograman Fungsional akan menjadi lebih dan lebih lazim karena jumlah core dalam satu mesin naik. Kurangnya keadaan yang melekat membuatnya lebih mudah untuk secara mekanik membagi program fungsional di seluruh prosesor (yang berarti bahwa jika Anda memiliki program murni fungsional, kompiler secara teoritis dapat menjaga paralelisme untuk Anda dengan sedikit usaha di pihak Anda, lihat youtube.com/watch? v = NWSZ4c9yqW8 untuk diskusi tentang paralelisme data).
Inaimathi

1
@Inaimathi Ditto. Pemrograman fungsional sangat scalable, sehingga masuk akal pada arsitektur multi-core.
EricBoersma

Perhatikan bahwa komentar pertama saya ditulis sebelum jawaban diedit mengandung pernyataan tambahan.
Inaimathi

Maaf untuk itu. Saya baru saja melupakan hal ini.
LennyProgrammers

Apakah benar-benar diterima secara umum bahwa kompiler fungsional tidak dapat menghasilkan kode mesin sama optimalnya dengan OOPS? Saya tidak dapat memikirkan alasan teoretis mengapa itu harus benar; dan saya bisa memikirkan cara-cara yang memungkinkan optimasi yang lebih maju daripada di OOPS.
Jeremy

7

Kebutuhan saat ini untuk komputasi terdistribusi.

FP menggunakan fungsi sebagai blok bangunan, yang tidak memiliki status, jadi menjalankannya n kali dengan parameter yang sama harus selalu mengembalikan nilai yang sama, mereka tidak memiliki efek samping.

Dengan demikian, Anda dapat mengirim fungsi yang sama ke banyak mesin untuk melakukan dan melakukan pekerjaan secara paralel.

Dalam paradigma OO, ini sedikit lebih sulit, karena blok bangunan adalah objek, yang hampir secara definisi stateful. Jika Anda memanggil beberapa kali metode yang sama, Anda harus berhati-hati dalam menyinkronkan data internal, untuk menghindari korupsi data. Meskipun masih mungkin, paradigma FP bekerja lebih baik daripada OO dalam beberapa skenario di mana komputasi harus didistribusikan.

Munculnya FP (dan NoSQL pada tingkat tertentu) muncul setelah cerita tentang hasil komputasi yang luar biasa di ratusan ribu komputer yang bekerja secara paralel, dan betapa mudahnya.

Tapi mungkin ini hanya ceruk jenis aplikasi yang membutuhkan pengaturan semacam ini. Bagi banyak orang, banyak aplikasi / sistem lain, prosedural dan OO bekerja dengan baik.

Begitu juga dengan semua akan memperluas cakrawala pemrograman kami dan mengambil kembali konsep-konsep yang kami pikir tidak akan melampaui dunia akademis.

Saya belajar untuk memprogram di Lisp tahun yang lalu, dan saat itu saya tidak tahu itu bahkan FP. Sekarang saya sudah melupakan hampir semua hal tentang itu, tetapi tentu saja membantu saya untuk memahami konsep seperti rekursi dengan sangat mudah.


2
Pertanyaannya adalah menanyakan tentang kelebihan bahasa seperti FP . Apa yang Anda uraikan dapat dilakukan dengan menggunakan bahasa tradisional juga.
Pacerier

6

Kami pindah ke era di mana pemrosesan multi-inti tidak hanya dilakukan di ruang belakang laboratorium sains atau pada perangkat keras khusus. Sekarang sedang dilakukan dengan prosesor komoditas. Pemrograman fungsional, paling tidak sebagian besar varian yang pernah saya gunakan, umumnya mencoba untuk mendorong pandangan tentang efek bebas, unit komputasi stateless. Ini adalah paradigma klasik untuk pekerjaan multi-core karena tidak perlu menjaga keadaan saling terkait antara prosesor.

Ini hanya salah satu alasan tetapi alasan yang sangat bagus untuk melihat pemrograman fungsional mulai berlaku.


5

Saya pikir jawaban utama untuk pertanyaan itu adalah 'paparan'.

Pemrograman fungsional bukanlah hal yang baru, saya diajari Haskell di universitas sekitar 12 tahun yang lalu dan menyukainya. Tetapi jarang bisa menggunakan bahasa dalam pekerjaan profesional saya.

Baru-baru ini ada sejumlah bahasa yang mendapatkan daya tarik dalam aliran utama yang menggunakan pendekatan multi-paradigma; F # , JavaScript menjadi contoh utama.

JavaScript khususnya, terutama ketika digunakan dengan bahasa kerangka gaya fungsional seperti jQuery atau Prototype , menjadi bahasa sehari-hari bagi banyak orang karena semua pekerjaan di situs web modern yang dinamis. Paparan gaya fungsional ini membuat orang menyadari kekuatan yang diberikannya, terutama ketika seseorang dapat kembali ke gaya imperatif sesuka hati.

Setelah orang terpapar, mereka mencoba varian bahasa fungsional yang lebih lengkap dan mulai menggunakannya untuk tugas sehari-hari.

Dengan F # menjadi bahasa kelas satu dalam Visual Studio 2010 dan jQuery (et al) menjadi sangat penting, menjadi realistis untuk menggunakan bahasa-bahasa ini, bukan hanya sesuatu yang tidak jelas untuk dimainkan atau dibuat program terisolasi.

Ingat bahwa kode harus dipelihara - sejumlah besar pengembang harus menggunakan dan mendukung bahasa agar perusahaan merasa aman menggunakannya.


3

Dalam pembicaraan ini Anders Hejlsberg menjelaskan pandangannya tentang topik tersebut.

[SUNTING]

Maaf, tautannya salah. Sekarang menunjuk ke tempat yang tepat.

Ringkasan singkat dari beberapa pokok pembicaraan satu jam:

Bahasa fungsional memungkinkan gaya pemrograman yang lebih deklaratif daripada bahasa prosedural, sehingga program yang ditulis dalam FLs biasanya lebih berkonsentrasi pada apa daripada bagaimana caranya . Karena struktur matematisnya yang elegan, FLs juga lebih mudah untuk dioptimalkan dan ditransformasikan oleh kompiler, yang juga memungkinkan meta-pemrograman yang mudah dan pembangunan DSL yang disematkan. Semua ini bersama-sama membuat program funtional lebih ringkas dan mendokumentasikan diri sendiri daripada program prosedural.

Juga, dalam menghadapi era banyak inti dalam waktu dekat, bahasa pemrograman harus dapat memanfaatkan multi threading / pemrosesan dengan cara yang berbeda. Multi threading pada mesin inti tunggal berlaku sebagai mekanisme pembagian waktu, dan arsitektur sistem mencerminkan hal ini. Multi threading pada mesin manycore akan sangat berbeda. Bahasa fungsional sangat cocok untuk paralelisasi, karena mereka sebagian besar menghindari keadaan, jadi orang tidak perlu terlalu khawatir tentang integritas data yang dapat ditukar bersama (karena cenderung tidak ada data yang dapat dibagikan bersama).


1
Bisakah Anda meringkas?

1
@ Talbjorn Itu mengingatkan saya pada pria yang tidak bisa meringkas . (Tidak mengarahkan itu pada Anda, jawab penulis.)
Mark C

1
Tautan bahkan tidak terhubung ke tempat yang tepat.
Ken Bloom

2

Saya pikir ini ada hubungannya dengan korelasi erat antara paradigma pemrograman fungsional dan pemrograman untuk web.

Ruby on Rails membawa seluruh pendekatan pemrograman fungsional ke dalam bantuan karena menawarkan jalan yang sangat cepat ke aplikasi web fungsional (heh heh). Ada diskusi menarik tentang SO tentang ini, dan satu jawaban khusus menonjol:

Pemrograman fungsional sangat cocok dengan aplikasi web. Aplikasi web menerima permintaan HTTP dan menghasilkan hasil HTML. Ini dapat dianggap sebagai fungsi dari permintaan ke halaman.

Bandingkan dengan aplikasi desktop, di mana kami biasanya memiliki proses yang berjalan lama, UI stateful dan aliran data di beberapa arah. Ini lebih cocok untuk OO yang peduli tentang objek dengan status dan pesan yang lewat.

Mengingat bahwa pemrograman fungsional sudah ada sejak lama, saya bertanya-tanya mengapa saya tidak melihat banyak iklan pekerjaan mencari pengembang Lisp untuk proyek web greenfield.


Saya pikir analogi fungsional hanya berlaku untuk web secara kebetulan, karena protokol yang mendasari adalah stateless. Aplikasi web tidak benar-benar tanpa kewarganegaraan, yang sebenarnya merupakan alasan bahwa kami harus selalu bekerja dengan HTTP.
Mladen Jablanović

@Mladen Hmmm, apakah mungkin Anda mengkonfigurasi status komunikasi client-server (HTTP) dengan status aplikasi (DAOs dll)? Mengutip Stefan Tilkov dari sini ( codemonkeyism.com/stateless-applications-illusion ) "Dalam aplikasi web, setiap permintaan individu harus berisi informasi yang cukup untuk dapat diproses secara independen apakah permintaan sebelumnya tidak atau tidak terjadi. Sumber daya sisi server yang gigih keadaan baik-baik saja, keadaan sisi klien baik-baik saja, komunikasi sementara (sesi) bukan karena itu akan merusak skalabilitas dan kemampuan bookmark. " Ini adalah dasar dari REST.
Gary Rowe

1
Anda mungkin ingin membaca paulgraham.com/avg.html untuk mendapatkan pemahaman yang lebih baik tentang mengapa tidak ada banyak iklan pekerjaan yang mencari pengembang Lisp.

@ Thorbjørn Ravn Andersen Artikel bagus. Mengilhami saya untuk keluar editor Lisp saya.
Gary Rowe

1

Pemrograman fungsional memberi saya perasaan geli yang sama tentang " wow, ini baru " seperti ketika saya mulai berkecimpung dengan benda bertahun-tahun yang lalu.

Saya menyadari bahwa FP bukanlah konsep baru sejauh ini, tetapi OO juga tidak ketika itu benar-benar pecah pada tahun sembilan puluhan ketika "semua orang" tiba-tiba melompat dari pemrograman pemrograman. Ini sebagian besar disebabkan oleh keberhasilan tepat waktu Jawa dan kemudian C #.

Saya membayangkan hal yang sama akan terjadi dengan FP pada akhirnya setelah kumpulan bahasa berikutnya mulai menyebar dengan cara yang sama. Sebanyak yang mereka miliki, setidaknya di beberapa lingkaran, dengan bahasa seperti Scala dan F #.


OO jauh lebih muda dari FP, tetapi menjadi pusat perhatian jauh sebelumnya. Saya kira kurung terlalu banyak orang takut
Javier

1

Inilah pertanyaan saya: 1. Apa yang berkontribusi pada antusiasme KB baru-baru ini? Apakah hanya kebosanan dengan OO, atau ada sesuatu yang berubah untuk membuat FP lebih dibutuhkan daripada sebelumnya? 2. Apakah ini merupakan indikasi masa depan FP? Atau ini mode, seperti database berorientasi objek?

Yang lain telah memberikan alasan teknis yang bagus.

Saya pikir alasan utama FP mendapatkan traksi di antara rata-rata pengembang dan jenis manajer adalah janji untuk memungkinkan penggunaan CPU multi-core yang lebih baik. Dari semua yang saya baca, FP memungkinkan pemrograman paralel yang lebih mudah (tidak mudah).

Ini digunakan secara luas di masa depan jika janji itu nyata dan dipenuhi.


Itu "jika" besar. COBOL, "dalam bahasa Inggris" akan berarti siapa pun dapat memprogram. AI akan membuat pemrograman menjadi usang. OO akan membuat pemrograman sesederhana merakit tinkertoy. Coder seperti groupies rock, selalu mencari "hal besar berikutnya", dan yang setelah itu, dan yang ...
Mike Dunlavey

0

Saya pikir ini adalah kombinasi dari dua tren:

  1. Fitur fungsional ditambahkan ke bahasa umum (mis. C #).
  2. Bahasa fungsional baru sedang dibuat.

Mungkin ada batas alami pada tren pertama, tetapi tebakan saya adalah bahwa setiap bahasa baru harus mendukung pemrograman fungsional, setidaknya sebagai pilihan, agar dianggap serius.


0

Dulu orang-orang menulis program untuk dijalankan di desktop menggunakan API asli sistem operasi, dan API itu (umumnya) ditulis dalam C, jadi sebagian besar jika Anda ingin menulis sebuah program untuk API asli, Anda menulis program itu di C.

Saya pikir inovasi baru dalam 10 tahun terakhir atau lebih adalah untuk keragaman API untuk menangkap, terutama untuk hal-hal seperti pengembangan web di mana platform API tidak relevan (karena membangun halaman web pada dasarnya melibatkan manipulasi string). Karena Anda tidak mengkode langsung ke Win32 API atau POSIX API, yang memberi orang kebebasan untuk mencoba bahasa fungsional.


0

Ini rapi dan bagus dan menggelitik otak Anda. Tidak apa-apa.

Ini juga, IMHO, kereta musik klasik. Solusi mencari masalah.

Ini seperti semua perusahaan startup yang didirikan oleh para insinyur yang terpesona dengan ide favorit, yang menyala dengan cerah untuk sementara waktu, tetapi diam-diam disusul oleh perusahaan yang didirikan untuk menyediakan apa yang dibutuhkan.

Itulah ide baru yang ingin saya lihat lepas landas, pemrograman berbasis kebutuhan, bukan pemrograman berbasis ide bagus. Mungkin kedengarannya biasa, tapi saya pikir itu sebenarnya bisa sangat kreatif, dan bagus.


-1

Pasti karena F #, meskipun kadang-kadang sulit untuk mengatakan mana yang menjadi penyebab dan yang mana efeknya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.