it-swarm-id.com

Mengapa pemrograman fungsional tidak lebih populer di industri? Apakah itu menangkap sekarang?

Selama empat tahun saya di universitas, kami telah menggunakan banyak pemrograman fungsional dalam beberapa bahasa pemrograman fungsional. Tetapi saya juga telah menggunakan banyak pemrograman berorientasi objek, dan pada kenyataannya saya lebih banyak menggunakan bahasa berorientasi objek ketika melakukan proyek kecil saya sendiri untuk mempersiapkan pekerjaan pertama saya. Tetapi saya sering berharap bahwa saya mengkode dalam bahasa pemrograman fungsional ketika melakukan proyek-proyek ini.

Namun, ketika mencari pekerjaan, sangat jarang untuk melihat pekerjaan di mana pengetahuan tentang bahasa pemrograman fungsional diperlukan.

Mengapa bahasa pemrograman fungsional lebih banyak digunakan di industri? Ada cukup banyak berita tentang bahasa pemrograman fungsional hari ini, jadi saya bertanya-tanya apakah pemrograman fungsional menarik di industri sekarang?

61
Jonas

Saya akan mengatakan bahwa salah satu alasan bahwa pemrograman fungsional tidak lebih lazim adalah kurangnya basis pengetahuan. Pengalaman saya adalah bahwa perusahaan sangat menolak risiko dalam hal menerapkan teknologi yang bukan arus utama dan lebih suka berinvestasi dalam kerangka kerja yang telah dicoba dan benar (Java, c ++, c #). Hanya ketika ada kebutuhan bisnis (seperti di Ericsson) yang dipertimbangkan paradigma baru. Tetapi bahkan dalam kasus Ericsson saya mendengar bahwa manajemen menuntut agar c ++ digunakan dan Joe Armstrong dipaksa untuk mengkode panggilan erlang di c ++ !! Ini harus menunjukkan bagaimana perusahaan yang enggan menerapkan teknologi baru!

38
ennuikiller

Saya adalah seorang profesor dan, seperti halnya programmer, profesor selalu mencari Hal Besar Berikutnya. Ketika mereka berpikir bahwa mereka telah menemukan satu, mereka membuatnya sebagai kereta musik, dan semua orang menumpuk. Karena mereka berkhotbah kepada siswa yang berpikir bahwa profesor harus benar-benar pintar, jika tidak, mengapa mereka menjadi profesor, mereka tidak mendapat perlawanan.

Pemrograman fungsional adalah semacam kereta musik. Tentu ada banyak pertanyaan menarik yang bagus untuk diselidiki, dan banyak artikel konferensi yang menarik untuk ditulis. Ini bukan ide yang sangat baru, dan Anda dapat melakukannya dengan bahasa modern apa pun, dan ide-ide tidak harus baru untuk menjadi menarik. Ini juga keterampilan yang baik untuk dimiliki.

Karena itu, pemrograman fungsional hanya satu panah yang ada di quiver Anda, bukan satu-satunya, sama seperti OOP bukan satu-satunya.

Daging sapi saya dengan akademisi sains komputer adalah kurangnya interaksi yang praktis dengan industri untuk menentukan apa yang sebenarnya masuk akal di dunia nyata, yaitu kontrol kualitas. Jika kontrol kualitas itu ada, mungkin ada penekanan yang berbeda, pada masalah klasifikasi dan rentang solusi untuk mereka, dengan pengorbanan, bukan hanya kereta musik terbaru.

67
Mike Dunlavey

Karena masalah terbesar dalam pengembangan perangkat lunak akhir-akhir ini adalah kemampuan mengelola kompleksitas. Ini bukan fokus dari sebagian besar bahasa pemrograman fungsional. Dengan demikian, bahasa yang do menjadikan itu prioritas (yaitu lebih populer OOP bahasa) cenderung hanya mencuri beberapa fitur keren yang keluar dari yang lebih akademis bahasa fungsional dan tetap di atas.

25
Fishtoaster

Pemrograman fungsional jelas mulai menangkap - perlahan tapi pasti.

Misalnya, startup yang saya bangun menggunakan bahasa fungsional (Clojure) sebagai bahasa pengembangan utama karena alasan berikut:

  • Produktivitas - belajar FP sulit, tetapi setelah Anda memahami itu sangat sulit dikalahkan dalam hal kekuatan dan ekspresi. Saya mungkin menulis sekitar 1/10 dari jumlah baris untuk mengimplementasikan fungsi apa pun yang diberikan dibandingkan dengan apa yang saya perlukan di C # atau Java

  • Keandalan - fungsi murni jauh lebih mudah untuk dipikirkan dan diuji daripada objek stateful. Karenanya Anda dapat menulis tes yang lebih baik dan memvalidasi kebenaran kode Anda dengan lebih mudah.

  • Konkurensi - bahasa fungsional menekankan keabadian, yang memiliki manfaat sangat besar untuk aplikasi bersamaan daripada harus berjalan secara efektif pada banyak core. Dan suka atau tidak, menjalankan banyak core adalah masa depan. Lihat http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey untuk penjelasan yang cemerlang tentang mengapa ini sangat penting

  • Kompabilitas/modularitas - bahasa fungsional tampaknya cocok untuk memasukkan komponen bersama-sama lebih mudah daripada sistem OO kompleks. Saya masih belum menemukan semua alasan untuk ini, tetapi sebagian darinya berasal dari kenyataan bahwa Anda tidak memiliki semua "kerumitan insidental" yang OO model seret dengan mereka. Ceramah tentang Kesederhanaan Radikal oleh Stuart Halloway mengeksplorasi ide-ide ini secara lebih mendalam.

[~ # ~] sunting [~ # ~] : Sebagai tanggapan terhadap komentar Despertar, sebuah contoh "kompleksitas insidental" dari OOP sistem yang membatasi modularitas adalah masalah dengan kloning mendalam vs kloning dangkal: Anda tidak dapat menyusun objek bersama dan membagikannya sebagai struktur komposit tanpa analisis yang sangat hati-hati tentang kloning dan semantik mutasi. Dalam kasus kecil ini dapat dikelola, tetapi dalam sistem yang kompleks itu dengan cepat menjadi masalah yang signifikan. Masalah ini tidak akan ada di tempat pertama jika Anda mengandalkan struktur data fungsional murni.

24
mikera

Kurangnya aplikasi pembunuh

Hei, yang ini terlihat segar. (Gali menggali Gali)

Saya pikir sebagian besar bahasa pemrograman berkembang dengan memiliki "aplikasi pembunuh" - sesuatu yang menarik yang eksklusif untuk bahasa (atau dilihat seperti itu). Ini bukan untuk mengatakan bahwa semua serapan adalah aplikasi itu , tetapi itu mendorong bahasa ke penerimaan yang lebih besar.

Inilah pandangan saya yang tidak terlalu akurat tentang niche apa yang mendorong adopsi beberapa bahasa yang kita miliki saat ini:

  • C: Bekerja di mana-mana (Ini adalah akhir 70-an dan 80-an)
  • C++: kerangka kerja GUI (awal 90-an)
  • Java: Applet dan servlets (di akhir tahun 90an)
  • Objective-C: aplikasi iOS (Sebelum itu, aplikasi OS X)
  • Ruby: Rails
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, dll.
  • Javascript: AJAX, terutama melalui kerangka kerja
  • lua: Game scripting, khususnya WoW

Selain itu, banyak bahasa yang dipatenkan telah masuk melalui organisasi penjualan yang kuat (Oracle, dan sedikit banyak bahasa Microsoft), yang secara efektif menciptakan ceruk mereka sendiri.

Satu catatan yang sangat penting tentang daftar itu: "Niche" bahasa, seperti yang ditunjukkan oleh aplikasi pembunuh, menjadi lebih dan lebih spesifik ketika beberapa dekade berlalu. Perhatikan yang terakhir dalam daftar: Game scripting , khususnya. Semakin sulit bagi bahasa untuk mendapatkan perhatian karena daftar hal-hal yang sudah dilakukan dengan cukup baik oleh bahasa lain.

Jadi, apa bahasa fungsional apa pun perlu benar-benar lepas landas adalah ceruk. Pada kenyataannya, belum ada bahasa fungsional yang besar, tetapi ada banyak di ceruk yang lebih kecil:

  • Emacs LISP: Penggunaan konstan sejak tahun 80-an di Emacs oleh pengembang. ( Hampir tidak pernah digunakan di tempat lain.)
  • Erlang: Di mana pun Anda ingin banyak agen bersamaan.
  • Skema: Pendidikan
  • APL/J/K: Keuangan (Sebut saja ini fungsional, demi argumen)
  • LISP Umum: "AI" - Ini adalah apa yang orang cenderung katakan itu digunakan untuk, yang merupakan berkah dan kutukan.

Sekarang, satu-satunya bahasa utama yang saya rasa tidak saya bahas dalam diskusi ini adalah Python. Python telah melakukan sesuatu yang sangat menarik; ia telah berhasil tanpa terlihat menjadi pemenang di ceruk utama apa pun. Ini dapat berarti saya salah untuk melihat popularitas bahasa dengan cara ini. Ini juga bisa berarti bahwa bahasa yang cukup baik dapat menjadi populer tanpa aplikasi pembunuh untuk mendorong adopsi dan penerimaan, tetapi sangat sulit dan mungkin membutuhkan waktu yang sangat lama. (Perl memiliki cerita yang sama, tetapi datang beberapa tahun sebelumnya dan sekarang memiliki lebih sedikit serapan.)

Dari sini, saya dapat mengatakan bahasa fungsional yang menurut saya sedang sedang naik daun:

  • Clojure: Pemrograman web, khususnya. melalui Heroku
  • Scala: Angkat (atau mungkin Main, hari ini) - JVM tanpa Java

Jika Anda bertanya kepada saya di mana mencari berikutnya untuk bahasa fungsional populer, saya akan mengatakan mencari bahasa fungsional dengan pengembangan cloud turnkey (a la Heroku atau GAE) atau pengembangan aplikasi turnkey mobile.

12
Jesse Millikan

Untuk alasan yang sama bahwa LISP tidak pernah benar-benar menarik perhatian (biarkan flamewars dimulai!). Pemrograman fungsional adalah paradigma yang sangat asing dibandingkan dengan pemrograman imperatif dan berorientasi objek. Jika, seperti sebagian besar siswa CS, Anda memulai dengan C dan berkembang ke C++/Java, Anda cenderung tidak ingin belajar berpikir dengan cara yang sepenuhnya ortogonal dengan cara yang biasanya Anda pikirkan.

9
Chinmay Kanchi

Mari kita pertimbangkan bisnis dan pemrograman.

Ada bisnis yang menggunakan perangkat lunak mereka sebagai aset strategis. Ini bukan tipikal. Bagi sebagian besar bisnis, TI adalah sesuatu yang mendukung bisnis nyata perusahaan. Itu biaya yang diperlukan. Mereka konservatif karena mereka tahu bahwa untuk $ X mereka bisa mendapatkan IT yang mereka butuhkan, sementara jika mereka beralih ke sesuatu yang berbeda mereka akan menghemat kurang dari $ X jika semuanya berjalan baik, dan kehilangan sangat besar jika semuanya berjalan buruk.

Selain itu, dalam bisnis, hal termurah yang harus dilakukan biasanya adalah apa yang mereka lakukan kemarin. Namun, perubahan yang diinginkan itu mahal. Jika sebuah perusahaan berubah dari, katakanlah, solusi C # /. NET, bahkan ke F #, mereka akan mengalami masalah. Pemrogram mereka (yang mungkin bukan pemrogram paling tajam di luar sana) harus belajar bahasa baru, dan mahir dalam keduanya, dan sering menggunakan keduanya. Akan ada rutinitas yang ditulis dalam keduanya untuk waktu yang lama. Jika mereka pindah ke sesuatu seperti Haskell, atau jika mereka menggunakan C++/MFC di tempat pertama, mereka akan berubah lebih banyak, dan itu akan jauh lebih mahal.

Juga, akan ada pasokan programmer C #, dan melanjutkan dukungan Microsoft, untuk waktu yang lama. Praktik TI saat ini dapat diandalkan. Tidak ada tingkat dukungan kelembagaan yang sama atau jaminan ketersediaan programmer yang berkelanjutan.

Oleh karena itu, untuk sebagian besar bisnis, membuat perubahan pada pemrograman fungsional akan mahal di muka, dan itu hanya akan membayar sendiri jika pengurangan biaya TI cukup dalam jangka panjang, kecuali bahwa jangka panjang berpotensi rapuh.

6
David Thornley

Anda sudah menulis kode dengan gaya fungsional, hanya saja Anda tidak mengetahuinya.

Ketika Anda diminta untuk membuat unit test untuk kode Anda, Anda cenderung menulis fungsi yang dapat diuji, yang tidak membuat atau bergantung pada efek samping, dan selalu mengembalikan hasil yang sama pada argumen yang sama (disebut fungsi murni). Ini adalah keunggulan utama dari program fungsional.

Saya pikir bahasa fungsional terlalu membatasi. Jadi, alih-alih mengganti bahasa imperatif dengan fungsional, bahasa imperatif akan mendapatkan fitur fungsional. Saat ini hampir setiap bahasa pemrograman memiliki penutup dan lambda.

2
Calmarius

Saya percaya hanya ada satu jawaban nyata untuk pertanyaan Anda. Anda dapat masuk ke banyak alasan terkait mengapa jawaban ini adalah masalahnya, tetapi itu adalah pertanyaan yang berbeda.

Ini dia:

  • Arsitek perangkat lunak memberikan solusi yang mereka yakin akan berhasil.
  • Mayoritas arsitek tidak bekerja dalam bahasa fungsional.
  • Setelah teknologi dan bahasa dipilih, bisnis menemukan orang yang dapat bekerja dengannya.

Apakah ini menangkap? Itu semua tergantung pada apakah orang yang percaya diri dalam menggunakan bahasa fungsional menjadi arsitek dan memilih untuk menggunakannya untuk proyek yang mereka kerjakan.

1
John Fisher

Masalah sebenarnya adalah negara.

Bahasa fungsional tidak memiliki status global. Sebagian besar masalah industri memerlukan keadaan dalam skala besar (bagaimana Anda mewakili buku besar atau satu set transaksi) bahkan jika beberapa fungsi dalam skala kecil tidak benar-benar memerlukannya (memproses buku besar).

Tapi kami menjalankan kode pada mesin arsitektur Von-Neuman yang secara inheren state-full. Jadi kita belum benar-benar menyingkirkan negara, bahasa fungsional hanya menyembunyikan kompleksitas negara dari pengembang. Ini berarti bahwa bahasa/kompiler harus berurusan dengan keadaan di belakang layar dan mengelolanya.

Jadi meskipun bahasa fungsional tidak memiliki status global, informasi status mereka dilewatkan sebagai parameter dan hasil.

Jadi pertanyaannya kemudian, dapatkah bahasa menangani negara secara efisien di belakang pengertian? Apalagi ketika ukuran data jauh melebihi ukuran arsitektur.

Melihatnya dari Sisi Hardware

OS telah banyak membantu dalam beberapa tahun terakhir dalam memvisualisasikan ruang alamat sehingga aplikasi tidak perlu khawatir tentang hal itu. Tetapi aplikasi yang tidak khawatir jatuh ke dalam perangkap meronta-ronta perangkat keras ketika tekanan memori menjadi intens (perangkat keras meronta-ronta akan memperlambat proses Anda untuk merangkak).

Karena programmer tidak mengarahkan kontrol atas keadaan dalam bahasa fungsional mereka harus bergantung pada kompiler untuk menangani ini dan saya belum melihat bahasa fungsional yang menangani ini dengan baik.

Di sisi sebaliknya, programmer state-full memiliki kontrol langsung atas keadaan dan dengan demikian dapat mengompensasi kondisi memori rendah. Meskipun saya belum melihat banyak programmer yang sebenarnya cukup pintar untuk melakukannya.

Dilihat dari sisi industri:

Industri memiliki banyak programer penuh negara yang tidak efisien.

Tetapi mudah untuk mengukur peningkatan dalam program-program ini dari waktu ke waktu. Anda melempar tim pengembang pada masalah mereka dapat meningkatkan kode dengan memperbaiki cara program menangani keadaan.

Untuk program fungsional perbaikan lebih sulit untuk diukur karena Anda perlu meningkatkan alat yang akan meningkatkan program (kami hanya melihat bagaimana aplikasi menangani keadaan yang mendasarinya secara efisien di sini, bukan keseluruhan perbaikan program ).

Jadi untuk industri, saya pikir ini berkaitan dengan kemampuan untuk mengukur peningkatan dalam kode.

Dari perspektif perekrutan

Ada banyak programmer stat-full yang tersedia untuk disewa. Pemrogram fungsional sulit ditemukan. Jadi model penawaran dan permintaan dasar Anda akan muncul jika industri beralih ke program gaya fungsional dan itu bukan sesuatu yang mereka inginkan (programmer cukup mahal seperti itu).

0
Martin York