Pemrograman Fungsional meningkat?

42

Akhir-akhir ini saya perhatikan bahwa bahasa pemrograman fungsional mulai populer . Baru-baru ini saya melihat bagaimana Indeks Tiobe menunjukkan peningkatan popularitas mereka dibandingkan dengan tahun lalu meskipun kebanyakan dari mereka bahkan tidak mencapai 50 bahasa terpopuler menurut indeks ini.

Dan ini sudah cukup lama terjadi. Pemrograman fungsional tidak menjadi sepopuler model lainnya (yaitu pemrograman berorientasi objek).

Saya telah melihat minat terlahir kembali pada kekuatan pemrograman fungsional, dan sekarang multicores semakin populer, pengembang mulai menunjukkan minat pada model konkurensi lain yang telah dieksplorasi di masa lalu oleh bahasa-bahasa seperti Haskell dan Erlang.

Saya melihat dengan minat besar fakta bahwa meskipun kurangnya penerimaan masyarakat yang signifikan, semakin banyak bahasa seperti ini terus muncul. Clojure (2007), Scala (2003), F # (2002) hanyalah tiga contoh dekade terakhir ini.

Saya sendiri, telah menginvestasikan waktu untuk belajar Haskell dan Scala. Dan saya menemukan potensi besar dalam paradigma yang bagi saya baru meskipun sudah ada di sana begitu lama.

Dan tentu saja, pertanyaan terbesar saya adalah apakah salah satu dari ini akan menjadi cukup populer untuk mempertimbangkan upaya apa pun di dalamnya, tetapi ini adalah pertanyaan yang bahkan tidak bisa dijawab oleh Mandrake, meskipun semua keributan yang dilakukan orang tentang mereka.

Yang ingin saya tanyakan adalah:

  • Dalam skenario mana saya harus mempertimbangkan bahasa pemrograman fungsional yang lebih cocok untuk melakukan tugas yang diberikan? Selain masalah multicore yang baru-baru ini populer pemrograman paralel.
  • Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang akan Anda anggap sebagai jebakan terbesar yang akan saya hadapi? (Selain perubahan paradigma dan kesulitan untuk mengevaluasi kinerja karena evaluasi malas).
  • Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

Setiap rekomendasi untuk penelitian lebih lanjut akan sangat disambut.

Saya telah mencari di web untuk pendapat, dan tampaknya semua popularitas pembaruan ini berasal dari gagasan bahwa sekarang kita akan menabrak tembok Hukum Moore dan bahasa pemrograman fungsional akan datang dan secara heroik menyelamatkan kita. Tetapi jika ini masalahnya, saya akan mengatakan ada lebih banyak kemungkinan bahasa populer yang ada beradaptasi dengan paradigma.

Beberapa dari Anda, dengan lebih banyak pengalaman bekerja setiap hari dengan bahasa-bahasa ini mungkin, dapat menawarkan lebih banyak wawasan tentang masalah ini. Semua pendapat Anda akan lebih dihargai dan dipertimbangkan dengan cermat.

Terima kasih sebelumnya!

edalorzo
sumber
4
Ini Erlang, bukan Earlang (saya telah mengedit posting Anda, tetapi Sistem tidak mengizinkan suntingan 1 huruf).
quant_dev
6
Layak dikatakan - tidak ada garis keras antara bahasa fungsional dan imperatif. Bahasa keluarga ML tidak bebas efek samping, dan mendukung pernyataan serta struktur dan variabel yang dapat berubah. Beberapa bahasa penting - di luar kepala saya Python dan Javascript - memiliki fitur signifikan yang diambil dari pemrograman fungsional. Secara pribadi, saya berharap dapat melihat lebih banyak ide fungsional dalam penggunaan umum - terutama pencocokan pola.
Steve314
1
Memiliki beberapa fitur yang umum untuk bahasa fungsional tidak selalu membuat bahasa "fungsional". Pemrograman fungsional adalah tentang cara berpikir dan merancang program seperti halnya tentang fitur bahasa tertentu.
mipadi
2
@mipadi - dan karena itu Anda dapat menerapkan filosofi fungsional dalam bahasa apa pun, sejauh yang dimungkinkan oleh alat yang tersedia. Anda dapat menulis kode gaya fungsional dengan Python (dalam batas), dan sejauh itu Python adalah bahasa fungsional. Dan Anda dapat menulis kode gaya imperatif dalam ML, dan sejauh itu ML adalah bahasa imperatif. Ini tidak persis sama dengan "programmer buruk dapat menulis Fortran dalam bahasa apa pun", meskipun jelas itu jebakan yang mudah untuk jatuh ke dalam jika Anda salah mengartikan poin saya.
Steve314
1
@Mipadi - tetapi jika bahasa imperatif memiliki semua konstruksi fungsional normal, Anda bisa melakukan apa saja dengan itu Anda bisa dalam bahasa fungsional - kesenjangan akan ditutup, dan pertanyaannya adalah "apa cara terbaik untuk melakukan ini" daripada "Apa cara fungsional / imperatif". Keluarga ML telah menutup celah itu, sungguh, tetapi karena ini disebut fungsional, kami menganggap gayanya sebagai gaya fungsional daripada sekadar gaya yang bagus.
Steve314

Jawaban:

24

Dalam skenario mana saya harus mempertimbangkan bahasa pemrograman fungsional yang lebih cocok untuk melakukan tugas yang diberikan? Selain masalah multicore yang baru-baru ini populer pemrograman paralel.

Apa pun yang melibatkan pembuatan urutan elemen data turunan menggunakan sejumlah langkah transformasi.

Pada dasarnya, "masalah spreadsheet". Anda memiliki beberapa data awal dan kumpulan perhitungan baris-demi-baris untuk diterapkan pada data itu.

Aplikasi produksi kami melakukan sejumlah ringkasan statistik data; ini semua terbaik didekati secara fungsional.

Satu hal umum yang kami lakukan adalah gabungan dari tiga set data yang mengerikan. Mirip dengan gabungan SQL, tetapi tidak digeneralisasikan. Ini diikuti oleh sejumlah perhitungan data turunan. Ini semua hanya transformasi fungsional.

Aplikasi ini ditulis dalam Python, tetapi ditulis dalam gaya fungsional menggunakan fungsi generator dan tuple bernama abadi. Ini adalah komposisi fungsi tingkat bawah.

Inilah contoh konkret dari komposisi fungsional.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Ini adalah salah satu cara pemrograman fungsional memengaruhi bahasa seperti Python.

Terkadang hal semacam ini ditulis sebagai:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang menurut Anda adalah jebakan terbesar yang akan saya hadapi? (Selain perubahan paradigma dan kesulitan untuk mengevaluasi kinerja karena evaluasi malas).

Benda yang tidak bisa berubah adalah rintangan terberat.

Seringkali Anda akan berakhir dengan menghitung nilai yang membuat objek baru alih-alih memperbarui objek yang ada. Gagasan bahwa itu adalah atribut yang bisa berubah dari suatu objek adalah kebiasaan mental yang sulit untuk dihancurkan.

Properti turunan atau fungsi metode adalah pendekatan yang lebih baik. Benda stateful adalah kebiasaan yang sulit untuk dihentikan.

Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

Awalnya tidak masalah. Pilih bahasa apa saja untuk dipelajari. Setelah Anda mengetahui sesuatu, Anda berada dalam posisi untuk memilih yang lain agar lebih sesuai dengan kebutuhan Anda.

Saya sudah membaca tentang Haskell hanya untuk memahami hal-hal yang tidak dimiliki Python.

S.Lott
sumber
5
@edalorzo: Python tidak diketik dengan lemah. Ini sangat, sangat sangat diketik. Tidak ada operator pemeran, jadi ini lebih kuat daripada Java atau C ++.
S.Lott
5
@ S.Lott - bukankah bantuan pengecekan tipe statis dengan alat IDE refactoring dan hal-hal jenis intellisense? Jika Anda memiliki kompilasi latar belakang, dan Anda memeriksa jenis secara statis, bukankah itu berarti Anda dapat mengotomatiskan lebih banyak pada alat Anda? Saya setuju bahwa jika Anda memiliki 100% cakupan kode dalam tes Anda, itu akan menangkapnya. Anda harus menyadari bahwa mungkin kurang dari 50% kode produksi di perusahaan sebenarnya memiliki cakupan uji unit, bukan? :) Ada dunia nyata di luar sana yang harus kita tinggali.
Scott Whitlock
8
@ S.Lott "Pemeriksaan tipe statis tidak terlalu membantu. Tidak masalah jika ada pemeriksaan statis oleh kompiler atau pemeriksaan run-time. Anda masih menulis jumlah kode yang sama dan jumlah tes unit yang sama. " Err, tidak. Inti dari pemeriksaan tipe statis adalah bahwa ia menangkap bug, akibatnya, secara besar - besaran mengurangi jumlah pengujian yang diperlukan.
Jon Harrop
3
@ S.Lott "Python tidak diketik dengan lemah. Ini diketik sangat, sangat kuat." Python secara implisit melemparkan antara tipe numerik, yang sedang diketik dengan lemah.
Jon Harrop
3
@ Steve314 "Bagaimanapun, pengecekan tipe statis menangkap beberapa kesalahan yang sesuai dengan beberapa aturan dasar. Pengujian unit, pada prinsipnya, dapat menangkap semua kesalahan itu dan banyak lagi." Tidak. Pemeriksaan statis membuktikan kebenaran aspek suatu program. Pengujian unit berusaha untuk membuktikan kebenaran tetapi tidak membuktikan kebenaran apa pun. Pengujian unit bukanlah pengganti untuk pemeriksaan tipe statis atau jenis bukti lainnya.
Jon Harrop
23

"Fungsional" adalah banyak fitur yang berbeda, yang masing-masing secara mandiri berguna, dan saya merasa lebih berguna untuk melihat masing-masing secara individual.

Kekekalan

Sekarang saya sudah mengenalnya, kapan saja saya bisa mengembalikan hasil yang tidak berubah, saya selalu mencoba melakukan itu, bahkan dalam program berorientasi objek. Lebih mudah untuk berpikir tentang program jika Anda memiliki data tipe nilai. Biasanya Anda membutuhkan kemampuan untuk hal-hal seperti GUI dan bottleneck kinerja. Entitas saya (menggunakan NHibernate) juga bisa berubah (yang masuk akal karena mereka memodelkan data yang disimpan dalam database).

Berfungsi sebagai Tipe Kelas Satu

Apa pun yang Anda ingin menyebutnya, membagikan delegasi, tindakan, atau fungsi, adalah cara yang sangat berguna untuk menyelesaikan seluruh kelas masalah dunia nyata, seperti "hole in the middle pattern". Saya juga menemukan bahwa mengirimkan delegasi, tindakan, atau fungsi ke objek lebih bersih daripada meminta kelas tersebut mendeklarasikan suatu peristiwa dan mengaitkan peristiwa itu (dengan asumsi biasanya hanya ada satu "pendengar"). Ketika Anda tahu ada satu pendengar, maka tindakan panggil balik dapat dilewatkan sebagai parameter konstruktor (dan disimpan dalam anggota yang tidak dapat diubah!)

Mampu menyusun fungsi (misalnya berubah Action<T>menjadi hanya Actionjuga sangat berguna dalam beberapa skenario.

Kami juga harus mencatat sintaks Lambda di sini, karena Anda hanya mendapatkan sintaks Lambda ketika Anda mempromosikan fungsi ke tipe kelas satu. Sintaks Lambda bisa sangat ekspresif dan ringkas.

Monad

Memang, ini adalah titik lemah saya, tetapi pemahaman saya adalah bahwa alur kerja komputasi di F #, seperti asyncalur kerja, adalah monad. Ini adalah konstruksi yang halus tetapi sangat kuat. Ini sama kuatnya dengan yieldkata kunci yang digunakan untuk membuat IEnumerablekelas di C #. Pada dasarnya itu membangun mesin negara untuk Anda di bawah selimut, tetapi logika Anda terlihat linier.

Evaluasi & Rekursi Malas

Saya menyatukan ini karena sementara mereka selalu disatukan sebagai fitur pemrograman fungsional, mereka telah membuat jalan mereka begitu cepat ke dalam bahasa-bahasa yang sangat penting sehingga sulit untuk menyebut mereka fungsional lagi.

S-Ekspresi

Saya kira saya tidak yakin di mana harus meletakkan ini, tetapi kemampuan untuk memperlakukan kode yang tidak dikompilasi sebagai objek (dan memeriksanya / memodifikasinya), seperti Lisp S-Expressions, atau LINQ Expressions, dalam beberapa hal, alat pemrograman fungsional yang paling kuat. Sebagian besar antarmuka .NET "lancar", dan DSL, menggunakan kombinasi sintaks lambda dan Ekspresi LINQ untuk membuat beberapa API yang sangat ringkas. Belum lagi Linq2Sql / Linq2Nhibernate di mana kode C # Anda "secara ajaib" dieksekusi sebagai SQL dan bukan sebagai kode C #.

Itu adalah jawaban panjang untuk bagian pertama dari pertanyaan Anda ... sekarang ...

Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang menurut Anda adalah jebakan terbesar yang akan saya hadapi? (Selain perubahan paradigma dan kesulitan untuk mengevaluasi kinerja karena evaluasi malas).

Jebakan terbesar yang saya hadapi adalah mencoba menemukan garis antara menggunakan solusi fungsional vs solusi imperatif. Namun, setelah mencoba kedua pendekatan beberapa kali, Anda mulai merasakan yang akan bekerja lebih baik.

Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

Jika Anda terbiasa dengan .NET, saya sangat menyarankan F #. Di sisi lain, jika Anda lebih terbiasa dengan JVM, selalu ada Clojure . Jika Anda lebih akademis daripada praktis, maka saya akan menggunakan Common Lisp atau Scheme. Jika Anda sudah tahu Python, saya percaya ada banyak konstruksi fungsional yang sudah tersedia di sana.

Scott Whitlock
sumber
@Scott Terima kasih atas penjelasan terperinci Anda. Saya kira apa yang Anda gambarkan sebagai perangkap terbesar akan diambil dari persamaan dengan menggunakan bahasa pemrograman fungsional murni seperti Haskell. Itu sebabnya saya mulai dengan itu, karena saya telah menjadi programmer imperatif sepanjang hidup saya, dan saya tidak ingin membintangi dengan bahasa pemrograman yang tidak murni dan berisiko tidak belajar dengan cara yang baik. Jika Anda tidak keberatan saya mengajukan pertanyaan lain: Dua hal yang membuat saya khawatir adalah alat dan perpustakaan. Seberapa baik integrasi F # dengan alat dan perpustakaan .Net lainnya?
edalorzo
Saya tidak mengerti mengapa Anda melakukan lump code pada saat runtime dan pembuatan kode runtime dan inspeksi dengan pemrograman fungsional. Keduanya tidak memiliki hubungan satu sama lain. Kemampuan pemrograman pemrograman yang Anda gambarkan dapat ditambahkan ke hampir semua bahasa, fungsional atau tidak. Saya pikir lisp mulai kode sebagai tren data tetapi sekarang tersedia dalam ruby ​​dan bahasa non-fungsional lainnya.
davidk01
1
Integrasi @edalorzo - F # dengan .NET sangat bagus, dengan hanya satu pengecualian kecil: tidak ada desainer GUI. Anda menyiasatinya dengan merancang GUI Anda dalam rakitan C # dan merujuknya dari F #, atau dengan menghasilkan GUI di dalam F # hanya dalam kode (bukan dengan perancang).
Scott Whitlock
@ davidk01 - pertanyaan bagus tentang meta-pemrograman. Saya baru saja menemukan bahwa sintaks dan meta-pemrograman lambda saling membangun, tetapi Anda benar, mereka dapat dipisahkan. Sepertinya Anda lebih cenderung mendapatkan meta-pemrograman dengan bahasa fungsional.
Scott Whitlock
1
@Scott: Saya pikir dalam banyak hal lebih mudah - misalnya, ketika Anda tidak perlu khawatir tentang efek samping Anda dapat memodifikasi bagian kode dengan cepat dengan lebih percaya diri - itu membatasi apa yang harus Anda ubah.
Michael K
15

Dan ini sudah cukup lama terjadi. Pemrograman fungsional tidak menjadi sepopuler model lainnya (yaitu pemrograman berorientasi objek).

Ini benar jika Anda menghitung program yang dikembangkan oleh pemrogram profesional (atau setidaknya orang yang melihat diri mereka seperti itu). Jika Anda menyebarkan jaring Anda lebih luas untuk memasukkan program yang dikembangkan oleh orang-orang yang tidak menganggap dirinya demikian, FP (atau paling tidak pemrograman dengan gaya fungsional) cukup dekat dengan OO (Excel, Mathematica, Matlab, R ... bahkan JavaScript 'modern' ).

Dalam skenario mana saya harus mempertimbangkan bahasa pemrograman fungsional yang lebih cocok untuk melakukan tugas yang diberikan? Selain masalah multicore yang baru-baru ini populer pemrograman paralel.

Pendapat pribadi saya adalah bahwa multicore bukanlah fitur pembunuh FP (setidaknya sampai Haskell, Scala, Clojure, kompiler F # menyelesaikan masalah cache locality). Fitur pembunuh adalah map, filter, folddan teman-teman yang memungkinkan ekspresi yang lebih ringkas dari kelompok besar algoritma. Ini diperparah oleh bahasa FP yang memiliki sintaksis yang lebih ringkas daripada kebanyakan mitra OO.

Selain itu FP yang lebih dekat ke model relasional mengurangi ketidakcocokan impedansi dengan RDBMS ... yang - sekali lagi setidaknya untuk non-programmer - sangat bagus.

Juga ketika Anda memiliki sangat sulit untuk memenuhi persyaratan 'kebenaran' - dalam bentuk yang sulit untuk diuji (umum dalam komputasi ilmiah / analisis data besar di mana tujuannya adalah untuk mendapatkan yang sebelumnya tidak diketahui dan dengan demikian hasil yang tidak ditentukan) FP dapat menawarkan keuntungan.

Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang menurut Anda adalah jebakan terbesar yang akan saya hadapi?

  • kurangnya dukungan alat (F # dan beberapa Lisps menjadi pengecualian, Scala sedang dalam perjalanan)
  • lebih sulit untuk mengeluarkan sedikit kinerja terakhir dari perangkat keras Anda
  • komunitas sering berfokus pada masalah yang berbeda dari yang dihadapi oleh sekelompok besar proyek pengembangan perangkat lunak komersial
  • sangat sedikit pengembang yang berpengalaman dalam menggunakan FP dalam pengaturan industri dan jika Anda dapat menemukannya, Anda mungkin harus bersaing dengan gaji dan tunjangan yang dapat ditawarkan industri keuangan
  • gaya fungsional pemrograman cenderung lebih sulit untuk di-debug; yaitu mengamati di antara hasil dalam rantai panjang fungsi yang dikomposisikan biasanya tidak mungkin di sebagian besar (semua?) debugger

Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

  • Berapa banyak masalah Anda yang dapat diselesaikan dengan sudah keluar dari perpustakaan / kerangka kerja pada platform mana (misalnya JVM atau .Net) berapa banyak yang baru? Apakah ada konstruksi bahasa yang mampu mengekspresikan masalah ini secara langsung?

  • Berapa banyak kontrol tingkat rendah yang Anda butuhkan atas kinerja ruang dan waktu aplikasi Anda?

  • Seberapa ketat persyaratan "kebenaran" Anda?

  • Dapatkah Anda mampu melatih kembali pengembang dan / atau bersaing dengan manfaat yang ditawarkan oleh beberapa ceruk yang sangat menguntungkan dalam pengembangan SW?

Alexander Battisti
sumber
+1 @Alexander ini tentu saja salah satu jawaban terbaik dalam diskusi ini. Anda membawa dimensi baru argumen ke diskusi dengan memperkenalkan faktor manusia, kesulitan untuk menemukan pengembang yang terampil dan membuat mereka tetap termotivasi. Saya benar-benar setuju dengan visi Anda tentang fitur mematikan dari bahasa FP, karena setiap hari saya melihat bahasa yang lebih penting juga mengadopsi mereka. Tetapi posting Anda telah membuka mata saya untuk menyadari ada banyak hal yang saya masih belum tahu tentang FP. Akhirnya, titik Anda mendasarkan pada platform yang ada seperti. Net atau Java tentu sangat valid dan benar-benar masuk akal.
edalorzo
9

Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang menurut Anda adalah jebakan terbesar yang akan saya hadapi? (Selain perubahan paradigma dan kesulitan untuk mengevaluasi kinerja karena evaluasi malas).

Dengan asumsi Anda adalah seorang C ++ / C # / pengembang Java di industri ...

Bersiaplah untuk teman sebaya pemarah yang tidak ingin belajar apa pun. Bersiaplah untuk bos berambut runcing memaksakan pilihan bahasa yang buruk "karena mereka adalah seorang programmer sekali". Bersiaplah untuk akademisi yang penuh semangat di forum-forum yang melindungi Anda tentang monoids. Bersiaplah untuk perang bahasa tanpa akhir karena Scala bahkan tidak memiliki eliminasi panggilan ekor dan Clojure benar-benar membutuhkan pedal kaki untuk semua kurung dan jangan mulai saya menggunakan Erlang.

Jika Anda seorang programmer web maka jebakan terbesar mungkin adalah rambut Anda.

Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

Saya akan mulai dengan platform:

  • OCaml sangat bagus di Linux dan mengerikan di Windows.
  • F # sangat bagus untuk Windows dan mengerikan untuk Linux.
  • Scala dan Clojure sangat bagus di JVM.
Jon Harrop
sumber
1
Ketika saya membaca "Bersiaplah untuk teman sebaya pemarah yang tidak ingin belajar apa pun." Saya ingin berteriak: "Benar! Benar sekali!" tapi itu sangat menyedihkan.
Zelphir Kaltstahl
3

Untuk satu perspektif (yang memang bias) pada pertanyaan ini, Anda dapat melihat blog Bob Harper, Existential Type . Carnegie Mellon baru-baru ini mengerjakan ulang kurikulum CS mereka untuk mengajarkan pemrograman fungsional terlebih dahulu, dengan paradigma lain diajarkan hanya setelah landasan yang kuat dalam pemrograman fungsional telah didirikan, dan Harper memberikan pukulan-per-pukulan ketika kurikulum baru diluncurkan dalam praktik .

Harper adalah salah satu pengembang utama bahasa pemrograman ML Standar, jadi wajar untuk mengatakan pendapatnya sendiri tentang masalah ini dapat ditebak sebelumnya, dan dia tentu saja tidak malu dengan pernyataan kontroversial dalam memperdebatkan posisi ini, tetapi dia membuat kasusnya dengan baik.

jimwise
sumber
1
+1 Artikel ini tentu saja sangat menarik dan saya akan menyimpannya di favorit saya mulai sekarang. Saya pikir mengajar FP pertama tentu saja merupakan pendekatan yang bagus, karena sangat sulit untuk menyingkirkan pemikiran imperatif jika Anda melakukannya sebaliknya, dan di atas semua itu, jika Anda tidak menggunakan bahasa pemrograman yang murni fungsional, sulit untuk mematahkan yang lama. kebiasaan. Saya juga melihat bahwa bahasa-bahasa OOP utama menggabungkan fitur-fitur fungsional dan oleh karena itu memperoleh keterampilan dan keadaan pikiran seorang programmer fungsional harus benar-benar berguna dalam waktu dekat. Wawasan yang menarik, terima kasih!
edalorzo
@jimwise: +1 untuk artikel Harper. Saya menemukan pendekatannya sangat tepat. @edalorzo: Ketika Anda mulai berpikir secara fungsional, Anda bisa melihat paradigma imperatif sebagai pilihan terakhir yang harus Anda terapkan untuk mengoptimalkan program Anda ketika itu tidak cukup cepat. Saya telah menulis beberapa alat kecil di Scala baru-baru ini, tidak terlalu besar tetapi tidak sepele dan dengan beberapa fungsi nyata. Yang mengejutkan saya, saya belum pernah menggunakan varatau koleksi yang bisa berubah satu kali saja. Jadi, pemikiran imperatif adalah IMO semacam optimasi prematur yang, seperti kita semua tahu, adalah akar dari semua kejahatan.
Giorgio
2

Dalam skenario mana saya harus mempertimbangkan bahasa pemrograman fungsional yang lebih cocok untuk melakukan tugas yang diberikan? Selain masalah multicore yang baru-baru ini populer pemrograman paralel.

Tidak ada rumus ajaib yang memberi tahu Anda kapan harus menggunakan pemrograman fungsional. Ini tidak seperti pemrograman berorientasi objek yang cocok untuk situasi pemrograman kita saat ini lebih baik. Ini hanyalah cara lain untuk menyusun program dalam bentuk serangkaian abstraksi lainnya.

Jika saya memutuskan untuk beralih ke bahasa pemrograman fungsional yang menurut Anda adalah jebakan terbesar yang akan saya hadapi? (Selain perubahan paradigma dan kesulitan untuk mengevaluasi kinerja karena evaluasi malas).

Pemrograman fungsional tidak ada hubungannya dengan kemalasan. ML dan OCaml adalah bahasa yang fungsional dan ketat. Rintangan terbesar yang akan Anda hadapi adalah menyusun hal-hal berdasarkan nilai-nilai yang tidak dapat diubah dan membungkus kepala Anda dengan abstraksi apa pun yang digunakan dalam sistem tipe untuk efek samping. Bahasa fungsional lebih cocok untuk optimasi karena fakta bahwa mereka membuat efek samping sangat eksplisit dalam sistem tipe. Haskell menggunakan monads tetapi ada pendekatan lain untuk menggunakan efek dalam bahasa fungsional murni. Bersih memiliki tipe keunikan dan beberapa bahasa lain dalam pengembangan memiliki hal-hal lain.

Dengan begitu banyak bahasa pemrograman fungsional di luar sana, bagaimana Anda memilih yang lebih sesuai dengan kebutuhan Anda?

Di antara bahasa pemrograman saya sadar saya akan mengatakan hanya Haskell dan Clean dapat disebut bahasa fungsional. Semua yang lain memungkinkan efek samping tanpa membuat efek tersebut eksplisit di sistem tipe. Jadi jika Anda akan mencurahkan waktu untuk mempelajari pemrograman fungsional maka Haskell mungkin satu-satunya yang sesuai dengan tagihan. Semua yang saya tahu, Erlang, Scala, Clojure, dll. Hanya menyediakan abstraksi fungsional di atas bahasa imperatif. Jadi jika Anda ingin mendekati paradigma fungsional dalam bit maka saya akan merekomendasikan Scala atau Erlang dan jika Anda ingin mengatasi semuanya sekaligus dan mungkin menyerah dalam frustrasi maka Anda harus pergi dengan Haskell.

davidk01
sumber
@ Dadivk01 +1 Saya suka alasan bahwa FP langs hanya alat kompetitif seperti yang lain dan dapat digunakan untuk memecahkan masalah yang sama seperti yang diselesaikan dengan model lain. Mengapa Anda pikir mereka kurang populer? Dan, apakah Anda masih setuju bahwa mereka lebih cocok untuk memecahkan masalah komputasi paralel daripada misalnya kebanyakan OOP? Apakah Anda mengatakan bahwa tipe data yang tidak dapat diubah memiliki pengaruh pada jejak memori dan kinerja bila dibandingkan dengan versi imperatif? Saya memberinya kesempatan untuk Haskell, mengapa Anda mengatakan "menyerah dalam frustrasi", Anda membuat saya takut, Bung :)
edalorzo
@edalorzo: Saya tidak berpikir pemrograman fungsional lebih baik untuk algoritma paralel. Orang-orang membingungkan pemrograman deklaratif dengan pemrograman fungsional. Apa pemrograman fungsional telah terjadi untuk itu adalah sifat deklaratif dan sekelompok orang yang benar-benar pintar menulis kompiler yang sangat baik untuk menerjemahkan kode deklaratif ke kode mesin. Bahasa lain yang lebih condong ke arah menggambarkan masalah daripada secara eksplisit menjabarkan detail kecil akan sama baiknya untuk pemrograman paralel.
davidk01
@ edalorzo: Adapun "menyerah dalam frustrasi" Saya katakan bahwa karena jika pemrograman imperatif adalah yang Anda tahu maka sistem tipe haskell dan pendekatan monadiknya untuk menggambarkan efek mungkin sedikit terlalu banyak. Saya pikir lebih baik memulai dengan bahasa yang menggunakan pendekatan yang lebih pragmatis untuk efek samping seperti Erlang dan Scala.
davidk01
0

Saya akan menghubungkan peningkatan minat saat ini dalam bahasa fungsional dengan fakta bahwa mereka ideal untuk komputasi paralel. Misalnya seluruh gagasan pengurangan peta didasarkan pada paradigma fungsional. Dan tidak ada keraguan bahwa komputasi paralel akan meningkat, karena jelas bahwa peningkatan skala saat ini jauh lebih mudah dan lebih murah daripada peningkatan skala. Bahkan di pasar konsumen, CPU mendapatkan lebih banyak core, bukan lebih banyak GHz.

EDIT: karena tidak jelas untuk semua.

Dalam pemrograman fungsional murni fungsi mengambil input, menghasilkan output dan tidak memiliki efek samping. Tidak memiliki efek samping, berarti tidak memiliki status berbagi, sehingga tidak perlu mekanisme sinkronisasi, yang sebaliknya akan diperlukan saat berjalan secara bersamaan. Sinkronisasi adalah bagian yang paling sulit dari perangkat lunak konkuren / paralel, sehingga melakukannya murni fungsional, pada dasarnya Anda tidak harus berurusan dengan bagian yang paling sulit sama sekali.

Adapun pengurangan peta, bahkan namanya berasal dari pemrograman fungsional (baik pemetaan dan pengurangan adalah operasi khas dalam paradigma fungsional). Kedua langkah pengurangan peta adalah fungsi, yang berjalan secara paralel, mengambil input, menghasilkan output dan tidak memiliki efek samping. Jadi ini adalah ide pemrograman fungsional murni.

Beberapa contoh FP yang digunakan untuk paralelisme:

  • CouchDB - membangun di atas Erlang
  • Obrolan Facebook - bangun di Erlang
  • Twitter - sebagian besar dibangun di Scala
vartec
sumber
3
Semua orang membuat klaim pemrograman paralel tetapi hanya ada sedikit data untuk mendukungnya. Jika Anda mengetahui adanya sumber seperti itu maka Anda harus mengutipnya. Komputasi kompleks seringkali memiliki dependensi data yang kompleks dan jika Anda menggunakan paradigma pemrograman fungsional, interdependensi data inheren dari beberapa model tidak hilang secara ajaib. Pemrograman GPU sejajar dengan yang didapat tetapi mereka dapatkan dengan menggunakan bahasa imperatif baik-baik saja karena model mereka bekerja dengan paralelisme built in.
davidk01
4
@artec: Demi objektivitas, tetap menyenangkan jika Anda dapat memberikan referensi yang mendukung klaim Anda. Itu akan membantu pembaca yang bodoh jauh lebih dari sekadar pertanyaan balasan ...
blubb
1
@artec: Sebenarnya tidak, tidak pernah terlintas dalam benak saya bahwa banyak orang yang membuat klaim membuatnya menjadi kenyataan. Saya menyalahkan pelatihan matematika saya, tetapi hei tidak semua dari kita percaya pada hal-hal seperti fakta keras dan pembenaran konkret untuk klaim kami dan hasil edit Anda masih tidak menanggapi komentar saya.
davidk01
1
@vartec Anda dapat menempatkan referensi ke sumber yang dapat dipercaya mendukung klaim Anda.
quant_dev
1
+1 @ davidk01 "Semua orang membuat klaim pemrograman paralel tetapi hanya ada sedikit data untuk mendukungnya". Saya menyadari sejumlah besar bukti yang bertentangan. Sebagai contoh, makalah Cilk menjelaskan bagaimana mutasi di tempat sangat penting jika Anda menginginkan kompleksitas cache yang baik yang merupakan persyaratan paralelisme yang dapat diskalakan pada multicore.
Jon Harrop