İşlevsel programlama neden henüz ele geçirilmedi?


197

Açıklayıcı / fonksiyonel programlama (diller) hakkında bazı metinler okudum, Haskell'i denedim ve kendim yazdım. Gördüğüm kadarıyla, fonksiyonel programlamanın klasik zorunluluk stiline göre birkaç avantajı vardır:

  • Vatansız programlar; Yan efektleri olmayan
  • Eşzamanlılık; Yükselen çok çekirdekli teknoloji ile son derece iyi çalışır
  • Programlar genellikle daha kısadır ve bazı durumlarda okunması daha kolaydır
  • Verimlilik artar (örnek: Erlang)

  • Zorunlu programlama çok eski bir paradigmadır (bildiğim kadarıyla) ve muhtemelen 21. yüzyıl için uygun değildir

İşlevsel dilde yazılmış programlar veya programlar neden hala "nadir"?

İşlevsel programlamanın avantajlarına bakarken neden zorunlu programlama dillerini kullanıyoruz?

Belki 1990'da bunun için çok erken, ama bugün?


1
NOT: Bu soru meta üzerinde en az iki kez tartışılmıştır ve fikir birliği, yukarıda belirtilen "tarihsel önem" kilidi ile arşivlense de, saklanması gerektiğidir . Bunu, bu soru hakkında başka bir sıkıcı tartışmaya katılmak, yanıtların tadını çıkarmak ve işlerine devam etmek zorunda kalmamaya teşekkür etmek için bunun kilidini açmaya göz kulak olan herkesi şiddetle tavsiye ediyorum.
Shog9

Yanıtlar:


530

Çünkü tüm bu avantajlar dezavantajlardır.

Vatansız programlar; Yan efektleri olmayan

Gerçek dünyadaki programlar tamamen yan etkiler ve mutasyonla ilgilidir. Kullanıcı bir düğmeye bastığında bunun nedeni bir şey olmasını istiyor. Bir şey yazdıklarında, bu durumun eskiden var olan herhangi bir durumun yerini almasını isterler. Muhasebede Jane Smith evlendiğinde ve adını Jane Jones olarak değiştirdiğinde, maaşını basan iş sürecini destekleyen veritabanı, bu tür bir mutasyonu ele almakla ilgili daha iyi olurdu. Makineli tüfeği uzaylıya ateşlediğinizde, çoğu insan zihinsel olarak bunu daha az isabet puanına sahip yeni bir uzaylı yapımı olarak modellemez; bunu mevcut bir uzaylı mülkünün mutasyonu olarak modelliyorlar.

Programlama dili kavramları temel olarak modellenen alana karşı çalıştığında, o dili kullanmayı haklı çıkarmak zordur.

Eşzamanlılık; Yükselen çok çekirdekli teknoloji ile son derece iyi çalışır

Sorun çözüldü. Değişmez veri yapıları ile, muhtemelen eski verilerle çalışmanın pahasına, ucuz iplik güvenliği elde edersiniz. Değişken veri yapıları ile verileri tutarlı tutmak için karmaşık mantık yazmak zorunda kalmadan daima taze veriler üzerinde çalışmanın avantajına sahip olursunuz. Bunlardan birinin açıkça diğerinden daha iyi olduğu gibi değil.

Programlar genellikle daha kısadır ve bazı durumlarda okunması daha kolaydır

Okumak daha uzun ve zor olduğu durumlar hariç. İşlevsel bir tarzda yazılmış programların nasıl okunacağını öğrenmek zor bir beceridir; insanlar programların bir dizi hesaplama yerine bir reçete gibi izlenecek bir dizi adım olarak tasarlanmasında çok daha iyi görünüyorlar.

Verimlilik artar (örnek: Erlang)

İşlevsel bir tarzda nasıl programlanacağını bilen programcıların işe alınmasının büyük masrafını haklı çıkarmak için verimlilik çok artar.

Ve unutmayın, bir çalışma sistemini atmak istemezsiniz; çoğu programcı yeni sistemleri sıfırdan inşa etmiyor, aksine çoğu işlevsel olmayan dillerde inşa edilmiş mevcut sistemleri sürdürüyor. Bunu hissedarlara haklı göstermeye çalıştığınızı düşünün. Milyonlarca dolar karşılığında yeni bir tane oluşturmak için neden mevcut çalışma bordro sisteminizi kazıyordunuz? "Çünkü fonksiyonel programlama harika" hissedarları memnun etmek olası değildir.

Zorunlu programlama çok eski bir paradigmadır (bildiğim kadarıyla) ve muhtemelen 21. yüzyıl için uygun değildir

Fonksiyonel programlama da çok eskidir. Kavramın yaşının ne kadar alakalı olduğunu görmüyorum.

Beni yanlış anlamayın. Fonksiyonel programlamayı seviyorum, bu ekibe katıldım çünkü fonksiyonel programlamadan kavramları C # 'a getirmek istedim ve bence değişmez bir tarzda programlamanın geleceğin yolu olduğunu düşünüyorum. Ancak, işlevsel bir tarzda programlamanın, sadece arzu edilemeyecek kadar büyük maliyetleri vardır . Daha işlevsel bir tarza geçiş, on yıllar boyunca yavaş ve kademeli olarak gerçekleşecektir. Ve işte bu olacak: Haskell'in saflığının ve güzelliğinin toptanlığını ve C ++ 'ın terk edilmesini değil, daha işlevsel bir stile doğru bir geçiş.

Yaşamak için derleyiciler inşa ediyorum ve kesinlikle yeni nesil derleyici araçları için fonksiyonel bir stili kucaklıyoruz. Çünkü fonksiyonel programlama temelde karşılaştığımız problemler için iyi bir eşleşme. Sorunlarımız tamamen ham bilgileri - dizeleri ve meta verileri - almak ve bunları farklı dizelere ve meta verilere dönüştürmektir. Mutasyonların meydana geldiği durumlarda, örneğin IDE'ye yazdığı gibi, problem alanı doğal olarak kendisini sadece ağacın değişen bölümlerini artımlı olarak yeniden inşa etmek gibi fonksiyonel tekniklere borçludur. Birçok alan, işlevsel bir stile açıkça uygun hale getiren bu güzel özelliklere sahip değildir .


41
"Muhasebede Jane Smith evlendiğinde ve adını Jane Jones olarak değiştirdiğinde, maaşını basan iş sürecini destekleyen veritabanı, bu tür bir mutasyonu ele almakla ilgili daha iyi olurdu." Jane Smith'in eski adı bir rekor olacak, Jane'in eski adının tüm örneklerini yeni adıyla geriye dönük olarak güncellemiyoruz;)
'16

40
@ Juliet: Tabii. Demek istediğim, bir çalışanı temsil eden bir nesneniz varsa, "çalışanın adını değiştir" işleminin, nesne kimliğini değiştirmeyen çalışanı temsil eden nesnenin mutasyonu olduğunu düşünmek mantıklıdır . Jane Smith adını değiştirdiğinde, Jane Jones adında farklı bir çalışan yaratmazsınız , aksi takdirde aynıdır. İki farklı isme sahip iki çalışan yok. Bu süreci yeni bir nesnenin inşası olarak değil, bir nesnenin mutasyonu olarak modellemek doğaldır.
Eric Lippert

24
Bu iyi bir cevap, ama zaman zaman davanızı abarttığınızı düşünüyorum. Juliet'in dediği gibi, insanlar bunu bir isim değişikliği olarak düşünebilse de, gerçekten daha derin bir isim değiştirme. Fonksiyonel programları (çünkü insanların okuması için zor olabilir rağmen olduğu öğrenilebilir bir beceridir) daha uzun çünkü o genelde değil. Bir Haskell programı neredeyse her zaman bir Java programından çok daha kısa olacaktır - hatta birçok doğal durumu olan "kötü uyum" alanında bile.
Chuck

29
+1 Bu cevabı okumak o kadar temiz bir nefesdi ki. Böyle bir pragmatizmi (fonksiyonel programlama için altta yatan tutkuyla) konumunuzdaki birinden duymak harika.
Dhaust

11
"Çünkü tüm bu avantajlar dezavantajlar. Vatansız programlar; Yan etkisi yok": Anladığım kadarıyla (FP hakkında yetkili bir cevap yazmak için yeterince bilmiyorum) bu doğru değil . Fonksiyonel programlama durumdan kaçınmakla ilgili olmayan referans şeffaflığı ile ilgilidir (referans şeffaflığını sağlamak için durumun uygun şekilde ele alınması gerekmesine rağmen). Haskell durum ve mutasyona izin verir . Sadece bunun hakkında muhakeme için farklı (daha iyi, tartışılabilir) araçlar sağlar.
Giorgio

38

Programlamanın Ustaları: Başlıca Programlama Dillerinin Yaratıcıları ile Konuşmalar

[Haskell]

Sizce neden ana akıma işlevsel bir programlama dili girmedi?

John Hughes: Kötü pazarlama! Propaganda demek istemiyorum; bundan çok şey aldık. Demek istediğim, hedef pazar nişinin egemen olması için dikkatli bir seçim, ardından fonksiyonel programlamayı bu niş için en etkili yol haline getirmek için kararlı bir çaba. 80'lerin mutlu günlerinde fonksiyonel programlamanın her şey için iyi olduğunu düşündük - ancak yeni teknolojiye "her şey için iyi" demek, "özellikle hiçbir şeyde iyi" olarak adlandırmakla aynı şeydir. Markanın ne olması gerekiyor? Bu, John Launchbury'nin ICFP'deki davetli konuşmasında çok açık bir şekilde tanımladığı bir sorundur. Galois Connections, markaları "işlevsel dillerde yazılım" olduğu zaman neredeyse sona ermişti, ancak "yüksek güvenceli yazılım" a odaklandıklarından beri güçlenerek güçlenmeye başladılar.

Birçok insan teknolojik inovasyonun nasıl gerçekleştiğine dair hiçbir fikre sahip değildir ve daha iyi teknolojinin tek başına ( "daha iyi fare kapanı" etkisi) baskın olmasını bekler , ancak dünya böyle değildir.


36
Haskell: 20 yıl sonra, bir gecede başarı!
Juliet

bağlantıyı takip edin ve Grady Booch'un oldukça eğlenceli bir diski için yorumları okuyun. Booch'un kim olduğu hakkında bir fikrim yok, ama yine de beni lol yaptı.
fearofawhackplanet

4
Grady Booch, nihayetinde, Jacobson ve Rumbaugh ile birlikte UML'nin iğrençliğinden sorumludur.
SADECE benim doğru görüşüm

27

Hisse senedi yanıtı, diğerinin yerine geçmeyecek veya değiştirilmeyecek - farklı artıları ve eksileri olan farklı araçlardır ve hangi yaklaşımın kenarı vardır, projeye ve mevcut yetenek havuzu gibi diğer "yumuşak" sorunlara bağlı olarak değişecektir.

Çok çekirdekten kaynaklanan eşzamanlılığın büyümesinin, işlevsel programlama diğer stillere göre seçildiğinde yüzdeyi (küresel kalkınma projeleri setinin) artıracağını haklı buldunuz.

Bugün nadir olduğunu düşünüyorum çünkü günümüzün profesyonel yetenek havuzunun çoğu zorunlu ve nesneye yönelik teknolojilerle en rahat olanı. Örneğin, bir kereden fazla Java'yı ticari bir projenin dili olarak seçtim çünkü yeterince iyi, tartışmalı değildi ve içinde programlayabilecek (yeterince iyi) insanlardan asla tükenmeyeceğimi biliyorum.


Bu çok anlayışlı ve nefis bir şekilde pragmatik. Kesinlikle bu soruya her biçiminde gördüğüm en iyi cevap.
Benson

Belki de her ikisi de birinci sınıf vatandaş olan bir dil ile popüler olacak.
Kevin Kostlan

1
% 110 katılıyorum. Birkaç kez FP'ye girmeye çalıştım, ancak birkaç hafta sonra devam etme isteğini kaybettim. 30 yılı aşkın bir süredir prosedürel olarak programlıyorum ve zorunlu programlamaya çok alışkınım. Bu genel olarak BT endüstrisi için geçerlidir. Değişim kolay ve hızlı bir şekilde gerçekleşmeyecektir.
Richard Eng

26

Fonksiyonel programlamanın avantajlarına rağmen, zorunluluk ve nesne yönelimli programlama asla tamamen ortadan kalkmayacaktır.

Zorunlu ve nesne yönelimli programlama, sorunun ve çözümünün adım adım açıklamasıdır. Bu nedenle, anlaşılması daha kolay olabilir. Fonksiyonel programlama biraz belirsiz olabilir.

Nihayetinde, yararlı bir programın her zaman yan etkileri olacaktır (tüketim için kullanıcıya gerçek çıktı sağlamak gibi), bu yüzden fonksiyonel dillerin en saf hali zaman zaman zorunlu dünyaya adım atmanın bir yoluna ihtiyaç duyacaktır.

Tekniğin bilinen durumu, zorunlu dillerin (C # gibi) işlevsel dünyadan (lambda ifadeleri gibi) özellikleri ödünç almasıdır.


3
OOP bir tür zorunlu programlama alt kümesi değil mi?
pankrax

9
OOP bir süper kümedir. C ++ C olarak olduğu için OOP zorunludur
Robert Harvey

10
OOP'nin zorunlu olarak zorunlu programlamaya bağlı olduğunu düşünmüyorum. Bir Clojure veya CLOS'a bakın - her ikisi de işlevsel, ancak nesne yönelimlidir.
Gabe

9
OO dilleri zorunlu olma eğilimindedir, ancak olmak zorunda değildir. OCaml, tüm varoluş nedeni OO olan güçlü (ancak tamamen olmasa da) işlevsel bir dildir.
Chuck

7
OOP'nin neden zorunlu programlamanın bir üst kümesi olduğunu anlamıyorum. Tüm zorunlu kodlar OOP değildir ve tüm fonksiyonel kodlar OOP değildir. OOP'nin, aerodinamik kanatlar gibi yarış arabaları, uçaklar veya roketler veya soğutma fanları veya yel değirmenleri gibi zorunlu programlama ve fonksiyonel programlama olduğunu söyleyebilirim, ya da ... yani, kavramlar birbiriyle ilişkilidir, ancak 1'e 1 bağlantı.
Sebastian Mach

21

Değil mi?

Smalltalk o güne kadar harika bir nesne yönelimli sistemdi. Nesneye yönelik programlama neden devralınmadı? Evet, öyle. Smalltalk gibi görünmüyor. Ana diller C ++, Java, C #, vb. .

Fonksiyonel aynı şekilde. Haskell çok işlevsel bir dildi. Ancak bugün 20 yıl öncesine göre C benzeri sözdizimini kullanan ana akım programcılardan daha fazla kitleye sahibiz. Yani C gibi görünmeli. Tamam: herhangi bir LINQ ifadesine bakın ve işlevsel olmadığını söyleyin.


2
İlginç bir nokta, ancak anaakım diller nasıl Smalltalk benzeri oluyor? Örneğin, C ++, Java ve C #, Smalltalk paradigmasının en önemli parçası olan (inanıyorum) mesaj göndermeye dayanmaz.
Jonathan Sterling

4
Jonathan: Herhangi bir Smalltalk özelliğini seçin ve C ++ (en eski) için en zayıf, Java için Tamam ve C # için daha iyi olduğunu gözlemleyin. Örneğin, GC (yalnızca Java / C #), otomatik kutulama (yalnızca daha sonra Java / C #), kapanışlar (yalnızca C #) ve yansıma (Java'da bulunur, C #'da daha iyidir). Mesaj iletmek istiyorsanız, C # 4'lere bakın dynamic. Bu özelliklerin en Smalltalk-y'i, bu yüzden bu üç dilin en moderninin en son sürümünde mevcut olması benim için sürpriz değil. :-)
Ken

Javascript, python ve ruby ​​gerçekten nasıl olduğunu gösteren iyi örneklerdir
nafg

15

Zorunlu dillerin daha yaygın olduğuna inanıyorum çünkü daha çok insan buna alışkın. Ne işlevsel programlama ne de zorunlu programlama modeli diğerinden daha belirsiz veya akademik değildir. Aslında, bunlar tamamlayıcıdır.

Bir poster, zorunlu kodun anlaşılmasının fonksiyonel programlama kodundan daha kolay olduğunu söyledi. Bu, yalnızca okuyucu daha önce zorunlu kod görmüşse, özellikle de önceki örnekler aynı "ailenin" bir parçasıysa (örneğin, C / C ++, Perl, PHP ve Java) geçerlidir. Herhangi bir zorunlu dil için doğru olduğunu iddia etmem ; aşırı bir örnek vermek için Java ve Forth karşılaştırmasını yapın

Bir uzmana göre, Hypertalk ve SQL gibi ayrıntılı diller dışında tüm programlama dilleri çözülemez anlamsızdır. (SQL'in açıklayıcı ve / veya işlevsel bir dildir ve büyük bir popülerliğe sahiptir.)

Başlangıçta Lisp-y veya Haskell-y dilinde eğitilmiş olsaydık, fonksiyonel programlama dillerinin tamamen normal olduğunu düşünürdük.


"Bir poster, zorunlu kodun anlaşılması için fonksiyonel programlama kodundan daha kolay olduğunu söyledi. Bu, yalnızca okuyucu zaten zorunlu kod görmüşse doğrudur, özellikle önceki örnekler aynı" ailenin "(örneğin, C / C ++, Perl, PHP ve Java). ": Çok doğru (+1): Programlamaya başladığımda Pascal ve C'yi öğrenmek için ne kadar çaba harcamam gerektiğini hatırlıyorum. Scala, Haskell veya Scheme'yi okumak artık bu diller hakkında biraz deneyime sahip olduğum için ne kadar kolay.
Giorgio

2
Değişken durumu hala bazen faydalı bulmamın tek nedeni, hızlı kod yazmak için kolay bir yol sunmasıdır (kopyalama yok); ama bunun nedeni yeterli işlevsel programlama bilmemem ve durumların% 90'ı için değişebilir durumu kullanmadan hızlı fonksiyonel kod yazabilmeniz olabilir.
Giorgio

3
Hesaplamayı düzenlemek için en yaygın kullanılan ve uzun ömürlü ortamlardan biri elektronik tablodur; aslında adlandırılmış değişkenlerden ziyade hücreler içeren fonksiyonel bir programlama ortamı. İnsanların genel olarak programları bir dizi adım olarak algıladıklarına inanmıyorum. Programcılar belki de yaygın zorunluluk dillerinde konuşlanmışlardır.
jpnp

14

Daha önce bahsetmediğim sadece birkaç şeyden bahsedeceğim kadar cevap aldınız.

Birincisi ve (aklımda), prosedürel diller, ortaklık derecelerinden büyük ölçüde yararlanmıştır. Bir örnek olarak, hemen hemen her dereceye kadar ana prosedürel (veya OO) dillerinden neredeyse her birini bilen hemen hemen herkes , diğerlerinin çoğunu makul derecede iyi okuyabilir. Java, C #, Cobol, Fortran veya Basic'te (sadece birkaç örnek için) aktif olarak çalışmaktan kaçınıyorum, ancak bunlardan herhangi birini makul derecede iyi okuyabilirim - aslında, her gün kullanan insanlar olarak.

İşlevsel açıdan, bu çok daha az doğru. Örneğin, Şemayı oldukça makul bir şekilde yazabilirim, ancak Ocaml veya Haskell'i okumak için çok az faydası var (sadece birkaç örnek için). Tek bir aile içinde bile (örneğin, Scheme vs., Common Lisp) birine aşinalık neredeyse diğerine tercüme edilmiyor gibi görünmektedir.

Fonksiyonel kodun daha okunabilir olduğu iddiası sadece dar koşullar altında doğrudur. Dile son derece aşina olan insanlar için okunabilirlik gerçekten mükemmel - ancak diğer herkes için, genellikle mevcut değil. Daha da kötüsü, prosedürel dillerdeki farklılıklar büyük ölçüde sözdizimi ve bu nedenle nispeten kolay öğrenilirken, fonksiyonel dillerdeki farklılıklar genellikle çok daha temeldir, bu yüzden gerçekten anlamak için önemli bir çalışma gerektirirler (örneğin, Lisp'in Monad'ları anlamada çok az yardımcı olduğunu bilmek).

Diğer önemli nokta, işlevsel programların yordamsal programlardan daha kısa olduğu fikrinin, genellikle semantikten ziyade sözdizimine dayanmasıdır. Haskell'de yazılmış programlar (bir örnek için) genellikle oldukça kısadır, ancak işlevsel olması bunun oldukça küçük bir parçasıdır. Haskell'in nispeten kısa bir sözdizimine sahip olması çok önemli.

Çok az işlevsel dil, kısa kaynak kodu için APL ile iyi rekabet edebilir (yine de, APL, daha yüksek seviyeli işlevler oluşturmayı da destekler, bu da diğer bazı durumlarda olduğu gibi büyük bir fark değildir). Aksine, Ada ve C ++ (sadece birkaç örnek için) belirli bir görevi yerine getirmek için gereken işlem sayısı açısından oldukça rekabetçi olabilir, ancak sözdizimi (en azından genellikle) önemli ölçüde daha ayrıntılıdır.


Mükemmel yorum! Bütün kalbimle katılıyorum. Birkaç prosedürde sadece iyi niyetli bir uzman olmama rağmen, çoğu prosedürel dili okumak ve anlamak oldukça kolay buluyorum. FP dilleri için aynı şey söylenemez.
Richard Eng

1
Bir başka önemli nokta, herhangi bir paradigmada, yeni başlayanlardan gurulara kadar bir dizi uzmanlık bulmanızdır. FP kodu uzmanlar için kolayca okunabilir ve anlaşılabilir olabilir, ancak orta düzeydeki programcılar hala mücadele edebilir. Uzmanlar genellikle FP topluluğunun çok küçük bir kısmını oluşturmaktadır.
Richard Eng

11

Algılanan Gereksinim Yok

Ona John Backus'un Turing Ödülü dersinin bir kopyasını von Neumann Stilinden Kurtuluyor Olabilir mi?

Cevabı: "Bazılarımız von Neumann stilinden kurtulmak istemiyoruz !"


10

İşlevsel programlama neden henüz ele geçirilmedi?

Fonksiyonel bazı şeyler için daha iyi ve diğerleri için daha kötüdür, bu yüzden asla "devralmayacaktır". Yine de gerçek dünyada her yerde bulunur.

Vatansız programlar; Yan efektleri olmayan

Durumsuz programların test edilmesi daha kolaydır. Bu artık endüstride yaygın olarak takdir ediliyor ve sıklıkla kullanılıyor.

Eşzamanlılık; Yükselen çok çekirdekli teknolojiyle son derece iyi çalışır Programlar genellikle daha kısadır ve bazı durumlarda daha kolay okunur Verimlilik artar (örnek: Erlang)

Eşzamanlı ve paralelliği karıştırıyorsunuz.

Eşzamanlılık, sıralı iletişim süreçleri (CSP) kullanılarak etkili bir şekilde yapılabilir. Bir CSP'nin içindeki kod yerel durumunu değiştirebilir, ancak aralarında gönderilen mesajlar her zaman değişmez olmalıdır.

Tamamen işlevsel programlama çok çekirdekli çok kötü oynar çünkü düşmanca önbelleklidir. Çekirdekler paylaşılan bellek için yarışır ve paralel programlar ölçeklenmez.

İşlevsel dilde yazılmış programlar veya programlar neden hala "nadir"?

Scala genellikle işlevsel bir dil olarak kabul edilir, ancak bugün dünyanın en popüler dillerinden biri olan C # 'dan daha işlevsel değildir.

İşlevsel programlamanın avantajlarına bakarken neden zorunlu programlama dillerini kullanıyoruz?

Tamamen işlevsel programlamanın birçok ciddi dezavantajı vardır, bu yüzden Lisp, Scheme, SML, OCaml, Scala ve C # gibi saf olmayan fonksiyonel dilleri kullanırız.


7

İşlevsel programlamanın işteki projelerime neler getirebileceğini düşündüğümde hep aynı düşünce yoluna yöneldim:

  1. Fonksiyonel programlamanın tüm avantajlarından yararlanmak için tembellik gerekir. Evet, sıkı fonksiyonel diller vardır, ancak fonksiyonel programlamanın gerçek faydaları katı kodda da parlamaz. Örneğin, Haskell'de bir listede bir dizi tembel işlem oluşturmak ve bunları birleştirmek ve bir listeye uygulamak kolaydır. Örneğin. op1 $ op2 $ op3 $ op4 $ someList. Tüm listeyi oluşturmayacağını biliyorum ve dahili olarak sadece birer birer unsurlardan geçen güzel bir döngü elde edeceğim. Bu gerçekten modüler bir kod yazmanıza izin verir. İki modül arasındaki arabirim, potansiyel olarak geniş veri yapılarının teslim edilmesini içerebilir, ancak yapının yerleşik olması gerekmez.

  2. Ancak tembellik yaptığınızda, bellek kullanımı ile ilgili akıl yürütmek zorlaşır. Haskell derleyici bayraklarının değiştirilmesi, bir algoritma tarafından kullanılan bellek miktarını bazen O (N) 'den O (1)' e değiştirir, ancak bazen değiştirmez. Bu, kullanılabilir belleğin tamamını kullanması gereken uygulamalarınız olduğunda gerçekten kabul edilemez ve tüm belleğe ihtiyaç duymayan uygulamalar için bile harika değildir.


Tembellik ayrıca hata ayıklama ile idealden daha az etkileşimde bulunur.
Brian

3
Diğer dillerde kovaladığım hataların çoğunun referans şeffaflık eksikliğinden kaynaklandığını fark ettiğim için, bazen bir ağrı olsa da hata ayıklama sorunları hakkında daha az endişeliyim.
sigfpe

6

İki şey:

  1. Bir teknoloji ne kadar iyi olursa olsun zaman alır. FP'nin arkasındaki fikirler yaklaşık 70 yaşında. Ancak Yazılım Mühendisliğinde (siperlerde, endüstride) yaygın kullanımı muhtemelen 10 yıldan azdır. Geliştiricilerden ırksal olarak yeni zihniyetleri benimsemelerini istemek mümkündür, ancak sadece zaman alır (uzun yıllar). Örneğin, OOP gerçekten 1980'lerin başında yaygın kullanıma sahipti. Ancak, 1990'ların sonlarına kadar dorminance kazanamadı.
  2. İnsanların, bir teknolojiye büyük bir vuruş yapmadan önce onun gücü ile yüzleşmek zorunda kalmaları gerekir . Şu anda insanlar paralellikten faydalanmayan araçlar kullanıyor ve işler iyi gidiyor. Paralellik kullanmayan uygulamalar dayanılmaz derecede yavaşladığında; birçok kişi paralellik araçlarını kullanmaya zorlanacak ve FP popülerlik kazanabilir. Bu, FP'nin diğer güçlü yönleri için de geçerli olabilir.

3
FP kod kullanımında çok iyidir. Muhtemelen OO'dan daha iyi. Birkaç kez işte, farklı tiplere ve yeni bir sisteme geçerek uğraşmak zorunda kaldım ve ağrısızdı.
nlucaroni

@Freddy Rios ve @nlucaroni. Yorumu yanlış yorumlamak için yeniden yazdım.
Phil
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.