it-swarm.dev

İşlevsel programlama endüstride neden daha popüler değil? Şimdi yakalanıyor mu?

Üniversitedeki dört yılım boyunca çeşitli fonksiyonel programlama dillerinde çok fonksiyonel programlama kullanıyoruz. Ama aynı zamanda nesne yönelimli programlamayı da kullandım ve aslında ilk işime hazırlanmak için kendi küçük projemi yaparken nesne yönelimli dilleri daha çok kullanıyorum. Ancak sık sık bu projeleri yaparken işlevsel bir programlama dilinde kodlama yapmayı diliyorum.

Bununla birlikte, bir iş ararken, işlevsel bir programlama dili bilgisinin gerekli olduğu bir işi görmek çok nadirdir.

İşlevsel programlama dilleri neden endüstride daha fazla kullanılmıyor? Bugünlerde fonksiyonel programlama dilleri hakkında oldukça fazla haber var, bu yüzden endüstride fonksiyonel programlamanın şimdi devam edip etmediğini merak ediyorum?

61
Jonas

Fonksiyonel programlamanın daha yaygın olmamasının nedenlerinden birinin bilgi tabanı eksikliği olduğunu söyleyebilirim. Deneyimlerim, şirketlerin ana akım olmayan ve denenmiş ve gerçek çerçevelere (Java, c ++, c #) yatırım yapma teknolojilerini uygulama konusunda riskten kaçınmalarıdır. Yalnızca yeni ihtiyaçlar dikkate alındığında (Ericsson gibi) bir iş ihtiyacı olduğunda. Ancak Ericsson'un durumunda bile, yönetimin c ++ 'ın kullanılmasını istediğini ve Joe Armstrong'un c ++' da erlang çağrılarını kodlamak zorunda kaldığını duydum! Bu, şirketlerin yeni teknolojileri uygulama konusunda ne kadar isteksiz olduklarını göstermelidir!

38
ennuikiller

Ben bir profesördüm ve tıpkı programcılar gibi profesörler de daima Sonraki Büyük Şey'i arıyorlar. Birini bulduklarını düşündüklerinde, bunu bir bandwagon yaparlar ve herkes birikir. Profesörlerin gerçekten zeki olması gerektiğini düşünen öğrencilere vaaz verdikleri için, neden profesör olurlarsa, hiçbir direnç kazanmıyorlar.

Fonksiyonel programlama böyle bir bandwagon. Elbette araştırılması gereken birçok güzel ilginç soru ve yazılması gereken çok sayıda ilginç konferans makalesi var. Bu özellikle yeni bir fikir değil ve hemen hemen her dilde yapabilirsiniz ve fikirlerin ilginç olmak için yeni olması gerekmez. Ayrıca sahip olmak iyi bir beceridir.

Bu göz önüne alındığında, fonksiyonel programlama sadece OOP gibi) tek değil, titreme sadece bir ok.

Bilgisayar bilimi akademisi ile olan sığır eti, gerçek dünyayı neyin anlamlı kıldığını, yani kalite kontrolünü belirlemek için endüstri ile pratik etkileşim eksikliği. Eğer bu kalite kontrolü orada olsaydı, sadece en yeni bandwagolardan ziyade, sorunlara ve çözümlerin çeşitliliğine, geleneklerle sınıflandırılmasında farklı bir vurgu olabilir.

67
Mike Dunlavey

Çünkü günümüzde yazılım geliştirmedeki en büyük sorun karmaşıklığı yönetebilme yeteneğidir. Bu, çoğu işlevsel programlama dilinin odağı değildir. Bu nedenle, do önceliği yapan diller (daha popüler olan OOP diller), daha akademik olanlardan gelen bazı serin özellikleri çalma eğilimindedir fonksiyonel diller ve böylece üstte kalmak.

25
Fishtoaster

Fonksiyonel programlama kesinlikle yavaş yavaş ama emin adımlarla başlıyor.

Örneğin, inşa ettiğim başlangıç, aşağıdaki nedenlerden dolayı birincil geliştirme dili olarak işlevsel bir dil (Clojure) kullanıyor:

  • Verimlilik - FP öğrenmek zor, ama bir kez asıldıktan sonra güç ve ifade açısından yenmek çok zor. Muhtemelen herhangi bir işlevsellik parçası uygulamak için satır sayısı yaklaşık 1/10 C # veya Java ne gerek göre yazıyorum

  • Güvenilirlik - saf işlevlerin mantıksal nesnelerinden daha fazla mantık yürütülmesi ve test edilmesi çok daha kolaydır. Böylece daha iyi testler yazabilir ve kodunuzun doğruluğunu çok daha kolay bir şekilde doğrulayabilirsiniz.

  • Eşzamanlılık - işlevsel diller, eşzamanlı uygulamalar için birden çok çekirdek üzerinde etkili bir şekilde çalışması gerekenden çok büyük faydaları olan değişmezliği vurgular. Ve beğen ya da beğenme, birden fazla çekirdek üzerinde çalışmak gelecektir. Bunun neden bu kadar önemli olduğuna dair mükemmel bir açıklama için http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey adresine bakın.

  • Oluşturulabilirlik/modülerlik - fonksiyonel diller, bileşenleri karmaşık OO sistemlerden daha kolay bir şekilde bir araya getirmeye borç veriyor gibi görünüyor. Bunun nedenlerini hala çözemedim, ancak bir kısmı OO modellerinin onlarla birlikte sürüklediği tüm "tesadüfi karmaşıklığa" sahip olmamanızdan kaynaklanıyor. Stuart Halloway'ın Radikal Sadeliği konusundaki konuşma bu fikirleri çok daha derinlemesine araştırıyor.

[~ # ~] düzenle [~ # ~] : Despertar'ın yorumuna yanıt olarak, OOP 'un "arızi karmaşıklığına" bir örnek modülerliği sınırlayan sistemler, derin klonlama ile sığ klonlama arasındaki problemlerdir: klonlama ve mutasyon semantiğinin çok dikkatli bir analizi olmadan nesneleri bir araya getiremez ve kompozit yapılar olarak geçiremezsiniz. Küçük durumlarda bu yönetilebilir, ancak karmaşık sistemlerde hızla önemli bir sorun haline gelir. Saf işlevsel veri yapılarına güveniyorsanız, bu sorun ilk etapta mevcut olmayacaktır.

24
mikera

Katil uygulaması eksikliği

Hey, buradaki taze görünüyor. (Kazmak Kazmak Kazmak)

Çoğu programlama dilinin bir "katil uygulaması" ile geliştiğini düşünüyorum - dile özgü (veya bu şekilde görüntülenen) zorlayıcı bir şey. Bu, tüm alımın that uygulama olduğu anlamına gelmez, ancak dili daha büyük bir kabullenmeye itti.

İşte nişin, bugün sahip olduğumuz bazı dillerin benimsenmesine neyin yol açtığına dair çok doğru olmayan bir görüşüm:

  • C: Her yerde çalışıyor (70'lerin ve 80'lerin sonlarıydı)
  • C++: GUI çerçeveleri (90'ların başı)
  • Java: Uygulamalar ve sunucu uygulamaları (90'ların sonunda)
  • Objective-C: iOS uygulamaları (Bundan önce OS X uygulamaları)
  • Ruby: Raylar
  • C #: ASP.NET, WinForms
  • PHP: Wordpress vb.
  • Javascript: AJAX, özellikle çerçeveler üzerinden
  • lua: Oyun senaryosu, özellikle WoW

Bunun yanı sıra, birçok özel dil güçlü satış organizasyonları (Oracle ve daha az derecede Microsoft'un dilleri) aracılığıyla etkin bir şekilde kendi nişlerini oluşturdu.

Bu liste hakkında çok önemli bir not: Katil uygulaması tarafından belirtildiği gibi, dilin "niş", onlarca yıl geçtikçe daha belirgin hale geliyor. Listedeki sonuncuyu not edin: Game script, özellikle. Başka bir dil tarafından yeterince iyi yapılmış şeylerin listesi nedeniyle dillerin dikkatini çekmek gittikçe zorlaşıyor.

Yani, herhangi bir işlevsel dilin gerçekten çıkarması gereken bir niş. Gerçekte, henüz herhangi bir büyük işlevsel dil yok, ancak daha küçük nişlerde çok şey var:

  • Emacs LISP: 80'li yıllardan beri geliştiriciler tarafından Emacs'ta sürekli kullanım. ( Neredeyse hiç başka bir yerde kullanılır.)
  • Erlang: İstediğiniz yerde birçok eşzamanlı ajan.
  • Şema: Eğitim
  • APL/J/K: Finans (Bunlara işlevsel olarak, argüman uğruna diyelim)
  • Ortak LISP: "AI" - İnsanlar bunun için kullanıldığını söyleme eğilimindedir, ki bu bir nimet ve bir lanettir.

Şimdi, bu tartışmanın dışında kaldığımı hissettiğim tek büyük dil Python. Python çok ilginç bir şey yaptı; herhangi bir büyük niş kazanan olarak görünmeden başarılı oldu. Bu olabilir Düzgün yanlış olduğum anlamına geliyor dil popülerliğini bu şekilde görüntülemek için. Ayrıca, yeterince iyi bir dil can bir katil uygulaması olmadan popüler hale gelmek ve kabulü teşvik etmek anlamına gelebilir, ancak çok zor ve çok uzun zaman alabilir. (Perl'in benzer bir hikayesi var, ancak birkaç yıl önce geldi ve şimdi daha az yer kaplıyor.)

Bundan, hangi işlevsel dillerin yükseldiğini söyleyebilirim are yükselişte:

  • Clojure: Web programlama, esp. Heroku aracılığıyla
  • Scala: Lift (ya da belki Play, bugünlerde) - Java olmadan JVM

Bana popüler fonksiyonel diller için nereye bakacağınızı sorduysanız, anahtar teslimi bulut geliştirme (la Heroku veya GAE) veya anahtar teslim mobil uygulama geliştirme ile fonksiyonel bir dil arayışı içinde olduğunuzu söyleyebilirim.

12
Jesse Millikan

Aynı nedenden ötürü, LISP hiçbir zaman gerçekten yakalanmadı (flamewars başlasın!). İşlevsel programlama, zorunlu ve nesne yönelimli programlamaya kıyasla çok yabancı bir paradigmadır. CS öğrencilerinin büyük çoğunluğu gibi, C ile başlayıp C++/Java'ya geçtiyseniz, normal olarak düşündüğünüz şekilde tamamen dik bir şekilde düşünmeyi öğrenmek istemezsiniz.

9
Chinmay Kanchi

İşletmeleri ve programlamayı ele alalım.

Yazılımlarını stratejik bir varlık olarak kullanan işletmeler var. Bu tipik değil. Çoğu işletme için BT, şirketin gerçek işini destekleyen bir şeydir. Bu gerekli bir masraf. Muhafazakarlar çünkü X $ için ihtiyaç duydukları BT'yi alabileceklerini biliyorlar, farklı bir şeye geçerse her şey yolunda giderse X $ 'dan daha az tasarruf edecekler ve her şey kötü giderse gerçek büyük kaybedecekler.

Dahası, işletmelerde yapılacak en ucuz şey, dün yaptıkları şeydir. Ancak değişim istenirse pahalıdır. Bir şirket, diyelim ki, bir C # /. NET çözümünden, hatta F # 'a geçiş yapsaydı, problemleri olurdu. Programcıları (muhtemelen en keskin programcılar değildir) yeni bir dil öğrenmek ve her ikisinde de yetkin olmak ve her ikisini de sık kullanmak zorundadırlar. Her ikisinde de uzun süre yazılı rutinler olacaktır. Haskell gibi bir şeye geçeceklerse ya da C++/MFC kullanıyorlarsa, çok daha fazla değişeceklerdi ve bu çok daha pahalı olurdu.

Ayrıca, uzun bir süre için C # programcıları ve sürekli Microsoft desteği sağlanacaktır. Mevcut BT uygulamalarına güvenilebilir. Aynı düzeyde kurumsal destek veya programcıların sürekli kullanılabilirliğinin güvencesi yoktur.

Bu nedenle, çoğu işletme için, işlevsel programlamada bir değişiklik yapmak pahalıya mal olur ve yalnızca uzun vadede potansiyel olarak buzlu olması dışında BT maliyetlerindeki azalma uzun vadede yeterliyse bunun bedelini ödeyecektir.

6
David Thornley

Zaten fonksiyonel tarzda kod yazıyorsunuz, sadece bilmiyorsunuz.

Kodunuz için birim testleri yapmanız gerektiğinde, yan etkilere neden olmayan veya yan etkilere bağlı olmayan ve her zaman aynı sonucu (salt işlevler olarak adlandırılır) döndüren test edilebilir işlevler yazma eğiliminde olursunuz. Bu fonksiyonel programların birincil avantajıdır.

İşlevsel diller çok sınırlayıcı. Bu nedenle, zorunlu dillerin yerine işlevsel diller yerine, zorunlu diller işlevsel özellikler kazanacaktır. Günümüzde hemen hemen her programlama dilinin kapanışları ve lambdaları vardır.

2
Calmarius

Sorunuza sadece tek bir gerçek yanıt olduğuna inanıyorum. Bu cevabın neden böyle olduğu ile ilgili birçok nedenden bahsedebilirsiniz, ancak bunlar farklı sorular.

İşte burada:

  • Yazılım mimarları çalışacağından emin oldukları çözümler sunar.
  • Mimarların çoğu işlevsel dillerde çalışmaz.
  • Teknolojiler ve diller seçildikten sonra, işletmeler onlarla çalışabilecek insanlar bulur.

Yakalanıyor mu? Her şey işlevsel dilleri kullanmaktan emin olan insanların mimar olup olmadıklarına ve üzerinde çalıştıkları projeler için kullanmayı seçmelerine bağlıdır.

1
John Fisher

Asıl sorun devlettir.

İşlevsel dillerin genel durumu yoktur. Endüstriyel sorunların çoğu, küçük ölçekte bazı işlevler gerçekten gerektirmese bile (bir defteri işlemek) büyük ölçekte (bir defter veya bir işlem kümesini nasıl temsil edersiniz) devlet gerektirir.

Ancak, doğası gereği devlet dolu olan Von-Neuman mimari makinelerinde kod çalıştırıyoruz. Yani aslında devletten kurtulmadık, fonksiyonel diller devletin karmaşıklığını geliştiriciden gizler. Bu, dilin/derleyicinin sahne arkasındaki durumla ve onu yönetmekle uğraşması gerektiği anlamına gelir.

İşlevsel dillerin küresel durumu olmamasına rağmen, durum bilgileri parametre ve sonuç olarak iletilir.

Öyleyse, soru şu olur; dil, durumu algılamanın arkasında etkin bir şekilde ele alabilir mi? Özellikle veri boyutu mimarinin boyutunu aştığında.

Donanım Yanından Bakmak

İşletim sistemi, son birkaç yılda adres alanını görselleştirmede çok yardımcı oldu, böylece uygulamaların resmi olarak endişelenmesine gerek yok. Ancak endişelenmeyen uygulamalar, bellek basıncı yoğunlaştığında donanımı çöpe atma tuzağına düşer (donanımı çöpe atmak işlemlerinizi yavaşlatacaktır).

Programcı, işlevsel dilde durum üzerinde doğrudan kontrol sahibi olmadığından, bunu işlemek için derleyiciye güvenmelidir ve bunu iyi işleyen fonksiyonel diller görmedim.

Madalyonun ters tarafında durum dolu programcı durum üzerinde doğrudan kontrole sahiptir ve bu nedenle düşük bellek koşullarını telafi edebilir. Gerçi bunu yapacak kadar akıllı olan pek çok programcı görmedim.

Endüstri tarafından bakıldığında:

Endüstride çok fazla verimsiz devlet dolu programcı vardır.

Ancak zaman içinde bu programlardaki gelişmeleri ölçmek kolaydır. Geliştiricilerin bir ekibini, programın durumu işleme biçimini iyileştirerek kodu geliştirebilecekleri soruna atıyorsunuz.

Fonksiyonel programlar için, iyileştirmeler daha ölçülmesi zor programları geliştirecek araçları geliştirmeniz gerektiğinden (programların genel iyileştirmesini değil, uygulamaların temeldeki durumu nasıl verimli bir şekilde ele aldığını inceliyoruz. ).

Bu yüzden endüstri için koddaki gelişmeleri ölçme yeteneğine geldiğini düşünüyorum.

İşe alma perspektifinden

Kiralık birçok stat-tam programcı vardır. Fonksiyonel programlayıcıları bulmak zordur. Eğer endüstri fonksiyonel stil programlamasına geçerse ve bu olmasını istedikleri bir şey değilse, temel arz ve talep modeliniz devreye girer (programcılar olduğu gibi pahalıdır).

0
Martin York