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

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

Neden fonksiyonel programlama dilleri endüstride daha fazla kullanılmıyor? Bugünlerde fonksiyonel programlama dilleri hakkında oldukça fazla haber var, bu yüzden şimdi sektörde fonksiyonel programlamanın başarılı olup olmadığını merak ediyorum.

İşlevsel programlamanın daha yaygın olmama nedenlerinden birinin bilgi tabanı eksikliği olduğunu söyleyebilirim. Benim deneyimim, şirketlerin ana akım olmayan ve denenmiş ve gerçek çerçevelere yatırım yapmak yerine teknolojiyi uygulama konusunda çok riskli olduklarıdır (java, c ++, c #). Sadece bir iş ihtiyacı olduğunda (Ericsson'da olduğu gibi) yeni paradigmaların göz önünde bulundurulması gerekir. Ancak Ericsson'un durumunda bile, yönetimin c ++ 'nın kullanılmasını istediğini duydum ve Joe Armstrong, c ++' da erlang çağrılarını kodlamak zorunda kaldı! Bu, isteksiz şirketlerin yeni teknolojileri nasıl uyguladıklarını göstermelidir!

Profesördüm ve tıpkı programcılar gibi, profesörler her zaman bir sonraki büyük şeyi arıyorlar. Bir tane bulduğunu düşündüklerinde, onu bir grup arabası yaparlar ve herkes kazınır. Profesörlerin gerçekten akıllı olması gerektiğini düşünen öğrencilere vaaz verdikleri için, neden profesör olurlarsa, hiç direnç almazlar.

İşlevsel programlama böyle bir ana yoldur. Elbette araştırılması gereken çok sayıda ilginç soru ve bir sürü ilginç konferans makalesi var. Bu özellikle yeni bir fikir değil ve bunu herhangi bir modern dilde yapabilirsin ve fikirlerin ilginç olmak için yeni olması gerekmez. Aynı zamanda sahip olmak için iyi bir beceri.

O göz önüne alındığında, işlevsel programlama titremenizdeki tek bir okdur, sadece bir değil, OOP'ın tek olmadığı gibi.

Bilgisayar bilimi akademisi ile olan sığır derim, gerçek dünyayı gerçek anlamda neyin anlam ifade ettiğini, yani kalite kontrolünü belirlemek için endüstri ile pratik bir etkileşimin olmaması. Eğer bu kalite kontrolü orada olsaydı, problemleri ve kendilerine göre çözüm çeşitlerini, en son bant vagonlarından ziyade haksızlıklarla sınıflandırmaya farklı bir vurgu yapılabilir.

Çünkü bugünlerde yazılım geliştirmedeki en büyük sorun karmaşıklığı yönetme yeteneğidir. Bu, işlevsel programlama dillerinin çoğunun odağı değildir. Bunun gibi, dil yapmak öncelikli (yani daha popüler cepten dilleri) sadece daha fazla akademik fonksiyonel dillerin çıkıp böylece üstünde kalmak soğutucu özelliklerinden bazıları çalmak eğiliminde olduğunu olun.

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

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

• Verimlilik - FP öğrenmek zordur, ancak bunu bir kez yakaladığınızda, güç ve ifade açısından yenmek çok zordur. Muhtemelen, C # ya da Java’da ihtiyacım olana kıyasla herhangi bir işlevsellik parçasını uygulamak için satır sayısının 1 / 10’unu yazıyorum

• Güvenilirlik - saf fonksiyonlar, mantıklı nesnelere göre düşünmek ve test etmek için çok daha kolaydır. Böylece daha iyi testler yazabilir ve kodunuzun doğruluğunu daha kolay doğrulayabilirsiniz.

• Eşzamanlılık - işlevsel diller, eşzamanlı uygulamalar için birden fazla çekirdek üzerinde etkili bir şekilde çalıştırmanın gereğinden büyük faydaları olan değişmezliği vurgular. Ve bunun gibi ya da değil, çoklu çekirdeklerde koşmak gelecek. Bunun neden bu kadar önemli olduğunu açıklayan bir açıklama için bkz. Http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

• Composability / modularity - işlevsel diller, bileşenleri karmaşık OO sistemlerinden daha kolay bir şekilde bir araya getirmeye kendilerini ödünç veriyor gibi görünmektedir. Bunun nedenini hala çözemedim, ancak bunun bir kısmı, OO modellerinin yanlarında sürüklediği tüm "tesadüfi karmaşıklığa" sahip olmamanızdan kaynaklanıyor. Stuart Halloway'ın Radikal Basitlik konulu konuşması bu fikirleri çok daha derinlemesine araştırıyor.

EDIT : Despertar'ın yorumuna cevaben, modülerliği sınırlayan OOP sistemlerinin "tesadüfi karmaşıklığına" bir örnek, derin klonlama ile sığ klonlama arasındaki problemlerdir: nesneleri bir arada oluşturamaz ve bunları bir arada olmadan kompozit yapılar olarak geçiremezsiniz. klonlama ve mutasyon semantiğinin dikkatli analizi. Küçük durumlarda bu yönetilebilir, ancak karmaşık sistemlerde hızla önemli bir sorun haline geliyor. Saf işlevsel veri yapılarına güvenirseniz, bu sorun ilk başta ortaya çıkmaz.

Katil uygulaması eksikliği

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

Sanırım çoğu programlama dili, bir "katil uygulaması" ndan - diline özgü (ya da bu şekilde görülen) çekici bir şeyle gelişiyordu. Bu, tüm alımların o uygulama olduğunu söylemek değil, dili daha büyük bir kabul görmeye sürdüğünü söylemek değildir .

İşte nişimizin bugün sahip olduğumuz bazı dillerin benimsenmesini sağladığına dair çok doğru olmayan bir görüşüm:

• C: Her yerde çalışıyor (Bu, 70'li ve 80'li yılların sonlarıydı)
• C ++: GUI çerçeveleri (90'ların başında)
• Java: Apletler ve uygulayıcılar (90'ların sonunda)
• Amaç-C: iOS uygulamaları (Bundan önce OS X uygulamaları)
• Yakut: Raylar
• C #: ASP.NET, WinForms
• PHP: Wordpress, vb.
• Javascript: AJAX, özellikle çerçeveler aracılığıyla
• lua: Oyun komut dosyası, özellikle WoW

Bunun yanı sıra, birçok özel dil kapıya güçlü satış organizasyonları (Oracle ve daha az derecede Microsoft'un dilleri) ile girerek etkin bir şekilde kendi alanlarını yarattı.

Bu listeyle ilgili çok önemli bir not: Katilin uygulaması tarafından belirtildiği gibi dilin "nişi", yıllar geçtikçe daha da belirginleşiyor. Listedeki sonuncuyu not edin: Özellikle oyun komut dosyası . Başka bir dil tarafından zaten yeterince iyi yapılan şeylerin listesi nedeniyle dillerin dikkatini çekmesi gittikçe zorlaşıyor.

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

• Emacs Lisp: 80'lerden bu yana Emacs'ta geliştiriciler tarafından sürekli kullanım. ( Neredeyse başka hiçbir yerde kullanılamaz.)
• Erlang: Her yerde çok fazla eşzamanlı ajan istiyorsun.
• Şema: Eğitim
• APL / J / K: Finans (Argüman uğruna bunları işlevsel olarak adlandıralım)
• Common Lisp: "AI" - İnsanların onun için kullanıldığını söyleme eğiliminde olduğu, bu bir nimet ve bir lanet.

Şimdi, bu tartışma dışında bıraktığımı hissettiğim tek ana dil Python. Python çok ilginç bir şey yaptı; Herhangi bir ana alanda kazanan olarak görünmeden başarılı olmuştur. Bu , dil popülerliğini bu şekilde görüntüleme konusunda yanlış yaptığım anlamına gelebilir. Aynı zamanda, yeterince iyi bir dilin , kabul edilmeyi ve kabullenmeyi teşvik eden katil bir uygulama olmadan popüler olabileceği anlamına gelebilir, ancak çok zordur ve çok uzun zaman alabilir. (Perl'in benzer bir hikayesi var, ancak birkaç yıl önce geldi ve şimdi daha az alımı var.)

Buradan, ben düşünüyorum fonksiyonel hangi dillerin söyleyebiliriz şunlardır artıyor:

• Clojure: Web programlama, esp. Heroku aracılığıyla
• Scala: Lift (veya bugün Oyna, bugünlerde) - Java olmadan JVM

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

Aynı sebepten dolayı Lisp hiç yakalanmadı (flamewarlar başlasın!). İşlevsel programlama, zorunlu ve nesne yönelimli programlamaya kıyasla çok yabancı bir paradigmadır. Eğer CS öğrencilerinin büyük çoğunluğu gibi, C ile başlayıp C ++ / Java'ya geçtiyseniz, normalde düşündüğünüze tamamen dik bir şekilde düşünmeyi öğrenmek istemezsiniz.

İşletmeleri ve programlamayı düşünelim.

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çtikleri takdirde her şey yolunda giderse X $ 'dan daha az tasarruf edeceğini ve her şey yolunda giderse çok büyük kaybedeceklerini biliyorlar.

Dahası, işletmelerde yapılacak en ucuz şey genellikle dün yaptıklarıdır. Bununla birlikte arzu edilen değişiklik, pahalıdır. Eğer bir şirket bir C # /. NET çözümünden, F # 'dan bile değişecek olsaydı, problemleri olurdu. Programcıları (muhtemelen en keskin programcıları olmayan) yeni bir dil öğrenmek ve her ikisinde de yetkin olmak ve her ikisini de kullanmak zorunda kalacaklardı. Uzun zamandır her ikisinde de yazılı rutinler olacaktır. Haskell gibi bir şeye geçmek isterlerse ya da en başta C ++ / MFC kullanıyorlarsa, çok daha fazla değişiyorlardı ve bu çok daha pahalı olurdu.

Ayrıca, uzun süredir C # programcıları ve Microsoft desteğini sürdürecek bir tedarik olacak. Mevcut BT uygulamalarına güvenilebilir. Aynı düzeyde kurumsal destek veya programcıların sürekli kullanılabilirliğinin sağlanması güvencesi yoktur.

Bu nedenle, çoğu işletme için, işlevsel programlamada bir değişiklik yapmak önden pahalıya mal olacak ve uzun vadede potansiyel olarak yumuşak olması dışında, yalnızca BT maliyetlerindeki düşüşün uzun vadede yeterli olması durumunda ücret ödeyecektir.

Kodları zaten işlevsel bir tarzda yazıyorsunuz, sadece bilmiyorsunuz.

Kodunuz için birim testleri yapmanız gerektiğinde, yan etkileri oluşturmayan veya bunlara bağlı olmayan test edilebilir işlevler yazma eğilimindedir ve her zaman aynı sonucu aynı argümanlar üzerinde (salt işlevler olarak adlandırılır) verir. İşlevsel programların birincil avantajı budur.

Bence işlevsel diller çok sınırlı. Bu nedenle zorunlu dilleri işlevsel olanlarla değiştirmek yerine, zorunlu dillerin işlevsel özellikleri olur. Günümüzde hemen hemen her programlama dilinde kapaklar ve lambdalar vardır.

Sorunuza sadece tek bir cevap olduğuna inanıyorum. Bu cevabın neden böyle olduğu ile ilgili birçok nedene katılabilirsiniz, ancak bunlar farklı sorular.

İşte burada:

• Yazılım mimarları işe yarayacağına emin oldukları çözümler sunar.
• Mimarların çoğu fonksiyonel dillerde çalışmıyor.
• Teknolojiler ve diller seçildikten sonra, işletmeler onlarla çalışabilecek kişileri bulur.

Yakalıyor mu? Bunların hepsi, fonksiyonel dilleri kullanmakta kendine güvenen insanların mimar olmalarına ve üzerinde çalıştıkları projeler için kullanmayı seçmelerine bağlıdır.

Asıl sorun devlet.

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

Ancak, doğal olarak devletle dolu olan Von-Neuman mimarisi makinelerinde kod kullanıyoruz. Dolayısıyla aslında devletten kurtulmadık, işlevsel diller devletin karmaşıklığını geliştiriciden gizliyor. Bu, dil / derleyicinin perde arkasındaki durumla ilgilenmesi ve onu yönetmesi gerektiği anlamına gelir.

Dolayısıyla, işlevsel dillerin küresel bir durumu olmasa da, durum bilgileri parametre ve sonuç olarak iletilir.

Öyleyse soru şu, dil, devleti duygunun arkasında verimli bir şekilde ele alabilir mi? Özellikle veri büyüklüğü mimarinin büyüklüğünü aştığında.

Donanım Tarafından Bakmak

İşletim sistemi son birkaç yıl içinde adres alanını görselleştirmede çok yardımcı oldu, böylece uygulamaların resmi olarak endişelenmesine gerek kalmadı. Ancak endişelenmeyen uygulamalar, bellek baskısı yoğunlaştığında donanıma girme tuzağına düşebilir (donma donanıma, işlemlerinizi süründürmek için yavaşlatır).

Programcı, işlevsel dilde durum üzerinde doğrudan kontrol sahibi olmadığından, bunun için derleyiciye güvenmeleri gerekir ve bunu iyi yapan işlevsel dilleri görmedim.

Madalyonun öbür tarafında, durum dolu programcının durum üzerinde doğrudan kontrolü vardır ve bu nedenle düşük bellek koşullarını telafi edebilir. Yine de, aslında bunu yapacak kadar akıllı olan pek çok programcı görmedim.

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

Endüstri, çok sayıda verimsiz devlet tam programlayıcısına sahiptir.

Ancak bu programlardaki gelişmeleri zaman içinde ölçmek kolaydır. Programın nasıl işlendiğini geliştirerek kodu geliştirebilecekleri bir takım geliştiricilerin problemini çözersiniz.

İşlevsel programlar için , programları geliştirecek araçları geliştirmeye ihtiyaç duyduğunuz için iyileştirmeleri ölçmek daha zordur (uygulamaların, programın genel iyileştirmesini değil, burada temelde devletin nasıl verimli bir şekilde kullanıldığını araştırıyoruz).

Bu yüzden endüstri için koddaki gelişmeleri ölçmenin kabiliyetine indiğini düşünüyorum.

Bir işe bakış açısından

Kiralanabilecek çok sayıda stat dolu programcı var. Fonksiyonel programlayıcıları bulmak zor. Dolayısıyla, temel arz ve talep modeliniz, endüstri fonksiyonel stil programlamasına geçerse ve bu onların olmasını istedikleri bir şey değilse (programcılar olduğu gibi pahalı) ortaya çıkar.

Bu soru biraz yanlış öncül var. Aşağıdaki sebeplerden dolayı:

1. Fonksiyonel programlama aslında sektörde oldukça yaygındır. Ancak, yalnızca deneyimli programcıların bulunduğu yerlerde kullanılır. Yeni başlayanların bunu bilmesi beklenemez. Neredeyse tüm büyük programlama projeleri onu kullanıyor, ancak sadece deneyimli programcılar tarafından yönetilen alanlarda tutuyorlar. Yeni başlayanlar, fonksiyonel programlama gerektirmeyen kolay modüller ile ilgileneceklerdir.
2. Bu gerçeğe bakıldığında, insanları işe alan şirketler (genellikle üniversiteden gelen gençler) gerçekten işlevsel programlama deneyimi istemezler. Fonksiyonel programlama gerektiren projelerde herkes 15 yıldır aynı şirkette.
3. Üniversiteler bunu öğretmeye başlıyor, çünkü biliyorlar ki artık 30 yıl içinde fonksiyonel programlama bilgisinin çok faydalı olacağını biliyor. Zaman aralığı 30 yıl, şirketlerdeki gibi normal yarı yıl değil.
4. Bu noktalar, insanların işgücüne girdiklerinde hayal kırıklığına uğramasının ve üniversitede öğrendiklerinin kullanılmadığını görmelerinin nedenidir. Ancak 30 yıl süre için tasarlandılar ve sonunda faydalı olacaklar - sadece şirketler basit şeyleri kullanıyorlar - insanların bilmesini bekleyebilecekleri şeyler.
5. Ayrıca birkaç yıl üniversitenin ardından, gerçek yazılım projelerinde kullanmak için yeterince işlevsel bir programlama bildiğinizi düşünüyorsanız kibirli olursunuz. Önce basit şeylerden başla. Çalışmaya başladığınızda ilk işiniz olarak en karmaşık yazılımı yapmanız gerekmez. Sonunda karmaşık şeylere ulaşacaksınız, ancak zaman alıyor.

Çünkü FP'de hata ayıklamak daha zor.