Mengapa bahasa fungsional? [Tutup]

332

Saya melihat banyak pembicaraan di sini tentang bahasa dan hal-hal fungsional. Mengapa Anda menggunakan salah satu dari bahasa "tradisional"? Apa yang mereka lakukan dengan lebih baik? Apa yang lebih buruk dari mereka? Apa aplikasi pemrograman fungsional yang ideal?

MattBelanger
sumber
John Hughes telah menulis makalah tentang ini: Mengapa Masalah Pemrograman Fungsional .
Hjulle

Jawaban:

214

Bahasa fungsional menggunakan paradigma yang berbeda dari bahasa imperatif dan berorientasi objek. Mereka menggunakan fungsi bebas efek samping sebagai blok bangunan dasar dalam bahasa. Ini memungkinkan banyak hal dan membuat banyak hal lebih sulit (atau dalam banyak kasus berbeda dari apa yang digunakan orang).

Salah satu keuntungan terbesar dengan pemrograman fungsional adalah bahwa urutan pelaksanaan fungsi bebas efek samping tidak penting. Misalnya, di Erlang ini digunakan untuk mengaktifkan konkurensi dengan cara yang sangat transparan. Dan karena fungsi dalam bahasa fungsional berperilaku sangat mirip dengan fungsi matematika, mudah untuk menerjemahkannya ke dalam bahasa fungsional. Dalam beberapa kasus, ini dapat membuat kode lebih mudah dibaca.

Secara tradisional, salah satu kelemahan besar pemrograman fungsional adalah juga tidak adanya efek samping. Sangat sulit untuk menulis perangkat lunak yang bermanfaat tanpa IO, tetapi IO sulit diimplementasikan tanpa efek samping pada fungsi. Jadi kebanyakan orang tidak pernah mendapatkan lebih banyak dari pemrograman fungsional daripada menghitung satu output dari input tunggal. Dalam bahasa paradigma campuran modern seperti F # atau Scala ini lebih mudah.

Banyak bahasa modern memiliki elemen dari bahasa pemrograman fungsional. C # 3.0 memiliki banyak fitur pemrograman fungsional dan Anda dapat melakukan pemrograman fungsional dengan Python juga. Saya pikir alasan untuk popularitas pemrograman fungsional sebagian besar karena dua alasan: Concurrency menjadi masalah nyata dalam pemrograman normal karena kita mendapatkan semakin banyak komputer multiprosesor; dan bahasa semakin mudah diakses.

Mendelt
sumber
14
Anda BISA melakukan pemrograman fungsional dalam python, tapi itu sangat mengerikan. stackoverflow.com/questions/1017621/…
Gordon Gustafson
28
Ini tidak sulit untuk menulis kode IO dalam bahasa fungsional murni. Mereka semua menyediakan mekanisme sederhana untuk menulis kode IO yang berfungsi seperti halnya dalam bahasa imperatif. Yang mereka lakukan hanyalah memastikan bahwa Anda tidak dapat memanggil kode IO di dalam kode lain yang antarmuka-nya dinyatakan tidak berkinerja IO. Analogi akan menjadi pemrogram bahasa dinamis yang mengeluh bahwa bahasa yang diketik secara statis seperti Java membuatnya sulit untuk mengembalikan jenis apa pun yang ia inginkan dari suatu metode, karena ia harus mengembalikan apa pun yang menurut jenis deklarasi akan dikembalikan.
Ben
9
Haskell adalah contoh bahasa fungsional murni, yang tidak memiliki kelemahan yang Anda katakan. Ini sebenarnya membuat berurusan dengan efek samping jauh lebih mudah, karena efek samping dienkapsulasi, dan memungkinkan programmer untuk mencapai tingkat abstraksi yang jauh lebih kuat daripada bahasa-bahasa penting ... Sungguh, semua orang harus mencoba Haskell, benar-benar memahami, dan menyadari mengapa begitu kuat.
FtheBuilder
202

Saya tidak berpikir bahwa ada pertanyaan tentang pendekatan fungsional untuk pemrograman "menangkap", karena sudah digunakan (sebagai gaya pemrograman) selama sekitar 40 tahun. Setiap kali seorang programmer OO menulis kode bersih yang menyukai objek yang tidak dapat diubah, kode itu meminjam konsep fungsional.

Namun, bahasa-bahasa yang menerapkan gaya fungsional sekarang mendapatkan banyak tinta virtual, dan apakah bahasa-bahasa itu akan menjadi dominan di masa depan adalah pertanyaan terbuka. Kecurigaan saya sendiri adalah bahwa bahasa hibrid, multi-paradigma seperti Scala atau OCaml kemungkinan akan mendominasi bahasa fungsional "purist" dengan cara yang sama seperti bahasa OO murni (Smalltalk, Beta, dll.) Telah mempengaruhi pemrograman utama tetapi belum berakhir sebagai notasi yang paling banyak digunakan.

Akhirnya, saya tidak dapat menahan diri untuk menunjukkan bahwa komentar Anda tentang FP sangat paralel dengan pernyataan yang saya dengar dari programmer prosedural beberapa tahun yang lalu:

  • Programmer "rata-rata" (mistis, IMHO) tidak memahaminya.
  • Itu tidak diajarkan secara luas.
  • Program apa pun yang Anda dapat menulis dengannya dapat ditulis dengan cara lain dengan teknik saat ini.

Sama seperti antarmuka pengguna grafis dan "kode sebagai model bisnis" adalah konsep yang membantu OO menjadi lebih dihargai secara luas, saya percaya bahwa peningkatan penggunaan keabadian dan paralelisme (masif) yang lebih sederhana akan membantu lebih banyak programmer melihat manfaat yang ditawarkan oleh pendekatan fungsional . Tetapi sebanyak yang telah kita pelajari dalam 50 tahun terakhir yang membentuk seluruh sejarah pemrograman komputer digital, saya pikir kita masih harus banyak belajar. Dua puluh tahun dari sekarang, pemrogram akan melihat kembali dengan takjub pada sifat primitif dari alat yang kami gunakan saat ini, termasuk bahasa OO dan FP yang sekarang populer.

joel.neely
sumber
55
Lihat saja 20 tahun yang lalu. Saya tidak berpikir pemrograman telah banyak berkembang. Yah punya alat yang lebih baik, mungkin bahasa baru atau 2 tetapi pada dasarnya tidak banyak yang akan berubah. Ini akan memakan waktu lebih dari 20 tahun. Kita semua pernah berpikir kita akan melihat mobil terbang pada tahun 2000. :)
bibac
32
O'Caml adalah orang Irlandia.
Defmeta
7
@ alex aneh: "Favour immutability" dan "menghindari efek samping" telah menjadi aturan praktis yang baik untuk sementara waktu di sekolah pemrograman berorientasi objek dan imperatif. (Jadi apa yang tidak disukai? ;-)
joel.neely
101
@ bibac: 20 tahun yang lalu kami menulis kode C, dan mendiskusikan manfaat Clipper atau Turbo Pascal. Orientasi Objek adalah bidang eksklusif akademisi. Mengusulkan bahwa sedikit yang telah berubah adalah benar-benar absurd.
Daniel C. Sobral
24
@Aniel: Tolong berikan daftar orang-orang ini yang berdebat untuk "jasa" Clipper. Mereka perlu diburu dan dibawa ke pengadilan.
David
125

Nilai tambah utama bagi saya adalah paralelisme inherennya, terutama karena kita sekarang bergerak menjauh dari lebih banyak MHz dan menuju lebih banyak core.

Saya tidak berpikir itu akan menjadi paradigma pemrograman berikutnya dan sepenuhnya menggantikan metode tipe OO, tapi saya pikir kita akan sampai pada titik bahwa kita perlu baik menulis beberapa kode kita dalam bahasa fungsional, atau bahasa tujuan umum kita akan tumbuh untuk memasukkan konstruksi yang lebih fungsional.

Steven Robbins
sumber
4
Kami sudah melihat ini terjadi. Dan itu akan terjadi lebih banyak di masa depan. Jadi saya setuju 100% pada poin ini.
Jason Baker
Masalahnya adalah bahwa aspek FP-sama-sama / tidak ada efek bersama yang membuatnya sangat cocok untuk paralelisme. Dan itu adalah aspek yang tidak sesuai dengan solusi OO - membuat hibrida yang efektif sangat sulit. Mungkin lem FP antara node OO?
James Brady
Untuk hibrida yang efektif, lihatlah cabang 2.0 dari bahasa pemrograman D. Ini adalah alfa / pekerjaan yang sedang berjalan, tetapi sedang menuju ke sana.
dsimcha
2
Saya menemukan jawaban ini menarik, saya tidak tahu bahasa fungsional, mengapa mereka dianggap lebih tepat untuk paralelisme?
andandandand
26
Karena tidak ada data bersama, fungsi tidak memiliki efek samping. Yang Anda pedulikan hanyalah nilai pengembalian. (Ini adalah ide yang cukup sulit bagi seorang OO / programmer prosedural untuk mendapatkan putaran kepalanya.) Oleh karena itu banyak fungsi dapat dipanggil sekaligus, selama output dari satu tidak digunakan sebagai input ke yang lain.
Tom Smith
79

Bahkan jika Anda tidak pernah bekerja dalam bahasa fungsional secara profesional, memahami pemrograman fungsional akan membuat Anda menjadi pengembang yang lebih baik. Ini akan memberi Anda perspektif baru pada kode dan pemrograman Anda secara umum.

Saya katakan tidak ada alasan untuk tidak mempelajarinya.

Saya pikir bahasa yang melakukan pekerjaan yang baik dengan menggabungkan gaya fungsional dan imperatif adalah yang paling menarik dan paling mungkin berhasil.

pengguna21714
sumber
Poin bagus, tapi saya ingin melihat penjelasan tentang "dengan cara apa itu akan membuat Anda menjadi pengembang yang lebih baik"
mt3
20
Paradigma pemrograman yang berbeda mendekati masalah dari sudut yang berbeda dan seringkali membutuhkan "cara berpikir yang berbeda" atau pola pikir. Dan melatih diri Anda dalam berbagai cara berpikir (menyiratkan pembelajaran mana yang harus digunakan dalam situasi mana ...) tidak pernah merupakan hal yang buruk.
RASHIr
56

Saya selalu skeptis tentang Hal Besar Berikutnya. Banyak kali Hal Besar Berikutnya adalah kecelakaan murni sejarah, berada di sana di tempat yang tepat pada waktu yang tepat tidak peduli apakah teknologinya bagus atau tidak. Contoh: C ++, Tcl / Tk, Perl. Semua teknologi cacat, semuanya sangat sukses karena mereka dianggap dapat memecahkan masalah saat ini atau hampir identik dengan standar yang sudah tertanam, atau keduanya. Pemrograman fungsional memang mungkin bagus, tetapi itu tidak berarti akan diadopsi.

Tetapi saya dapat memberi tahu Anda mengapa orang sangat tertarik dengan pemrograman fungsional: banyak, banyak programmer telah memiliki semacam "pengalaman konversi" di mana mereka menemukan bahwa menggunakan bahasa fungsional membuat mereka dua kali lebih produktif (atau mungkin sepuluh kali lebih produktif) saat memproduksi kode yang lebih tangguh untuk diubah dan memiliki lebih sedikit bug. Orang-orang ini menganggap pemrograman fungsional sebagai senjata rahasia; contoh yang baik dari pola pikir ini adalah Beating the Averages karya Paul Graham . Oh, dan lamarannya? Aplikasi web e-commerce.

Sejak awal 2006, ada juga beberapa buzz tentang pemrograman fungsional dan paralelisme. Karena orang-orang seperti Simon Peyton Jones telah mengkhawatirkan paralelisme dan setidaknya sejak 1984, saya tidak menahan napas sampai bahasa fungsional menyelesaikan masalah multicore. Tapi itu menjelaskan beberapa buzz tambahan saat ini.

Secara umum, universitas-universitas Amerika melakukan pekerjaan yang buruk dengan mengajarkan pemrograman fungsional. Ada inti dukungan yang kuat untuk mengajar pemrograman intro menggunakan Skema , dan Haskell juga menikmati beberapa dukungan di sana, tetapi ada sangat sedikit cara mengajarkan teknik canggih untuk programmer fungsional. Saya telah mengajar kursus seperti itu di Harvard dan akan melakukannya lagi di musim semi ini di Tufts. Benjamin Pierce telah mengajar kursus semacam itu di Penn. Saya tidak tahu apakah Paul Hudak telah melakukan sesuatu di Yale. Universitas-universitas Eropa melakukan pekerjaan yang jauh lebih baik; misalnya, pemrograman fungsional ditekankan di tempat-tempat penting di Denmark, Belanda, Swedia, dan Inggris. Saya kurang memahami apa yang terjadi di Australasia.

Norman Ramsey
sumber
Saya tidak tahu tentang universitas UK. Anda kemungkinan besar akan menemukan bahwa banyak universitas di sini mengajarkan sangat sedikit bahasa pemrograman (Java, C, mungkin Perl jika Anda beruntung). Masalahnya di sini adalah perbedaan kualitas, karena (beberapa) universitas terbaik memiliki program CS terbaik.
Mike B
Saya tidak setuju bahwa contoh yang Anda berikan cacat, mungkin niche, atau cocok untuk bidang tertentu, tetapi tujuan umum cukup untuk diambil secara universal tanpa kurva belajar yang besar. itu mungkin alasan terbesar mereka begitu sukses.
gbjbaanb
Saya melakukan Forth dan Lisp di uni di Inggris (serta Pascal, C, modula2 dan Cobol) tapi itu 20 tahun yang lalu ..
kpollock
29
Saya diajarkan Java / C ++ di uni (di Australia), tetapi beberapa rekan kerja saya pergi ke berbagai universitas di mana mereka mengerjakan beberapa unit di Haskell. Itu digunakan baik untuk pengantar pemrograman dan salah satu unit tahun terakhir mereka. Saya tertawa ketika saya mendengar apa yang dikatakan rekan kerja saya kepada seorang dosen Jawa setelah dia diperkenalkan untuk casting untuk pertama kalinya (pada titik ini dia hanya mengenal Haskell) - "Apa ?! Maksud Anda, Anda memiliki sesuatu dan Anda tidak t TAHU seperti apa itu ?! "
Jacob Stanley,
1
Lihatlah apa yang terjadi pada C # dengan semua orang Eropa di tim :)
Benjol
32

Saya tidak melihat ada yang menyebutkan gajah di kamar di sini, jadi saya pikir itu terserah saya :)

JavaScript adalah bahasa fungsional. Karena semakin banyak orang melakukan hal-hal yang lebih maju dengan JS, terutama memanfaatkan poin-poin yang lebih baik dari jQuery, Dojo, dan kerangka kerja lainnya, FP akan diperkenalkan oleh pintu belakang pengembang web.

Sehubungan dengan penutupan, FP membuat kode JS benar-benar ringan, namun masih dapat dibaca.

Ceria, PS

Psvensson
sumber
2
Itulah bagaimana saya benar-benar mulai menggali pemrograman fungsional. Tidak ada yang lebih baik daripada daftar Prototype.js. Setiap (fungsi (item) {}) atau seluruh metode operasi jQuery.
Cory R. King
20
Javascript memungkinkan seseorang untuk memprogram dengan cara fungsional. Namun, ini adalah bahasa paradigma lintas, yang memungkinkan seseorang untuk memprogram dalam berbagai cara yang berbeda (yang saya sukai, tapi itu tidak relevan) ... OO, fungsional, prosedural, dll.
RHSeeger
+1, lihat codex.sigpipe.cz/zeta
hanya seseorang
Metode objek jQuery hanya operasi di daftar monad. Mengambil objek yang mewakili wadah (atau urutan) sebagai input dan mengembalikan wadah objek sebagai output adalah contoh yang baik dari reinvention praktis fmap.
Jared Updike
25

Sebagian besar aplikasi cukup sederhana untuk dipecahkan dengan cara OO normal

  1. Cara OO tidak selalu "normal." Standar dekade ini adalah konsep terpinggirkan dekade lalu.

  2. Pemrograman fungsional adalah matematika. Paul Graham on Lisp (pemrograman fungsional pengganti untuk Lisp):

Jadi penjelasan singkat mengapa bahasa 1950-an ini tidak usang adalah bahwa itu bukan teknologi tetapi matematika, dan matematika tidak menjadi basi. Hal yang tepat untuk membandingkan Lisp bukanlah perangkat keras tahun 1950-an, tetapi, katakanlah, algoritma Quicksort, yang ditemukan pada tahun 1960 dan masih merupakan jenis tujuan umum tercepat.

Michael Paulukonis
sumber
25

Saya yakin Anda tidak tahu Anda pemrograman fungsional ketika Anda menggunakan:

  • Rumus Excel
  • Komposer Kuarsa
  • JavaScript
  • Logo (Turtle grafis)
  • LINQ
  • SQL
  • Underscore.js (atau Lodash), D3
Breton
sumber
10
Bagaimana Javascript dianggap pemrograman fungsional?
Pacerier
8
Ini memiliki fungsi kelas satu, fungsi tingkat tinggi, penutupan, fungsi anonim, aplikasi parsial, currying, dan komposisi.
daniel1426
2
Ha ha. Pernah menulis formula pembayaran Excel memuat yang lebih luas dari layar dengan fungsi bersarang. Saya agak tahu saat itu saya sedang pemrograman fungsional, tetapi belum tahu istilah itu.
ProfK
7
Silakan tambahkan C ke daftar itu
Mandeep Janjua
2
@ MandeepJanjua: Hah? Bagaimana bisa? Atau mengapa tidak bahasa apa pun?
Sz.
18

Programer korporat rata-rata, mis. Sebagian besar orang yang bekerja dengan saya, tidak akan memahaminya dan sebagian besar lingkungan kerja tidak akan membiarkan Anda memprogram di dalamnya

Yang itu hanya masalah waktu saja. Programer korporat rata-rata Anda mempelajari apa pun Big Thing saat ini. 15 tahun yang lalu, mereka tidak mengerti OOP. JIKA FP menangkap, "programmer perusahaan rata-rata" Anda akan mengikuti.

Itu tidak benar-benar diajarkan di universitas (atau saat ini?)

Bervariasi banyak. Di universitas saya, SML adalah bahasa pertama yang diperkenalkan oleh siswa. Saya percaya MIT mengajarkan LISP sebagai kursus tahun pertama. Dua contoh ini mungkin tidak representatif, tentu saja, tetapi saya percaya sebagian besar universitas paling tidak menawarkan beberapa program opsional tentang FP, bahkan jika mereka tidak menjadikannya bagian wajib dari kurikulum.

Sebagian besar aplikasi cukup sederhana untuk dipecahkan dengan cara OO normal

Ini sebenarnya bukan masalah "cukup sederhana". Apakah solusinya lebih sederhana (atau lebih mudah dibaca, kuat, elegan, berkinerja) di FP? Banyak hal yang "cukup sederhana untuk dipecahkan di Jawa", tetapi masih membutuhkan sejumlah besar kode.

Bagaimanapun, perlu diingat bahwa pendukung FP telah mengklaim bahwa itu adalah Hal Besar Berikutnya selama beberapa dekade sekarang. Mungkin mereka benar, tetapi perlu diingat bahwa mereka tidak ketika mereka membuat klaim yang sama 5, 10 atau 15 tahun yang lalu.

Namun, satu hal yang sangat penting bagi mereka adalah bahwa baru-baru ini, C # telah berbelok tajam ke arah FP, sampai-sampai secara praktis mengubah generasi pemrogram menjadi pemrogram FP, tanpa mereka sadari . Itu mungkin saja membuka jalan bagi "revolusi" FP. Mungkin. ;)

jalf
sumber
MIT dulu mengajarkan Skema dalam kursus intro CS-nya, tetapi sekarang menggunakan Python.
mipadi
1
"15 tahun yang lalu, mereka tidak mengerti OOP" - Masalahnya adalah 15 tahun yang lalu, mereka juga tidak mengerti FP. Dan mereka masih tidak melakukannya hari ini.
Jason Baker
15

Manusia tidak dapat memahami kesempurnaan dan ketidaksempurnaan dari seni yang dipilihnya jika ia tidak dapat melihat nilai dalam seni lain. Mengikuti aturan hanya memungkinkan pengembangan sampai pada titik dalam teknik dan kemudian siswa dan seniman harus belajar lebih banyak dan mencari lebih jauh. Masuk akal untuk mempelajari seni lain dan juga strategi.

Siapa yang belum belajar lebih banyak tentang diri mereka sendiri dengan menonton kegiatan orang lain? Untuk mempelajari pedang, pelajari gitar. Untuk mempelajari perdagangan studi pertama. Hanya mempelajari pedang akan membuat Anda berpikiran sempit dan tidak akan membiarkan Anda tumbuh keluar.

- Miyamoto Musashi, "Buku Lima Lingkaran"

shawndumas
sumber
12

Salah satu fitur utama dalam bahasa fungsional adalah konsep fungsi kelas satu. Idenya adalah Anda bisa meneruskan fungsi sebagai parameter ke fungsi lain dan mengembalikannya sebagai nilai.

Pemrograman fungsional melibatkan penulisan kode yang tidak mengubah status. Alasan utama untuk melakukannya adalah agar panggilan yang berurutan ke suatu fungsi akan menghasilkan hasil yang sama. Anda dapat menulis kode fungsional dalam bahasa apa pun yang mendukung fungsi kelas satu, tetapi ada beberapa bahasa, seperti Haskell, yang tidak memungkinkan Anda mengubah status. Bahkan, Anda tidak seharusnya membuat efek samping (seperti mencetak teks) sama sekali - yang kedengarannya sama sekali tidak berguna.

Haskell sebagai gantinya menggunakan pendekatan yang berbeda untuk IO: monads. Ini adalah objek yang berisi operasi IO yang diinginkan untuk dieksekusi oleh tingkat teratas penerjemah Anda. Pada tingkat lain mereka hanya objek dalam sistem.

Apa kelebihan yang disediakan pemrograman fungsional? Pemrograman fungsional memungkinkan pengkodean dengan potensi bug yang lebih sedikit karena setiap komponen sepenuhnya terisolasi. Juga, menggunakan rekursi dan fungsi-fungsi kelas satu memungkinkan untuk bukti sederhana kebenaran yang biasanya mencerminkan struktur kode.

Kyle Cronin
sumber
12

Saya tidak berpikir orang yang paling realistis berpikir bahwa pemrograman fungsional akan menangkap (menjadi paradigma utama seperti OO). Lagi pula, sebagian besar masalah bisnis bukan masalah matematika yang cantik, tetapi aturan imperatif untuk memindahkan data dan menampilkannya dalam berbagai cara, yang berarti itu tidak cocok untuk paradigma pemrograman fungsional murni (kurva belajar monad jauh melebihi OO.)

OTOH, pemrograman fungsional adalah apa yang membuat pemrograman menyenangkan. Ini membuat Anda menghargai keindahan yang tak terpisahkan dari ekspresi singkat dari matematika yang mendasari alam semesta. Orang mengatakan bahwa belajar pemrograman fungsional akan membuat Anda menjadi programmer yang lebih baik. Ini tentu saja sangat subyektif. Saya pribadi tidak berpikir itu sepenuhnya benar juga.

Itu membuat Anda menjadi makhluk yang lebih baik.

obecalp
sumber
6
Saya tidak berpikir bahwa OO secara inheren lebih mudah daripada FP. Itu benar-benar tergantung pada latar belakang Anda (saya seorang pria matematika, coba tebak apa yang saya temukan jauh lebih mudah? :) Sialan Anda orang-orang OO dan aturan gila Anda.
temp2290
14
Monad tidak sulit untuk dimengerti. Jangan membeli omong kosong itu.
Rayne
-1 OOP lebih sulit daripada FP
hanya seseorang
-1 Kami tidak akan menulis kompiler pengoptimalisasi menggunakan OCaml atau Haskell jika FP hanya sesuai untuk masalah matematika cantik.
gracchus
8

Saya harus padat, tapi saya masih belum mengerti. Apakah ada contoh nyata aplikasi kecil yang ditulis dalam bahasa fungsional seperti F # di mana Anda dapat melihat kode sumber dan melihat bagaimana dan mengapa lebih baik menggunakan pendekatan seperti itu daripada, katakanlah, C #?

Mike K.
sumber
Komentar bagus +1. @Mendelt: "lebih mudah diakses"? Apakah maksud Anda sakit kepala lebih cepat ketika Anda menonton kode?
Patrick Honorez
2
Lihat perpustakaan F # ini: quanttec.com/fparsec/tutorial.html . Saya ingin melihat kode sampel dalam C # dengan parser yang tampak setengah elegan dan dapat dibaca sebagai kode F #, bahkan jika mereka dikompilasi dengan instruksi yang sama. Dan coba porting FParsec dari F # ke C # dan lihat bagaimana kodenya membengkak.
Jared Updike
8

Saya akan menunjukkan bahwa semua yang Anda katakan tentang bahasa fungsional, kebanyakan orang mengatakan tentang bahasa berorientasi objek sekitar 20 tahun yang lalu. Saat itu sangat umum untuk mendengar tentang OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

Perubahan harus datang dari suatu tempat. Perubahan yang berarti dan penting akan terjadi tanpa memandang apakah orang yang terlatih dalam teknologi sebelumnya berpendapat bahwa perubahan tidak perlu. Apakah Anda pikir perubahan ke OO baik meskipun semua orang menentangnya pada saat itu?

RD1
sumber
2
* Rata-rata programmer perusahaan, mis. Sebagian besar orang yang bekerja dengan saya, tidak akan memahaminya dan sebagian besar lingkungan kerja tidak akan membiarkan Anda memprogramnya - Itu masih berlaku untuk OOP di banyak tempat saya pernah bekerja :) (tentu saja kata mereka mereka melakukan OOP, tetapi tidak)
tolanj
7

F # dapat menangkap karena Microsoft mendorongnya.

Pro:

  • F # akan menjadi bagian dari Visual Studio versi berikutnya
  • Microsoft sedang membangun komunitas untuk beberapa waktu sekarang - penginjil, buku, konsultan yang bekerja dengan pelanggan terkemuka, paparan signifikan pada konferensi MS.
  • F # adalah bahasa .Net kelas pertama dan ini adalah bahasa fungsional pertama yang datang dengan fondasi sangat besar (bukan berarti saya mengatakan bahwa Lisp, Haskell, Erlang, Scala, OCaml tidak memiliki banyak perpustakaan, mereka hanya tidak selengkap .Net adalah)
  • Dukungan kuat untuk paralelisme

Kontra:

  • F # sangat sulit untuk memulai bahkan jika Anda baik dengan C # dan .Net - setidaknya untuk saya :(
  • mungkin akan sulit untuk menemukan pengembang F # yang baik

Jadi, saya memberi kesempatan 50:50 pada F # untuk menjadi penting. Bahasa fungsional lainnya tidak akan membuatnya dalam waktu dekat.

zendar
sumber
6
Saya berpendapat bahwa Scala adalah fondasi yang cukup dalam dengan JRE.
cdmckay
2
Mengenai perpustakaan, itu benar-benar tergantung pada apa yang Anda lakukan. F # ditargetkan pada sektor keuangan dan juga berlaku untuk komputasi ilmiah tetapi OCaml sebenarnya memiliki perpustakaan yang jauh lebih baik untuk aplikasi seperti itu daripada .NET. Sebagai contoh, ketika saya datang ke F # dari OCaml saya gagal menemukan FFT yang layak dan akhirnya menulis (dan menjual) saya sendiri di C # dan kemudian F #.
Jon Harrop
1
LINQ adalah jembatan yang baik untuk menggunakan konsep fungsional dengan C # dan VB.Net ... Dan saya merasa itu jauh lebih menyakitkan untuk dibaca jika dibandingkan dengan F #
Matthew Whited
5

Saya pikir salah satu alasannya adalah bahwa beberapa orang merasa bahwa bagian terpenting dari apakah suatu bahasa akan diterima adalah seberapa baik bahasa itu . Sayangnya, hal-hal jarang begitu sederhana. Sebagai contoh, saya berpendapat bahwa faktor terbesar di balik penerimaan Python bukanlah bahasa itu sendiri (walaupun itu adalah sangat penting). Alasan terbesar mengapa Python begitu populer adalah perpustakaan standarnya yang besar dan komunitas perpustakaan pihak ke-3 yang lebih besar.

Bahasa seperti Clojure atau F # dapat menjadi pengecualian untuk aturan ini mengingat mereka dibangun di atas JVM / CLR. Akibatnya, saya tidak punya jawaban untuk mereka.

Jason Baker
sumber
+1 tetapi jangan lupa kekuatan pemasaran, dan fakta bahwa gunung kode warisan perusahaan Anda tidak akan berganti bahasa berdasarkan beberapa tren baru yang keren.
temp2290
Dan Anda lupa menyebutkan: Google mempopulerkan python.
Hao Wooi Lim
4

Sebagian besar aplikasi dapat diselesaikan di [masukkan bahasa, paradigma, dll. Favorit Anda di sini].

Meskipun, ini benar, alat yang berbeda dapat digunakan untuk menyelesaikan masalah yang berbeda. Fungsional hanya memungkinkan abstraksi tingkat tinggi (lebih tinggi?) Yang memungkinkan untuk melakukan pekerjaan kita lebih efektif bila digunakan dengan benar.

tylermac
sumber
4

Tampaknya bagi saya bahwa orang-orang yang tidak pernah belajar Lisp atau Skema sebagai sarjana sekarang menemukannya. Seperti halnya banyak hal dalam bidang ini, ada kecenderungan untuk hype dan menciptakan harapan tinggi ...

Itu akan berlalu.

Pemrograman fungsional sangat bagus. Namun, itu tidak akan mengambil alih dunia. C, C ++, Java, C #, dll akan tetap ada.

Apa yang akan datang dari ini saya pikir lebih banyak kemampuan lintas bahasa - misalnya menerapkan hal-hal dalam bahasa fungsional dan kemudian memberikan akses ke hal-hal itu dalam bahasa lain.

Tim
sumber
1
C # sekarang menjadi bahasa pemrograman fungsional (sebanyak Lisp) karena memiliki penutupan leksikal kelas satu. Memang, mereka sudah digunakan di WPF dan TPL. Jadi pemrograman fungsional jelas sudah ada di sini.
Jon Harrop
4

Saat membaca "Bahasa Pemrograman Mainstream Berikutnya: Perspektif Pengembang Game" oleh Tim Sweeney, Epic Games, pikiran pertama saya adalah - Saya harus belajar Haskell.

PPT

Versi HTML Google

Janis Veinbergs
sumber
3

Hal-hal telah bergerak dalam arah fungsional untuk sementara waktu. Dua anak baru yang keren dalam beberapa tahun terakhir, Ruby dan Python, secara radikal lebih dekat dengan bahasa fungsional daripada apa yang datang sebelum mereka - sangat banyak sehingga beberapa Lispers mulai mendukung satu atau yang lain sebagai "cukup dekat."

Dan dengan perangkat keras paralel besar-besaran yang memberikan tekanan evolusioner pada semua orang - dan bahasa fungsional di tempat terbaik untuk menghadapi perubahan - itu bukan lompatan seperti dulu untuk berpikir bahwa Haskell atau F # akan menjadi hal besar berikutnya.

Membuang
sumber
3

Apakah Anda mengikuti evolusi bahasa pemrograman belakangan ini? Setiap rilis baru dari semua bahasa pemrograman utama tampaknya meminjam semakin banyak fitur dari pemrograman fungsional.

  • Penutup, fungsi anonim, fungsi lewat dan kembali sebagai nilai yang digunakan untuk fitur eksotis yang hanya diketahui oleh peretas Lisp dan ML. Namun secara bertahap, C #, Delphi, Python, Perl, Javascript, telah menambahkan dukungan untuk penutupan. Tidak mungkin bahasa apa pun yang akan datang dianggap serius tanpa penutup.

  • Beberapa bahasa, terutama Python, C #, dan Ruby memiliki dukungan asli untuk pemahaman daftar dan daftar generator.

  • ML memelopori pemrograman generik pada tahun 1973, tetapi dukungan untuk obat generik ("parametrik polimorfisme") hanya menjadi standar industri dalam 5 tahun terakhir. Jika saya ingat benar, Fortran mendukung obat generik pada tahun 2003, diikuti oleh Java 2004, C # pada 2005, Delphi pada 2008. (Saya tahu C ++ telah mendukung templat sejak 1979, tetapi 90% diskusi tentang C ++ STL dimulai dengan "here there be demon" .)

Apa yang membuat fitur ini menarik bagi programmer? Itu harus jelas jelas: ini membantu programmer menulis kode yang lebih pendek . Semua bahasa di masa depan akan mendukung - setidaknya - penutupan jika mereka ingin tetap kompetitif. Dalam hal ini, pemrograman fungsional sudah dalam arus utama.

Sebagian besar aplikasi cukup sederhana untuk dipecahkan dengan cara OO normal

Siapa bilang tidak bisa menggunakan pemrograman fungsional untuk hal-hal sederhana juga? Tidak setiap program fungsional perlu menjadi kompiler, teorema, atau saklar telekomunikasi paralel masif. Saya secara teratur menggunakan F # untuk skrip sekali pakai ad hoc di samping proyek saya yang lebih rumit.

Juliet
sumber
3

Checkout Mengapa Masalah Pemrograman Fungsional

grom
sumber
Tautan tidak terbuka. Kesalahan 403.
Alexey Frunze
Ini mungkin pengganti yang baik? cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
canadiancreed
Tautan mati. Inilah sebabnya mengapa jawaban semacam ini tidak menguntungkan untuk dikutip dan dihubungkan.
Sylwester
Saya telah memperbaiki tautannya. @Sylwester itu benar, tetapi dokumen 23 halaman. Menyaring kertas untuk menjawab di situs ini tidak akan adil.
grom
2

Saya setuju dengan poin pertama, tetapi waktu berubah. Korporasi akan merespons, meskipun mereka adalah pengguna yang terlambat, jika mereka melihat bahwa ada keuntungan yang bisa didapat. Hidup itu dinamis.

Mereka mengajar Haskell dan ML di Stanford pada akhir 90-an. Saya yakin tempat-tempat seperti Carnegie Mellon, MIT, Stanford, dan sekolah-sekolah bagus lainnya menyajikannya kepada siswa.

Saya setuju bahwa sebagian besar aplikasi "mengekspos basis data relasional di web" akan berlanjut dalam jangka waktu yang lama. Java EE, .NET, RoR, dan PHP telah mengembangkan beberapa solusi yang cukup bagus untuk masalah itu.

Anda telah menemukan sesuatu yang penting: Ini mungkin masalah yang tidak dapat diselesaikan dengan mudah dengan cara lain yang akan meningkatkan pemrograman fungsional. Apa itu?

Akankah perangkat keras multicore besar dan komputasi awan mendorong mereka?

Duffymo
sumber
2

Karena FP memiliki manfaat signifikan dalam hal produktivitas, keandalan, dan pemeliharaan. Many-core dapat menjadi aplikasi pembunuh yang akhirnya membuat perusahaan besar untuk beralih meskipun kode legacy volume besar. Selanjutnya, bahkan bahasa komersial besar seperti C # mengambil rasa fungsional yang berbeda sebagai hasil dari banyak masalah inti - efek samping hanya tidak cocok dengan konkurensi dan paralelisme.

Saya tidak setuju bahwa programmer "normal" tidak akan memahaminya. Mereka akan, sama seperti mereka akhirnya mengerti OOP (yang sama misterius dan anehnya, jika tidak lebih).

Juga, sebagian besar universitas mengajarkan FP, bahkan banyak yang mengajarkannya sebagai kursus pemrograman pertama.

Sebastian
sumber
Maaf, tapi FP sudah ada hampir 3 kali lipat selama OOP. Ini sama sekali bukan masalah membutuhkan lebih banyak waktu. Butuh sesuatu yang lebih untuk membuat FP menjadi arus utama.
Jason Baker
Bagaimana Anda bisa melewatkan bagian dari posting saya di mana saya menjelaskan bahwa "sesuatu yang lebih" bisa sangat banyak inti? Dan sesuatu "berada di sekitar" tidak benar-benar relevan. Orang-orang memahami OOP karena menawarkan manfaat nyata pada saat itu, FP baru-baru ini menjadi praktis.
Sebastian
2

Wow - ini diskusi yang menarik. Pikiran saya sendiri tentang ini:

FP membuat beberapa tugas relatif sederhana (dibandingkan dengan bahasa non-FP). Bahasa None-FP sudah mulai mengambil ide dari FP, jadi saya curiga tren ini akan berlanjut dan kita akan melihat lebih banyak penggabungan yang seharusnya membantu orang membuat lompatan ke FP lebih mudah.

Pete OHanlon
sumber
2

Saya tidak tahu apakah itu akan cocok atau tidak, tetapi dari penyelidikan saya, bahasa fungsional hampir pasti layak untuk dipelajari, dan akan menjadikan Anda seorang programmer yang lebih baik. Hanya dengan memahami transparansi referensial membuat banyak keputusan desain menjadi jauh lebih mudah- dan program yang dihasilkan lebih mudah untuk dipikirkan. Pada dasarnya, jika Anda mengalami masalah, maka itu cenderung hanya menjadi masalah dengan output dari satu fungsi, bukan masalah dengan keadaan tidak konsisten, yang bisa disebabkan oleh salah satu dari ratusan kelas / metode / fungsi dalam bahasa imparatif dengan efek samping.

Sifat tanpa kewarganegaraan dari FP memetakan secara lebih alami ke sifat tanpa kewarganegaraan dari web, dan dengan demikian bahasa-bahasa fungsional lebih mudah digunakan untuk webapp yang lebih elegan dan RESTFUL. Kontras dengan kerangka kerja JAVA dan .NET yang perlu menggunakan HACKS jelek seperti VIEWSTATE dan SESI kunci untuk mempertahankan status aplikasi, dan mempertahankan abstraksi (kadang-kadang sangat bocor) dari bahasa imperatif stateful, pada platform fungsional dasarnya stateless seperti web.

Dan juga, semakin stateless aplikasi Anda, semakin mudah ia dapat meminjamkan dirinya ke pemrosesan paralel. Sangat penting bagi web, jika situs web Anda menjadi populer. Tidak selalu mudah untuk hanya menambahkan lebih banyak perangkat keras ke situs untuk mendapatkan kinerja yang lebih baik.

Breton
sumber
2

Pandangan saya adalah bahwa itu akan menangkap sekarang bahwa Microsoft telah mendorongnya lebih jauh ke arus utama. Bagi saya itu menarik karena apa yang bisa dilakukan untuk kita, karena itu adalah tantangan baru dan karena peluang kerja yang membenci masa depan.

Setelah dikuasai itu akan menjadi alat lain untuk lebih membantu membuat kita lebih produktif sebagai programmer.

Kacang
sumber
2

Poin yang terlewatkan dalam diskusi adalah bahwa sistem tipe terbaik ditemukan dalam bahasa FP kontemporer. Terlebih lagi, kompiler dapat menyimpulkan semua (atau setidaknya sebagian besar) tipe secara otomatis.

Sangat menarik bahwa seseorang menghabiskan separuh waktu menulis nama ketik saat pemrograman Java, namun Java sejauh ini tidak mengetik aman. Meskipun Anda mungkin tidak pernah menulis tipe dalam program Haskell (kecuali sebagai jenis kompilasi dokumentasi yang diperiksa) dan kodenya 100% aman.

Ingo
sumber
1

Selain jawaban yang lain, casting solusi dalam istilah fungsional murni memaksa seseorang untuk memahami masalah dengan lebih baik. Sebaliknya, berpikir dengan gaya fungsional akan mengembangkan keterampilan pemecahan masalah yang lebih baik.

* Entah karena paradigma fungsional lebih baik atau karena akan memberikan sudut serangan tambahan.

Rodrick Chapman
sumber