Ada banyak argumen "teoretis" tentang mengapa pemrograman fungsional adalah ide yang bagus (terlalu banyak untuk itu tetap menjadi pertanyaan terbuka, dan memang benar demikian).
Namun, kebanyakan dari mereka adalah argumen yang dibuat dari teori ("keanggunan", dll ...), atau, yang ditujukan untuk pengembang.
Masalahnya adalah, kebanyakan dari mereka sama sekali tidak berguna ketika tujuan seseorang adalah untuk mempresentasikan ide tersebut kepada manajemen senior sebuah perusahaan besar , beberapa di antaranya bahkan bukan pengembang, dan semuanya kebanyakan peduli dengan argumen bisnis : biaya, manajemen sumber daya manusia , pengiriman produk, layanan klien dan pendapatan; serta fakta-fakta kuantitatif atas poin-poin teoretis yang tidak dapat didukung dengan fakta.
Adakah argumen kuat untuk diajukan untuk mengatasi masalah bisnis tersebut sejauh mempertimbangkan adopsi pemrograman fungsional sebagai konsep (bukan bahasa spesifik), vs. campuran khas prosedural / OOP, misalnya Java / C ++ / (Perl | Python) .
Lebih disukai, saya mencari argumen yang kuantitatif dan / atau berdasarkan penelitian atau studi kasus. Misalnya "menurut referensi ini, tingkat bug sistem multithreaded di Lisp / F # adalah 10% dari Jawa" atau "80% lulusan top yang mengekspresikan preferensi teknologi yang diinginkan bernama pemrograman fungsional sebagai atas 3 minat utama".
Saya tahu bahwa Graham mempresentasikan kasus penggunaan pemrograman fungsional untuk starup dan akan terbuka untuk beberapa argumennya dengan asumsi mereka dapat valid untuk perusahaan mapan yang lebih besar.
psI saya sangat menyadari bahwa Anda dapat melakukan sesuatu yang dekat dengan pemrograman fungsional dalam Perl, kemungkinan Python, dan (mungkin) bahkan Java 8 atau C ++ 14. Tetapi itu tidak berarti bahwa organisasi yang menggunakan Perl, C ++ atau Java akan mendukung fungsional vs OOP / pendekatan prosedural bahkan dalam bahasa-bahasa tersebut
Untuk keperluan bahasa ini, "besar" didefinisikan sebagai cukup besar untuk memiliki kelompok teknik / alat pengembangan khusus, yang menentukan apa yang semua pengembang boleh gunakan / lakukan; dan setidaknya ratusan pengembang di kelas bawah .