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


61

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?


3
Sampai batas tertentu, saya tidak setuju dengan premis pertanyaan Anda. Fitur bahasa yang terinspirasi oleh "bahasa fungsional" sedang ditambahkan ke bahasa seperti Java dan JavaScript. Sebenarnya, JavaScript selalu (dalam beberapa hal) bahasa fungsional, meskipun banyak orang tidak menyadarinya sampai saat ini.
MatrixFrog

1
@ MatrixFrog: Orang mungkin bertanya, "Mengapa berfungsi hanya setengah jalan dengan menambahkan beberapa konsep fungsional ke bahasa non-fungsional alih-alih mengadopsi bahasa FP penuh? Setelah semua paradigma telah ada selama bertahun-tahun dan sangat matang."
Giorgio

dunia tidak beralih ke alternatif yang unggul (dan FP murni adalah alternatif yang unggul) untuk alasan yang berbeda termasuk kompatibilitas ke belakang, inersia dll. Pertimbangkan tata letak keyboard DVORAK: lebih efisien untuk pengetikan sentuh tetapi kita semua terjebak dengan QWERTY hanya karena ada begitu banyak perangkat lunak dengan pintasan qwerty-friendly.
KolA

Jawaban:


38

Saya akan mengatakan bahwa salah satu alasan bahwa pemrograman fungsional tidak lebih lazim adalah kurangnya basis pengetahuan. Pengalaman saya adalah bahwa perusahaan sangat menentang risiko dalam hal menerapkan teknologi yang bukan arus utama dan lebih suka berinvestasi dalam kerangka kerja yang sudah terbukti 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!


9
Bagaimana pemrograman fungsional dengan cara apa pun 'baru'?
Evan Plaice

7
Saya pikir maksudnya 'tidak digunakan' dan bukan 'baru'.
Vinko Vrsalovic

10
Jadi tidak digunakan ... karena tidak digunakan? Hm
Alex Baranosky

21
@ Alex - Tepat. Menyebalkan, bukan?
KeithS

5
@ Stargazer712: Apa alasannya? Saya tahu banyak pengembang yang tidak tahu pemrograman fungsional, jadi ketidaktahuan masuk akal bagi saya. Apakah pemrograman fungsional memiliki kegagalan besar di masa lalu yang menjauhkan industri dari yang tidak saya sadari?
Sean McMillan

67

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 untuk diselidiki, dan banyak artikel konferensi yang menarik untuk ditulis. Ini bukan ide yang sangat baru, dan Anda dapat melakukannya di hampir semua bahasa modern, 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 praktis dengan industri untuk menentukan apa yang sebenarnya masuk akal di dunia nyata, yaitu kontrol kualitas. Jika kontrol kualitas ada di sana, mungkin ada penekanan yang berbeda, pada masalah klasifikasi dan rentang solusi untuk mereka, dengan pengorbanan, bukan hanya kereta musik terbaru.


1
Ini komentar yang sangat bagus. +1 ke panah di quiver Anda, dan rentang solusi dengan pengorbanan.
user21007

2
+1 untuk QC. Itu MSc akan jauh lebih berguna dengan mata pelajaran khusus yang meliputi pengujian, tinjauan kode, kompleksitas kode dan sejenisnya. Mampu memverifikasi secara otomatis bahwa program melakukan apa yang seharusnya setelah tambalan terakhir bernilai sejumlah "itu harus bekerja sekarang" omong kosong bergelombang tangan.
l0b0

5
@ l0b0: Terima kasih, meskipun sebenarnya saya memikirkan kontrol kualitas dari apa yang diajarkan dan bagaimana caranya. Karena itu, para profesor CS hanya mengajarkan apa yang menurut mereka paling menarik bagi mereka. Bandingkan dengan teknik, di mana ada interaksi dengan industri, atau kedokteran, di mana relevansi dunia nyata sangat tinggi. IME, CS profs memperkirakan dunia nyata akan melakukan pengajaran tentang hal-hal penting di dunia nyata, tetapi para siswa tidak mau belajar - mereka ingin sekali mencari tahu apa yang paling membuat para profesional bersemangat.
Mike Dunlavey

@ Mike: hampir semua bahasa modern? Apakah Anda termasuk C ++ dan Java?
kevin cline

+1. Tidak bisa mengatakannya sendiri dengan lebih baik.
riwalk

25

Karena masalah terbesar dalam pengembangan perangkat lunak saat ini adalah kemampuan untuk mengelola kompleksitas. Ini bukan fokus dari sebagian besar bahasa pemrograman fungsional. Dengan demikian, bahasa yang melakukan membuat prioritas (yaitu bahasa OOP lebih populer) cenderung hanya mencuri beberapa fitur pendingin yang keluar dari bahasa fungsional lebih akademis dan sebagainya tetap di atas.


48
Saya tidak setuju. Bahasa pemrograman fungsional mencoba untuk meminimalkan penggunaan negara, dan dengan itu menjadi kurang kompleks. Program yang diprogram dalam bahasa fungsional juga lebih mudah untuk diuji dan diperbaiki.
Jonas

7
@Jonas: banyak programmer merasa sangat sulit untuk menulis program menggunakan hampir tidak ada keadaan sama sekali (termasuk saya). Dari sudut pandang itu, sebenarnya lebih kompleks. (Harap dicatat bahwa saya tidak memperdebatkan kegunaan pemrograman fungsional dengan cara apa pun!)
ShdNx

3
@ ShdNx: Ya, saya tahu. Bahkan saya pikir pemrograman fungsional itu sulit ketika saya pertama kali mempelajarinya di universitas. Tetapi setelah beberapa saat saya mulai lebih suka untuk pemrograman imperatif dan OOP lebih spesifik. Di universitas saya pemrograman fungsional diajarkan sebelum pemrograman imperatif dan siswa yang belum melakukan pemrograman sebelum universitas berpikir bahwa pemrograman imperatif sangat sulit pada awalnya dan pemrograman fungsional lebih dekat dengan matematika.
Jonas

16
Ada perbedaan antara kesulitan dan kompleksitas. OOP jelas lebih sulit daripada pemrograman terstruktur karena ia menambahkan lebih banyak konsep. Untuk jumlah kode yang cukup besar, mereka mengurangi kerumitan dengan menyediakan struktur pada kode. FP adalah hal yang sama: jika Anda hanya menulis dua baris sepertinya berlebihan, tetapi jika kode Anda cukup besar maka penataan kode sebagai subunit stateless meningkatkan skalabilitas dan mengurangi kompleksitas kode.
Muhammad Alkarouri

6
Salah satu penekanan utama pemrograman fungsional adalah kompabilitas. Jika itu bukan alat untuk mengelola kompleksitas, saya tidak tahu apa itu.
dan_waterworth

23

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 itu sulit, tetapi begitu Anda terbiasa, sangat sulit dikalahkan dalam hal kekuatan dan ekspresif. 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 berbarengan daripada harus berjalan secara efektif pada banyak core. Dan suka atau tidak, berjalan di beberapa core adalah masa depan. Lihat http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey untuk penjelasan yang cemerlang tentang mengapa ini sangat penting

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

EDIT : Menanggapi komentar Despertar, contoh "kerumitan insidental" dari sistem OOP yang membatasi modularitas adalah masalah dengan kloning mendalam vs kloning dangkal: Anda tidak dapat menyusun objek bersama-sama dan membagikannya sebagai struktur komposit tanpa analisis yang cermat tentang semantik kloning dan 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.


+1, saya akan sangat tertarik mendengar proses pengambilan keputusan Anda tentang mengapa Anda memilih Clojure. (Aku bukan untuk atau anti Clojure, aku hanya tertarik).
dan_waterworth

4
"belajar FP itu sulit": Mempelajari paradigma apa pun itu sulit. Saya ingat berapa jam saya habiskan dengan kode imperatif (Pascal) sebelum saya memiliki cukup pengalaman untuk menjadi cukup produktif. Saya pikir FP kurang dikenal karena banyak programer belajar bahasa imperatif terlebih dahulu dan begitu mereka belajar bagaimana memprogram mereka tidak punya waktu untuk melihat sesuatu yang lain. Saya seorang programmer C ++ penuh waktu dan saya saat ini belajar Scala di malam hari setelah bekerja. Jika saya memiliki keluarga yang harus dijaga, saya bisa melupakannya.
Giorgio

1
Saya pikir 3 yang pertama adalah kasus yang bagus, namun saya tidak setuju dengan yang ke 4. OOP sangat modular dan komposisi; bagi saya ini adalah salah satu kekuatan terbesarnya. Ini juga hebat dalam menyembunyikan kompleksitas melalui enkapsulasi dan abstraksi.
Despertar

1
@Iorgio. Persis. "Belajar FP itu sulit, belajar OOP itu mudah" sama absurdnya dengan "Belajar bahasa Spanyol itu sulit tetapi bahasa Cina itu mudah". Itu tergantung mana bahasa pertama Anda. Dan saya tidak memilih bahasa Cina sebagai analog sewenang-wenang untuk OOP - karena idiom OO seperti hieroglif: mudah dipelajari satu per satu tetapi sulit untuk mengingat semuanya dan mustahil untuk menulis. FP jauh lebih mirip bahasa dengan alfabet: huruf terpisah tidak berguna dalam isolasi tetapi memungkinkan untuk menulis apa pun dengan seperangkat aturan yang cukup kecil
KolA

1
(lanjutan) jadi mengapa itu tidak populer - belum - karena alasan yang sama. Hieroglif ada jauh sebelum alfabet pertama diciptakan dan dimatangkan. Mungkin diperlukan generasi lain yang memiliki tulisan dan membaca alfabet maksud saya FP sebagai paradigma pertama mereka
KolA

12

Kurangnya aplikasi pembunuh

Hei, yang ini terlihat segar. (gali 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 bahwa aplikasi, tetapi itu melaju bahasa untuk 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, terutama 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 ini fungsional, demi argumen)
  • Common Lisp: "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; itu telah berhasil tanpa terlihat menjadi pemenang di ceruk utama mana pun. Ini bisa berarti bahwa 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 serupa, tetapi datang beberapa tahun sebelumnya dan sekarang memiliki lebih sedikit serapan.)

Dari sini, saya bisa mengatakan bahasa fungsional mana yang menurut saya 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 harus mencari bahasa fungsional populer berikutnya, saya akan mengatakan mencari bahasa fungsional dengan pengembangan cloud turnkey (a la Heroku atau GAE) atau pengembangan aplikasi turnkey mobile.


Saya akan menganggap Perl bahasa utama juga. Ini adalah bahasa yang lebih tua yang menurut saya paling sering digunakan dengan sistem mirip Unix. Meskipun Python tampaknya menjadi alternatif yang lebih modern. Ini masih merupakan bahasa populer yang telah mendapat banyak perhatian dan memiliki komunitas besar.
Despertar

1
@Despertar - Saya tidak berusaha sangat keras untuk menjadi egaliter tentang bahasa yang saya sebutkan :) Dan setuju, ceritanya tampak sangat mirip dengan Python, kecuali beberapa tahun di masa lalu.
Jesse Millikan

1
Perl memang memiliki beberapa relung. Yang paling awal tercermin dalam versi dokumentasi yang lebih lama, yang merujuk pada namanya sebagai akronim untuk "bahasa ekstraksi praktis dan pelaporan". Kedua datang sedikit kemudian, dan CGI scripting - selama bertahun-tahun, perl adalah yang bahasa web. Jelas sudah kehilangan banyak popularitas itu sekarang, tetapi lihatlah situs web lama yang masih berjalan pada perangkat lunak yang sama dengan yang mereka buat sebelumnya, dan Anda akan melihat banyak perl (saya memikirkan slashdot.org, sekarang juga , tetapi ada beberapa lagi).
Jules

9

Untuk alasan yang sama bahwa Lisp tidak pernah benar-benar memahaminya (biarkan flamewar 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.


2
Paradigma asing? Ini lebih dekat dengan matematika daripada pemrograman imperatif. Di sini, di Swedia, saya berpikir bahwa kebanyakan siswa CS di universitas adalah pemrograman fungsional pertama. Misalnya kita mulai dengan ML Standar, sebelum C, Erlang dan Java.
Jonas

4
Cukup adil. Saya tahu bahwa banyak mahasiswa teknik di Inggris dan India diajarkan C pertama, diikuti oleh C ++ dan / atau Java. Seringkali mereka tidak diajarkan bahasa fungsional sama sekali.
Chinmay Kanchi

14
@Jonas Bagi sejumlah orang di luar sana, matematika adalah paradigma alien dan apa pun yang membuat pemrograman lebih jauh dari matematika membuatnya lebih mudah untuk dipahami.
scriptocalypse

5
Saya pernah mendengar tentang orang yang belum pernah mendengar tentang pohon, apalagi pemrograman fungsi, setelah lulus.
dan_waterworth

1
@ Tux-D, sebenarnya, tidak, saya sedang berbicara tentang siswa di Inggris.
dan_waterworth

6

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 dengan 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.


2

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.


1

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.


0

Masalah sebenarnya adalah negara.

Bahasa fungsional tidak memiliki status global. Sebagian besar masalah industri memerlukan keadaan pada skala besar (bagaimana Anda mewakili buku besar atau 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 statusnya 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 mengendalikan langsung 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 seiring waktu. Anda melempar tim pengembang pada masalah mereka dapat meningkatkan kode dengan meningkatkan 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 perbaikan keseluruhan 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 pemrograman gaya fungsional dan itu bukan sesuatu yang mereka inginkan terjadi (programmer cukup mahal seperti itu).


2
Bahasa fungsional, terutama bahasa fungsional "tidak murni", dapat menangani keadaan global dengan sangat baik. Saya menemukan bahwa sering program terurai menjadi lapisan bolak-balik: misalnya, keadaan global ... tetapi transisi keadaan fungsional ... dengan keadaan lokal (tertutup) sesekali untuk mengimplementasikan bagian-bagian kritis kinerja dari transisi tersebut, dll. Masalah dengan bahasa imperatif , IMO , adalah bahwa mereka sering mengarahkan programmer untuk menggunakan negara secara tidak tepat, ketika pola fungsional akan bekerja lebih baik. Tetapi bahasa tampaknya berevolusi ke arah yang mendukung kedua gaya dengan baik.
Ryan Culpepper

1
Sangat mudah untuk berurusan dengan keadaan dalam bahasa fungsional, tetapi membutuhkan perubahan penekanan. Sedangkan dalam bahasa imperatif Anda menulis prosedur yang mengubah keadaan, dalam bahasa fungsional Anda menulis fungsi yang mengembalikan prosedur yang mengubah keadaan.
dan_waterworth

"Bahasa fungsional tidak memiliki status global" - Anda tidak perlu status global. Hampir semua manajemen negara dapat dilakukan melalui monad.
Arunav Sanyal

-3

Pertanyaan ini memiliki premis yang sedikit salah. Karena alasan berikut:

  1. Pemrograman fungsional sebenarnya cukup umum di industri. Tapi itu hanya digunakan ketika programmer berpengalaman tersedia. Pemula tidak bisa diharapkan mengetahuinya. Hampir semua proyek pemrograman besar menggunakannya, tetapi mereka hanya menyimpannya di area yang ditangani oleh programmer berpengalaman. Pemula akan berurusan dengan modul mudah yang tidak memerlukan pemrograman fungsional.
  2. Dengan kenyataan ini, perusahaan yang mempekerjakan orang (biasanya yang muda dari universitas) tidak dapat benar-benar meminta pengalaman pemrograman fungsional. Siapa pun dalam proyek yang memerlukan pemrograman fungsional telah berada di perusahaan yang sama selama 15 tahun.
  3. Universitas mulai mengajarkannya, karena mereka tahu sekarang bahwa pengetahuan pemrograman fungsional akan sangat berguna dalam 30 tahun. Rentang waktu mereka dalam 30 tahun, bukan setengah tahun normal seperti di perusahaan.
  4. Poin-poin ini adalah alasan mengapa orang kecewa ketika mereka memasuki dunia kerja dan melihat bahwa hal-hal yang mereka pelajari di universitas tidak digunakan. Tetapi mereka dirancang untuk jangka waktu 30 tahun, dan itu akan bermanfaat pada akhirnya - hanya saja perusahaan menggunakan hal-hal sederhana - hal-hal yang mereka harapkan orang tahu.
  5. Anda juga akan menjadi sombong jika Anda berpikir setelah beberapa tahun di universitas, Anda tahu pemrograman fungsional cukup baik untuk menggunakannya dalam proyek perangkat lunak yang sebenarnya. Mulai dari hal-hal sederhana terlebih dahulu. Anda tidak benar-benar perlu melakukan perangkat lunak yang paling kompleks sebagai tugas pertama Anda ketika Anda mulai bekerja. Anda akhirnya akan sampai pada hal-hal yang rumit, tetapi butuh waktu.

2
1) "hampir semua proyek pemrograman besar menggunakannya". Pengalaman saya adalah bahwa ini jauh dari kenyataan. Sangat sedikit perusahaan yang menggunakan pemrograman fungsional seperti yang saya tahu. Sebagian besar hanya menggunakan Java dan C # (meskipun C # memiliki konstruksi fungsional lebih banyak dalam beberapa tahun terakhir), C ++ dan C.
Jonas

2
2) Pengalaman saya adalah sebaliknya. Orang-orang dari universitas tampaknya menjadi satu - satunya yang tahu pemrograman fungsional. Di sini di Swedia, sebagian besar universitas mengajarkan pemrograman fungsional sejak tahun pertama. Dan universitas seperti MIT sampai saat ini telah menggunakan pemrograman fungsional dalam kursus pemrograman pertama mereka (Skema).
Jonas

@jonas: tidak, bahasa pemrograman tidak ada hubungannya dengan itu. Tentu saja C dan C ++ dan java dll digunakan oleh sejumlah besar proyek. Pemrograman fungsional juga bekerja dalam kode c ++. Praktek saat ini tampaknya bagian dari proyek menggunakan OO dan sebagian lagi menggunakan pemrograman fungsional. Kedua bagian menggunakan bahasa yang sama (biasanya c / c ++)
tp1

Ya, Anda juga bisa melakukan OO di C. Tapi itu tidak disarankan. C dan C ++ tidak memiliki banyak konstruksi untuk pemrograman fungsional, misalnya tidak dapat diubah secara default, tidak ada dukungan yang baik untuk pencocokan pola, tidak termasuk struktur data yang tidak dapat diubah dan sebagainya ...
Jonas

Nah, itu sebabnya dibutuhkan programmer yang berpengalaman. Karena sangat tidak mungkin untuk mengubah bahasa pemrograman dari yang umum, hal terbaik berikutnya adalah melakukan pemrograman fungsional dalam c ++. Juga c ++ memiliki hal-hal seperti const yang banyak membantu.
tp1

-10

Karena lebih sulit untuk men-debug FP.


11
Saya tidak setuju. Tanpa efek jaminan proses debug lebih mudah. Mungkin Anda berpikir itu lebih sulit karena paradigma fungsional berbeda dan perlu pengalaman untuk merasa nyaman dengan cara baru untuk melakukan sesuatu, termasuk debug.
Maniero

2
Bahasa pemrograman fungsional sebenarnya lebih mudah untuk diuji, karena fungsi murni tidak bernegara.
Jonas

4
Jonas, saya tidak mengatakan "test", saya mengatakan "debug" yaitu. menemukan kesalahan yang Anda buat. Pengujian adalah bagian dari itu, tetapi begitu juga alasan tentang program, dll. Masalah besar - Saya mendukung ini. Ini adalah fungsi dari kekuatan FP. Semakin banyak pekerjaan yang dilakukan oleh baris kode tertentu, semakin sulit untuk melihat baris kode mana yang menyebabkan masalah. Pemetaan antara garis kode, dan efek, misalnya lebih tersebar. satu fungsi tingkat tinggi dapat menyentuh lusinan perilaku program dan sebaliknya. Gejala-gejalanya dapat sangat bervariasi di antara titik-titik berbeda untuk kesalahan yang sama.
interstar

Dalam pengalaman saya tidak sulit untuk debug sama sekali. Saya menggunakan F # dan saya tidak dapat menemukan alasan mengapa Anda akan merasa lebih sulit untuk melakukan debug daripada C # misalnya. Mungkin debugging lebih sulit di Haskell karena kemalasan (saya tidak tahu), tetapi pemrograman FP bersemangat lebih sederhana karena kewarganegaraan seperti kata Jonas. Dengan kata lain, kode FP lebih mudah diprediksi karena Anda tahu hasilnya tidak dipengaruhi oleh variabel yang tidak terlihat.
Muhammad Alkarouri

2
Selama fungsi Anda murni, debugging itu mudah. Jika Anda tidak dapat men-debug dengan menambahkan unit-test maka Anda tidak melakukan pekerjaan yang cukup untuk menulis tes.
dan_waterworth
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.