Apa argumen faktual yang baik untuk meyakinkan manajemen tingkat tinggi untuk mempertimbangkan pemrograman fungsional? [Tutup]


15

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 .


1
Anda mencari yang ini, saya kira? paulgraham.com/avg.html Sebenarnya, saya pikir artikel ini agak ketinggalan jaman, di antara banyak konsep fungsional telah memasuki bahasa mainstream.
Doc Brown

34
Mengapa manajemen tingkat tinggi peduli dengan bahasa pemrograman dan metode apa yang digunakan? Mengapa mereka dilibatkan dalam keputusan seperti itu? Tentunya itu masalah bagi manajer teknis?
High Performance Mark

8
@HighPerformanceMark: Ganti "manajer teknis" untuk "manajemen tingkat tinggi," dan evaluasi kembali pertanyaannya.
Robert Harvey

2
Bisnis apa yang sedang kamu jalani? Jika Anda melakukan pemrograman kontrak dan konsultasi, pemrograman fungsional mungkin merupakan kata kunci yang menurut manajemen akan mengesankan klien Anda.
JeffO

3
Argumen bisnis apa yang diberikan manajemen kepada Anda untuk bahasa yang Anda gunakan saat ini?
JeffO

Jawaban:


7

Ada satu argumen yang sangat sederhana, yang setidaknya bisa menghibur manajemen.

Sudah diketahui bahwa komputer modern tidak menjadi "lebih cepat" seperti dulu, karena penskalaan frekuensi, untuk saat ini, mencapai batasnya. Mereka meningkatkan potensi produktivitas mereka dengan menambahkan core.

Ini menyiratkan bahwa untuk mendapatkan manfaat paling banyak dari arsitektur ini, program harus diparalelkan. Tetapi pemrograman paralel jauh lebih sulit daripada pemrograman berurutan, karena banyak tantangan baru yang dibawanya (lihat artikel Wiki untuk tinjauan komprehensif).

Pemrograman fungsional membantu untuk menyingkirkan beberapa tantangan ini, misalnya kondisi balapan tidak berlaku jika Anda hanya menggunakan variabel dan metode yang tidak dapat diubah tanpa efek samping. Kurva belajar untuk pemrograman fungsional seringkali curam, tetapi kurva belajar untuk pemrograman paralel mungkin lebih curam, dan sama sekali tidak intuitif.

Jadi, jika tantangannya adalah untuk menulis program yang lebih efisien dengan cara yang lebih efisien, orang dapat membandingkan biaya pelatihan orang untuk menulis program paralel dengan biaya pelatihan orang untuk belajar pemrograman fungsional, dan risiko yang mungkin ditimbulkan oleh kedua pendekatan tersebut.

Mengenai bahasa campuran (yang mendukung gaya pemrograman fungsional dan imperatif): dari satu titik, mereka mungkin berguna untuk transisi (orang mungkin mulai menggunakannya dengan cara "akrab" dan secara bertahap mempelajari pendekatan baru). Dari titik lain, ini mungkin menjadi berkah tersembunyi, karena potensi keuntungan yang dibawa oleh pemrograman fungsional mungkin dibatalkan dengan kode seseorang yang canggung. Seseorang dapat mengurangi ini dengan membuat pedoman pengkodean yang jelas (lihat misalnya " Scala Efektif " oleh Twitter), meskipun mengikuti pedoman tersebut membutuhkan tingkat kematangan tim tertentu. Dari sudut pandang ini, bahasa fungsional murni mungkin "lebih mudah" untuk pengembangan perangkat lunak karena aturan yang lebih ketat yang diterapkan oleh desain.


Jika Anda dapat menemukan penelitian / bukti aktual untuk pernyataan ini untuk mendukungnya - terutama "Bahasa fungsional membantu untuk menyingkirkan beberapa dari tantangan ini" - sejauh ini siap untuk menjadi jawaban terbaik yang tersedia.
DVK


3
Kecuali bahwa banyak bahasa OOP mendukung pemrograman fungsional juga, sehingga Anda dapat menggunakan aspek fungsional dengan membuang bayi keluar dengan air mandi.
Andy

1
Benar, pertanyaannya adalah tentang "pemrograman fungsional" bukan tentang "bahasa fungsional". Akan mengubah kata-katanya.
Ashalynd

40

Anda mendekati ini dari sisi yang salah. Di sebagian besar perusahaan, manajemen tidak bertanggung jawab untuk "memilih paradigma pemrograman", mereka (atau setidaknya harus) bertanggung jawab untuk membuat tim bekerja secara efisien. Jika seluruh tim Anda yakin pemrograman fungsional akan meningkatkan kecepatan atau kualitas pekerjaan Anda, seharusnya tidak terlalu sulit untuk meyakinkan manajemen juga. Selain itu, jika tim Anda baru saja mulai menggunakan konstruksi fungsional dalam bahasa pemrograman Anda yang sudah mapan, dan semua orang senang dengan itu, Anda bahkan tidak perlu meminta izin (huh, non-programmer bahkan mungkin tidak memahami perbedaan antara non-programmer). konstruksi fungsional dan fungsional, jadi mengapa Anda ingin membahas masalah itu dengannya?).

Tetapi berhati-hatilah, jika anggota tim Anda yang lain memiliki pendapat yang berbeda tentang FP, dan mereka mulai mengeluh tentang kode fungsional Anda yang anggota tim lainnya tidak mengerti, Anda mungkin mengalami masalah dengan manajemen - untuk alasan yang baik, karena dalam suatu kasus, tim kehilangan efisiensi.

Jadi intinya adalah: meyakinkan anggota tim lain, atau pemimpin tim Anda, tetapi, bukan manajemen tingkat tinggi!

EDIT: karena komentar Anda - sebenarnya, ini adalah jawaban untuk pertanyaan Anda ;-). Satu argumen faktual yang saya bicarakan adalah "seluruh tim berpikir FP bermanfaat untuk melakukan pekerjaan itu . IMHO itulah argumen dengan peluang tertinggi untuk diterima oleh manajemen tingkat tinggi, dan ini sangat praktis dapat diterapkan. Mencoba menggunakan argumen teknis untuk orang-orang non-teknis secara langsung jarang bekerja, bukan karena mereka "terlalu bodoh untuk memahami alasan teknis", tetapi karena mereka cukup pintar untuk mengetahui bahwa keputusan teknis harus dibuat oleh para ahli teknis, dan mereka juga cukup pintar untuk tidak mengandalkan menurut pendapat hanya satu ahli.


7
Saya kagum bahwa 19 orang memilih jawaban yang tidak menjawab pertanyaan sama sekali . Ini pertanyaan praktis, dalam situasi praktis. Anggota tim TIDAK memiliki suara, dan tidak perlu diyakinkan. Mereka juga tidak akan berfungsi - dan saya juga tidak akan - pada teknologi / bahasa yang tidak disetujui, karena pertanyaannya menjadi sangat jelas.
DVK

1
@DVK jika tidak ada orang lain yang melihat kode Anda, maka Anda tidak perlu meyakinkan orang lain bahwa bahasa Anda baik. Mulai gunakan saja.
user253751

2
@DVK - Anda perlu memberikan lebih banyak wawasan tentang bagaimana manajemen mengendalikan bahasa yang digunakan di perusahaan Anda. Dalam kebanyakan kasus, manajemen memiliki sedikit masukan dalam bidang ini karena mereka menyerahkannya kepada tim dan pemimpin mereka.
JeffO

3
@DVK: Orang-orang yang menjawab pertanyaan yang mereka temukan paling membantu untuk menjawab pertanyaan. Jika sebagian besar orang memilih jawaban yang menyatakan Anda mendekati masalah yang salah, maka itu mungkin menyarankan sejumlah besar pemrogram untuk situasi yang sama dan menganggap "tidak dijawab" ini bermanfaat. Sebagian besar setuju bahwa ada sesuatu yang secara fundamental tidak sehat dalam bisnis Anda, dan itu tidak ada hubungannya dengan pilihan bahasa. Sebagian besar setuju bahwa itu perlu diatasi, setiap upaya untuk langsung setelah pilihan bahasa hanya akan membawa Anda ke kendala berikutnya, daripada serangkaian solusi.
Cort Ammon - Reinstate Monica

1
@CortAmmon Sementara saya dengan senang hati setuju bahwa pertanyaan menunjukkan ada yang salah dengan cara perusahaan penanya dikelola, sangat tidak mungkin dia dalam posisi untuk memperbaiki masalah seperti itu. Saya telah melihat sendiri masalah yang dapat ditimbulkan oleh CTO (pada kenyataannya, baru kemarin saya harus menghabiskan banyak waktu untuk mengatasi masalah yang disebabkan oleh aturan bahwa perusahaan kami tidak akan menggunakan perangkat lunak di luar "file program" "Direktori pada mesin Windows, tetapi Ruby tidak akan menginstal di direktori dengan spasi dalam namanya.
Jules

16

Untuk memahami mengapa Pemrograman Fungsional tidak mengambil alih dunia, Anda harus memahami pemikiran perusahaan di balik keputusan bahasa pemrograman. Untuk memilih Java sebentar:

  1. Ada pasukan programmer yang tersedia yang dapat menulis rim kode Java biasa. Ini tidak benar untuk programmer Lisp atau Haskell (atau bahkan Scala).
  2. Semua orang menggunakan Java, jadi pasti bagus. Corrolary: manajer tidak harus membenarkan pilihan mereka terhadap Java versus beberapa bahasa yang tidak dikenal yang tidak pernah ada dalam struktur perintah yang pernah didengar oleh siapa pun.

Jika organisasi Anda sudah bercokol di Kingdom of Nouns , membuat perubahan besar untuk Pemrograman Fungsional tidak akan terjadi. Pilihan bahasa (dan semua pilihan lain yang mengelilinginya) sudah sangat tertanam dalam budaya perusahaan.

Dengan asumsi tujuan Anda adalah untuk tumbuh sebagai pengembang perangkat lunak, taruhan terbaik Anda adalah untuk

  1. Menggabungkan konsep-konsep fungsional ke dalam program-program Anda saat ini di mana mereka berguna dan sesuai,
  2. Gunakan fitur bahasa fungsional baru saat ditambahkan ke bahasa, dan
  3. Pelajari pola desain berorientasi objek, beberapa di antaranya ada untuk mengatasi kekurangan bahasa dalam bahasa OO yang tidak ada dalam bahasa Fungsional.

Argumen Paul Graham benar-benar hanya berlaku untuk startup, dan ada sejumlah kisah peringatan tentang perusahaan yang awalnya menggunakan bahasa Fungsional murni, tetapi kemudian dibeli oleh perusahaan lain yang pesanan bisnis pertamanya adalah segera mengubah basis kode fungsional ke bahasa OO sehingga pengembang perangkat lunak yang ada bisa memahaminya.


1
Tidak, tujuan saya BUKAN (untuk keperluan pertanyaan ini) untuk "tumbuh sebagai pengembang perangkat lunak". Tujuan saya adalah untuk mengumpulkan serangkaian argumen terbaik untuk disajikan kepada orang-orang yang membuat keputusan, yang akan mempengaruhi mereka untuk mengizinkan FP sebagai pendekatan yang disetujui. Tidak lebih, dan tidak kurang. Soroti manfaat FP, terutama dibandingkan dengan OOP standar / tumpukan prosedural.
DVK

Juga, kecuali saya membuat kesalahan kata-kata yang besar, pertanyaan itu jelas tidak berarti menyinggung "perubahan besar-besaran" sebagai hasil yang dimaksudkan dari argumen yang dicari.
DVK

+1 untuk Kingdom of Nouns. Saya telah menyebutnya "The War Between Nouns and Verbs".
Rob

4
@DVK: Cara meyakinkan manajemen apa pun sudah sama sejak waktu dimulai: tunjukkan pada mereka bagaimana hal itu akan menghemat uang mereka.
Robert Harvey

9

Dalam pengalaman saya (agak sinis), pernah bekerja di toko tempat kami menggunakan pemrograman fungsional, dan mewawancarai beberapa orang lain:

  1. Selalu ada CTO dan orang-orang teknis tingkat tinggi lainnya yang memiliki pengalaman dengan pemrograman fungsional dan berhasil meyakinkan para eksekutif non-teknis itu. (Dan kebetulan, orang-orang ini lebih memenuhi syarat untuk menjawab pertanyaan Anda daripada saya.)
  2. Begitu orang-orang ini meninggalkan perusahaan, dan digantikan oleh orang-orang yang tidak memiliki kecenderungan ini, segalanya akan pergi ke selatan. Orang-orang baru akan menyalahkan segala sesuatu yang salah (termasuk, dan terutama kegagalan mereka sendiri) pada bahasa pemrograman aneh dan paradigma yang digunakan untuk membangun apa yang terjadi sebelumnya. Mereka akan meminggirkan orang-orang yang tersisa dengan keterampilan pemrograman fungsional, mendorong mereka keluar dari perusahaan. Sistem yang dibangun pada bahasa fungsional akan memburuk tanpa perawatan. Hal semacam ini, dalam pikiran saya, risiko terbesar yang dihadapi bisnis jika mereka mengadopsi bahasa fungsional, dan tidak boleh diremehkan.
  3. Organisasi harus memiliki budaya "membangun alih-alih membeli" agar ini berfungsi. Karena mengadopsi bahasa fungsional berarti lebih sedikit opsi "beli".
  4. Hampir selalu ada beberapa kompromi terhadap para pencela ide teknis dan non-teknis. Yang paling umum dari kompromi ini adalah bahwa bahasa non-JVM hanya karena pertimbangan; Clojure dan Scala diusulkan, Haskell dan O'Caml baru saja lolos.

4

Hal-hal yang perlu dipertimbangkan untuk manajemen tingkat atas ketika / jika manajemen tingkat atas terlibat dalam memilih bahasa pemrograman (yang aneh, mereka harus menyerahkannya kepada orang-orang yang dapat dipercaya dan berpengetahuan (baik teknologi dan cerdas bisnis):

  • Produktifitas
    • Baik karyawan saat ini dan masa depan
    • Semua peran (arsitek, pengembang, penguji, OP, ...)
  • Platform yang didukung
    • Sistem operasi, (perangkat keras?)
  • Penerbit bahasa / platform
    • Lisensi
  • Kematangan bahasa / platform
    • Dukungan dari / oleh penerbit dan / atau komunitas
    • Perpustakaan
  • Bermigrasi basis kode saat ini
    • Atau integrasi dengan

Perhatikan bahwa ini tidak spesifik untuk bahasa pemrograman fungsional. Ini juga bukan argumen kecuali Anda memberikan data ini. Kami tidak dapat memberi Anda data karena sepenuhnya bergantung pada lingkungan bisnis Anda. Satu-satunya hal yang bisa kami lakukan adalah mengumpulkan data dari web untuk menunjukkan seberapa banyak pengetahuan dan minat untuk bahasa tertentu. Hati-hati saat menerjemahkan banyak pertanyaan di StackOverflow atau banyak tag di Linkedin ke dalam bahasa yang sedang populer.


1
Bisnis juga khawatir tentang mempekerjakan orang, jadi jika lebih sulit untuk mengganti pengembang fungsional saya akan mengatakan itu alasan yang baik bagi mereka untuk terlibat dalam keputusan seperti itu.
Andy

1
@Andy - Ya, itu sebabnya saya tidak menyangkal pertanyaan dan saya pikir manajer harus tertarik dengan topik yang saya nyatakan. Kekhawatiran saya kurang lebih bahwa solusi (Bahasa Pemrograman Fungsional) dipilih SEBELUM masalah (???) didefinisikan.
Erno

Apakah benar-benar sulit untuk mengganti pengembang fungsional? Dengan jumlah pengembang informasi yang memposting di sini dan di situs lain di Internet, saya menduga ada lebih banyak pengembang fungsional daripada yang dipikirkan manajer.
Giorgio

@Giorgio - Saya tidak pernah mengatakan bahwa itu sulit untuk menggantikan mereka tetapi saya pengalaman saya ketersediaannya dapat berbeda dari satu lokasi ke lokasi lainnya. Beberapa lulusan perguruan tinggi bahkan tidak pernah belajar dasar-dasar sedangkan beberapa universitas mengkhususkan diri di dalamnya. Untuk bisnis, sangat penting untuk melihat jangka panjang dan kebutuhan yang diharapkan dari karyawan baru.
Erno

@ Erno: Saya setuju dengan pandangan Anda. Saya mengomentari komentar Andy. Bagaimanapun, saya selalu berasumsi bahwa ada sangat sedikit programmer fungsional dan bahwa FP dipandang sebagai sesuatu yang esoteris. Akhir-akhir ini kesan saya adalah bahwa ada lebih banyak pengembang FP daripada pekerjaan FP.
Giorgio

3

Saya pikir argumen atau fakta tidak akan membantu. Dan tentu saja bukan tanpa menyatakan masalah yang ingin Anda pecahkan.

Terhadap kepercayaan umum dan evaluasi diri yang khas, banyak keputusan dibuat berdasarkan firasat. Dan seringkali keputusan ini adalah keputusan yang sangat baik, karena mereka menggabungkan pada tingkat bawah sadar banyak pengalaman dari individu yang membuat keputusan.

Jika Anda ingin menentang keputusan seperti "Kami akan tetap menggunakan bahasa seperti C sampai akhir semua komputer" Anda harus melakukan lebih dari sekadar memberikan beberapa argumen.

Langkah pertama mungkin untuk mengungkap orang dan alasan di balik keputusan bahwa manajemen senior harus mengatakan dalam keputusan teknis tersebut. Tentu saja saya hanya bisa menebak di sini, tetapi sangat mungkin mereka memiliki rekam jejak keputusan yang dibuat oleh pribadi teknis yang buruk. Mari kita hadapi: Kebanyakan pengembang tidak pandai membuat keputusan (bahkan teknis) di tingkat perusahaan.

Setelah Anda menemukan orang-orang ini berbicara kepada mereka untuk mendapatkan kepercayaan di sana. Mungkin pendekatan terbaik adalah: dengarkan mereka. Apa yang mereka khawatirkan, apa risiko dan peluang yang mereka lihat. Masalah apa yang mereka hadapi. Dari sini Anda mungkin bergerak untuk melibatkan orang-orang teknologi ke dalam keputusan semacam ini. Manajemen sering kali tidak benar-benar ingin membuat keputusan ini, tetapi tidak memercayai orang lain dengannya. Jadi, jika tim Anda mulai terlibat dalam keputusan arsitektur dan menunjukkan bahwa keputusan yang Anda usulkan adalah manajemen yang baik mungkin bersedia mempercayai Anda / tim Anda.

Penting untuk menghasilkan keputusan arsitektur yang baik adalah:

  • Kumpulkan masukan dari pemegang saham (Manajemen, Pengguna, Administrator, Penjualan, Klien ...)
  • Mendasarkan keputusan pada input itu
  • Berkomunikasi dengan jelas: Apa keputusan (yang diusulkan) itu; Risiko apa yang ingin mereka mitigasi; Apa kepentingan yang bertentangan dan dengan penundaan: seberapa baik mereka bekerja.

Jika Anda bekerja untuk perusahaan besar dengan karyawan 10K + katakan, bersiaplah untuk belajar beberapa pelajaran berikut.

  • kecepatan pengkodean tidak benar-benar relevan untuk intinya.
  • hal-hal seperti rawatan pada skala dekade adalah.
  • masalah yang Anda pikir dapat Anda selesaikan dengan menggunakan bahasa fungsional tidak benar-benar relevan untuk intinya
  • masalah seperti melatih 1000 pengembang, resistensi alami untuk mengubah dan mempertahankan basis kode yang ditulis oleh pengembang dengan kurang dari 5 tahun pengalaman dalam teknologi yang digunakan adalah.

Setelah Anda mencapai tingkat kepercayaan bahwa argumen Anda didengar dan dipertimbangkan, Anda juga akan membentuk cara untuk mengumpulkan dan mempertimbangkan persyaratan yang Anda, tim, dan manajemen percayai.

Jika proses ini menghasilkan rekomendasi untuk menggunakan pendekatan fungsional di bidang-bidang tertentu Anda selesai.

Jika proses ini menghasilkan rekomendasi untuk mengabaikan pendekatan fungsional yang melampaui apa yang ditawarkan oleh bahasa pemrograman utama saat ini, Anda juga telah selesai.

Berita buruknya adalah: Bergantung pada ukuran dan gaya perusahaan, ini mungkin dengan mudah memakan waktu beberapa tahun atau beberapa dekade.

Berita baiknya adalah: Anda akan belajar banyak di jalan.

Karena langkah pertama adalah mulai berbicara dan terutama mendengarkan manajemen senior, saya sarankan mulai dengan membaca Just Listen .


3

Salah satu pendekatan yang baik adalah menunjukkan bahwa itu menunjukkan hasil yang baik di industri dan diadopsi.

Anda bisa mendapatkan beberapa data dari:

Idealnya, cobalah berbicara dengan para manajer di beberapa perusahaan terbuka, terutama jika di industri Anda, dan dapatkan angka dan testimonial dari mereka.

Google memiliki banyak tautan serupa lainnya untuk Haskell, OCaml, dll.


3
Beberapa perusahaan akan melihat ini sebagai kasus yang menentang, karena praktisi OO melebihi jumlah penganut FP dengan selisih yang lebar .
Robert Harvey

1
@ RobertTarvey - itu sedikit argumen ikan merah, setidaknya dalam kasus khusus saya. Mereka sudah cukup pintar untuk mengetahui ITU. Apa yang mereka TIDAK tahu (dan apa yang saya temukan dari jawaban ini) adalah bahwa Eaton Vance menggunakan Skema dan yang lebih penting, Faceboook , BoA / ML, Deutsche Bank dan Google [gunakan Haskell]. Berarti, itu adalah sesuatu yang mereka BISA pertimbangkan untuk mencelupkan jari kaki, karena orang lain memutuskan untuk melakukannya. Luar biasa bahwa satu-satunya jawaban yang benar-benar berguna yang mencoba menjawab pertanyaan yang saya ajukan (dan bukan orang yang merasa ingin menjawab) adalah jawaban dengan suara terbanyak
DVK

1
@dvk: Pertanyaan yang Anda tanyakan (jika saya memahaminya dengan benar) adalah "Bagaimana saya meyakinkan atasan saya bahwa FP adalah hal yang baik?" Terkadang tidak. Kita hidup di dunia yang bisa berubah, dan Pemrograman Fungsional, sejujurnya, sedikit aneh. Jika Anda tidak percaya kepada saya, lihatlah pada monad. Jawaban yang membahas keanehan ini (dan bagaimana pengaruhnya terhadap desain dan proses pengembangan perangkat lunak) berguna, baik menurut Anda atau tidak.
Robert Harvey

@RobertHarvey (1) Saya mengambilnya kembali. Sekarang DUA dari jawaban yang bermanfaat diberi nilai terendah :) (yang baru diposkan dapat diperbaiki dengan fakta tetapi merupakan awal yang baik).
DVK

@RobertHarvey - ya. Pertanyaannya BUKAN "Apakah FP itu hal yang baik" atau "Apakah mungkin meyakinkan orang FP adalah hal yang baik". Pertanyaannya sangat tepat "Argumen mana yang dapat digunakan untuk mendukung KAPAN mencoba meyakinkan itu adalah hal yang baik". Itu BUKAN "Bagaimana saya bisa secara diam-diam memperkenalkan FP ke dalam pekerjaan saya / coding dengan cara yang positif" baik, itulah yang Anda jawab - jika itu adalah opsi yang saya tidak akan meminta di tempat pertama, saya akan coding: )
DVK

2

Anda datang pada ini dari arah yang salah.

Anda sedang mencoba meyakinkan manajemen untuk beralih ke paradigma fungsional untuk hiburan Anda sendiri dan Anda sedang mencoba menyuarakan argumen untuk mendukung ini yang tidak ada hubungannya dengan alasan sebenarnya mengapa Anda menginginkannya. Kalau tidak, Anda tidak perlu mengajukan pertanyaan, karena Anda dapat membuat daftar argumen dari atas kepala Anda.

Sebaliknya, apa yang harus Anda pikirkan adalah apa yang dibutuhkan oleh bisnis saat ini dan bagaimana hal itu dilayani dengan sebaik-baiknya. Jika itu terjadi maka sebaiknya disajikan menggunakan paradigma fungsional maka - yay! - kamu bisa bermain. Tetapi jika Anda melakukan analisis yang adil, dengan mempertimbangkan kebutuhan bisnis operasional, pelatihan yang diperlukan dari rekan kerja, latar belakang programmer masa depan, pemeliharaan, dan sebagainya, sering kali tidak.


2
Ini agak rumit, dan tidak terlalu membantu dalam menjawab pertanyaan, yang harus diabstraksi agar tidak hanya membantu OP dalam "pendekatannya".
VF1

1

Manajemen senior tanpa keterampilan teknis seharusnya tidak memedulikan aspek teknis seperti penggunaan paradigma fungsional. Ini bukan bidang keahlian mereka, dan mencium manajemen mikro. Mengapa mereka tidak mendelegasikan keputusan itu kepada orang-orang yang sebenarnya memiliki keterampilan yang dibutuhkan?

Makhluk ini dikatakan, berikut adalah beberapa petunjuk untuk meyakinkan orang-orang dengan latar belakang teknis (kasus pertama) dan mereka yang tidak memiliki satu (kasus kedua).

Kasus pertama

Jika Anda berbicara dengan orang yang tahu pemrograman , membandingkan kode yang ditulis tanpa paradigma pemrograman fungsional dan kode yang sama yang ditulis dengan gaya fungsional mungkin cukup meyakinkan:

Contoh kode C # yang menggunakan gaya imperatif:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Kode yang sama ditulis ulang dengan pemrograman fungsional dalam pikiran:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Kemudian tanyakan pada mereka:

  1. Berapa banyak kesalahan yang bisa dilakukan seorang programmer dalam sampel pertama? Bagaimana dengan yang kedua?

  2. Seberapa sulitkah untuk menemukan kesalahan?

  3. Seberapa sulitkah untuk memodifikasi kode?

Ketiga faktor tersebut mempengaruhi produktivitas, dan juga biaya produk.

Kasus kedua

Jika Anda berurusan dengan orang-orang yang tidak tahu pemrograman, tidak ada banyak hal teknis yang bisa Anda sampaikan kepada mereka. Salah satu cara untuk meyakinkan adalah untuk menunjukkan dampak aktual dari paradigma fungsional pada pekerjaan Anda dan pekerjaan rekan kerja Anda.

Misalnya, bandingkan dua proyek yang dibuat oleh tim yang sama, satu menggunakan FP, yang lain tidak menggunakannya. Menunjukkan bahwa jumlah bug jauh lebih rendah atau ini adalah proyek pertama yang sebenarnya dikirimkan perusahaan tepat waktu harus cukup meyakinkan.


3
Saya melihat apa yang telah Anda lakukan di sana, tetapi teladan Anda tidak sepenuhnya meyakinkan. Pada dasarnya Anda telah membuka contoh fungsional Anda menjadi keharusan, yang bukan sesuatu yang akan terjadi dalam masalah perusahaan praktis. Anda yield returnsedikit curang, ini menjadi contoh bagaimana Anda akan menyiapkan kode untuk digunakan dalam skenario Linq, dan ifpernyataan Anda dapat ditulis lebih ringkas dengan operator ternary. Semua contoh pertama Anda dapat di refactored menjadi fungsi imperatif, sehingga kompleksitasnya tersembunyi.
Robert Harvey

@RobertHarvey Anda bisa mengubah contoh pertama menjadi sekelompok fungsi imperatif, tetapi mereka akan menjadi fungsi imperatif khusus yang khusus untuk kueri itu; Anda masih harus melihat semuanya untuk meyakinkan diri Anda bahwa kueri itu benar. Refactoring itu akan meledakkan ukuran kode imperatif lebih jauh juga. Bahkan jika Anda bisa menulisnya dengan kompak, Anda masih harus membaca kode dengan hati-hati karena semua pekerjaan dilakukan melalui efek samping; Anda tidak akan mau ketinggalan efek samping yang dilakukan di bagian kedua dari operator ternary di akhir saluran.
Doval

1
@RobertHarvey Saya bahkan tidak yakin bahwa kedua cuplikan kode tersebut setara, karena yang penting "menyaring" dengan membuat daftar kedua alih-alih hanya melewatkan iterasi. Bukankah setara nyata hanya menggunakan satu loop dan dengan demikian menjadi lebih dalam?
Doval

5
Tidak ada pertanyaan bahwa Anda membuat kasus yang baik untuk menggabungkan konsep-konsep fungsional dalam bahasa imperatif / OO, tetapi tidak selalu merupakan kasus yang baik untuk menggunakan bahasa yang sepenuhnya fungsional dalam lingkungan perusahaan yang sudah imperatif / OO.
Robert Harvey

Lain (mungkin kurang valid) masalah dengan contoh Anda: Saya bisa menulis contoh pertama dalam Perl sebagian besar dapat dibaca-non-FP di - Saya menduga - 30% dari volume. Mungkin kurang. Tergantung pada apakah Anda menerima map/ grepsebagai non-FP. TKI, Anda mengajukan argumen bahwa Java adalah bahasa yang buruk, bukan bahwa FP adalah pendekatan yang baik.
DVK
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.