Fonksiyonel programlama problemler ve çözümler arasındaki 'temsili boşluğu' artırır mı? [kapalı]

Makine dili (örn. 0110101000110101) Bilgisayar dilleri genellikle daha yüksek soyutlama biçimlerine dönüştüğünden, genellikle bir soruna uygulandığında kodu anlamayı kolaylaştırır. Birleştirici, makine kodu üzerinde bir soyutlama, C, birleştirici üzerinde bir soyutlama vb.

Nesne yönelimli tasarım, nesneler açısından bir problemi modellememize izin vermede çok iyi görünmektedir, örneğin, bir üniversite ders kayıt sistemi problemi bir Coursesınıf, bir Studentsınıf vb. İle modellenebilir . Sonra, çözümü yazdığımızda OO dilinde, sorumluluk alan ve tasarım için, özellikle de kodu modüle etmek için genellikle yardımcı olan benzer sınıflarımız var. Eğer bu problemi bir OO yöntemiyle çözen 10 bağımsız takıma verirsem, genellikle 10 çözüm ortak problem ile ilgili sınıflara sahip olacaktır. Bu sınıfların birleşmesine ve etkileşimlerine girmeye başladığınızda çok fazla farklılık olabilir, bu nedenle "sıfır temsili boşluk" diye bir şey yoktur.

Fonksiyonel Programlama ile ilgili deneyimim çok sınırlıdır (gerçek dünya kullanımı yoktur, sadece Hello World tipi programlar). Bu tür dillerin FP çözümlerini OO dillerinin yaptığı gibi sorunlara (düşük temsili bir boşlukla) kolayca eşleştirmeye nasıl izin verdiğini göremiyorum.

FP'nin eşzamanlı programlama açısından avantajlarını anlıyorum. Ama bir şey mi kaçırıyorum, yoksa FP temsili bir boşluğu azaltmakla ilgili değil (çözümleri daha kolay anlaşılır kılıyor)?

Bunu sormanın başka bir yolu: Aynı gerçek dünya sorununu çözen 10 farklı takımın FP kodunun ortak bir yanı var mı?

Vikipedi'den Soyutlama (bilgisayar bilimi) (benimkini vurgulayın):

Fonksiyonel programlama dilleri yaygın sergileyen fonksiyonlarla ilgili soyutlamalar gibi lamda soyutlamaların (bazı değişkenin bir fonksiyonu bir terim yapma), yüksek mertebeden fonksiyonlarının (parametreler fonksiyonlar), braket soyutlama (değişkenin bir fonksiyonu bir terim yapma).

Temsili boşluk potansiyel olarak arttırılabilir, çünkü [bazı] gerçek dünya sorunları bu tür soyutlamalarla kolayca modellenmez.

Temsili boşluğun azaldığını görmenin bir başka yolu, çözüm öğelerini soruna geri döndürmektir. 0Var ve 1makine kodu s ise, geri iz çok zordur Studentsınıf iz geri kolaydır. Tüm OO sınıfları problem alanına kolayca ulaşmaz, ancak birçoğu yapar.

FP soyutlamalarının problem alanının hangi kısmını çözdüklerini bulmak için her zaman açıklamaya gerek yoktur ( matematik problemleri dışında )?Tamam - bu konuda iyiyim. Daha birçok örneğe baktıktan sonra, FP soyutlamalarının sorunun veri işlemede ifade edilen kısımları için ne kadar açık olduğunu görüyorum.

İlgili bir soruya kabul edilen cevap UML bir Fonksiyonel programı modellemek için kullanılabilir mi? - "Fonksiyonel programcıların diyagramlar için fazla bir kullanımı yoktur." UML olup olmadığını gerçekten umursamıyorum, ancak FP soyutlamalarının anlaşılması / iletişiminin kolay olmasını merak ediyorum, yaygın olarak kullanılan diyagramlar yoksa (bu cevabın doğru olduğunu varsayarak). Yine, FP kullanım / anlama seviyem önemsizdir, bu yüzden basit FP programlarında şemalara gerek olmadığını anlıyorum.

OO tasarımı, her birinde kapsülleme (erişim kontrolü, bilgi gizleme) ile işlev / sınıf / paket düzeyinde soyutlamaya sahiptir, bu da karmaşıklığı yönetmeyi kolaylaştırır. Bunlar problemden çözüme ve daha kolay geri dönmeye izin veren unsurlardır.

Birçok cevap, analiz ve tasarımın FP'de OO'ya benzer şekilde nasıl yapıldığından bahsediyor, ancak kimse şimdiye kadar üst düzey bir şeyden bahsedemiyor (paul bazı ilginç şeyler gösterdi, ancak düşük seviyeli). Dün çok fazla Google Çalışması yaptım ve bazı ilginç tartışmalar buldum. Aşağıdakiler Simon Thompson'un (2004) (Vurgu madeni) Fonksiyonel Programları Yeniden Düzenleme'den alınmıştır.

Nesneye yönelik bir sistem tasarlanırken, tasarımın programlamadan önce olacağı düşünülmektedir. Tasarımlar, Eclipse gibi araçlarda desteklenen UML gibi bir sistem kullanılarak yazılacaktır. Yeni başlayan programcılar BlueJ gibi sistemleri kullanarak görsel tasarım yaklaşımını iyi öğrenebilirler. Fonksiyonel programlama için benzer bir metodoloji üzerindeki çalışmalar FAD: Fonksiyonel Analiz ve Tasarım'da rapor edilmiştir , ancak çok az çalışma vardır. Bunun birkaç nedeni olabilir.

• Mevcut fonksiyonel programlar tasarım gerektirmeyen bir ölçektir. Birçok işlevsel program küçüktür, ancak Glasgow Haskell Derleyicisi gibi diğerleri önemlidir.

• Fonksiyonel programlar doğrudan uygulama alanını modellemekte, böylece tasarımı ilgisiz hale getirmektedir. İşlevsel diller çeşitli güçlü soyutlamalar sağlarken, bunların gerçek dünyayı modellemek için gereken tüm ve sadece soyutlamaları sağladığını iddia etmek zordur.

• Fonksiyonel programlar gelişen bir dizi prototip olarak oluşturulmuştur.

Gelen Doktora tezi, yukarıda değinilen , Analiz ve tasarım yöntemleri (ADM) kullanmanın yararları paradigmalar bağımsız özetlenmiştir. Ancak, ADM'lerin uygulama paradigmasına uyması gerektiği konusunda bir tartışma yapılmıştır. Yani, OOADM en iyi OO programlama için çalışır ve FP gibi başka bir paradigmaya iyi uygulanmaz. İşte temsili boşluk dediğim şeyleri açıkladığını düşünüyorum büyük bir alıntı:

yazılım geliştirme için hangi paradigmanın en iyi desteği sağladığı konusunda uzun süre tartışılabilir, ancak sorun tanımından uygulama ve teslimata kadar tek bir paradigma içinde kaldığında en doğal, verimli ve etkili geliştirme paketini elde eder.

İşte FAD tarafından önerilen diyagramlar kümesi:

• Bir işlevi uygulamasında kullandığı işlevlerle sunan işlev bağımlılık diyagramları;
• tipler için aynı hizmeti sağlayan tip bağımlılık diyagramı; ve,
• sistemin modül mimarisinin görünümlerini sunan modül bağımlılık diyagramları.

Bir futbol (futbol) ligi ile ilgili veri üretimini otomatikleştiren bir sistem olan FAD tezinin 5.1 bölümünde bir vaka çalışması var. Gereksinimler% 100 işlevseldir, örn. Futbol maç sonuçları, lig tabloları, puanlama tabloları, katılım tabloları, oyuncuları takımlar arasında aktarma, yeni sonuçlardan sonra verileri güncelleme, vb. FAD, fonksiyonel olmayan gereksinimleri çözmek için nasıl çalıştığından bahsedilmez , "yeni işlevselliğe minimum maliyetle izin verilmesi gerektiğini" belirtmek dışında, neredeyse imkansız olan bir şey.

Ne yazık ki, FAD dışında, FP için önerilen modelleme dilleri (görsel) için modern referanslar görmüyorum. UML başka bir paradigma, bu yüzden unutmalıyız.

Temel veriler hemen hemen her paradigmada aynı şekilde yapılandırılmıştır. Bir zorunda gidiyoruz Studentbir, Coursebir nesne, bir yapı, bir kayıt ya da her ne olsun, vb. OOP ile fark, verilerin nasıl yapılandırıldığı değil, işlevlerin nasıl yapılandırıldığıdır.

Aslında fonksiyonel programları bir problem hakkındaki düşüncelerime çok daha yakın buluyorum. Örneğin, bir öğrencinin bir sonraki dönem için programını planlamak için, bir öğrencinin tamamladığı derslerin listesi, bir öğrencinin lisans programındaki dersler, bu dönem sunulan dersler, bir öğrencinin ön koşullarını tamamladığı dersler, çatışma vb.

Aniden, hangi sınıfın tüm bu listeleri oluşturması ve saklaması gerektiği belli değil. Hatta bu listelerin karmaşık kombinasyonları olduğunda. Ancak, gereken tek sınıf seçin.

FP'de, öğrenciyi ve ders listesini alan ve filtrelenmiş ders listesini döndüren işlevler yazarsınız. Tüm bu işlevleri bir modülde birlikte gruplayabilirsiniz. Bir sınıf ya da başka bir sınıfla birleştirmek zorunda değilsiniz.

Böylece veri modelleriniz, OOP programcılarının, diğer sınıfların kombinasyonları üzerinde çalışan işlevler koymak için uygun yerler sağlamaktan başka bir amacı olmayan sınıflarla kirlenmeden önce, modellerini nasıl düşündüklerine benziyor. OOP'da CourseStudentFilterListher zaman ihtiyaç duyduğunuz garip veya benzer sınıflar yok , ancak başlangıç ​​tasarımında asla düşünmeyin.

Yıllar önce Java dersimi aldığımda, çözümlerimizi tüm sınıfa göstermemiz bekleniyordu, bu yüzden insanların nasıl düşündüklerini görmeliydim; sorunları mantıksal olarak nasıl çözdüklerini. Çözümlerin üç veya dört ortak çözüm etrafında kümelenmesini bekledim. Bunun yerine, 30 öğrencinin sorunu 30 farklı şekilde çözdüğünü izledim.

Doğal olarak, yeni başlayan programcılar deneyim kazandıkça, ortak yazılım modellerine maruz kalacaklar, bu kalıpları kodlarında kullanmaya başlayacaklar ve sonra çözümleri birkaç optimal strateji etrafında birleşebilirler. Bu kalıplar, deneyimli geliştiricilerin iletişim kurabileceği teknik bir dil oluşturur.

Fonksiyonel programlamanın temelini oluşturan teknik dil matematiktir . Buna göre, fonksiyonel programlama kullanarak çözülmeye en uygun problemler aslında matematik problemleridir. Matematiğe göre, toplama ve çıkarma gibi iş çözümlerinde göreceğiniz matematik türünden bahsetmiyorum. Aksine, Math Overflow'da görebileceğiniz matematik türünden veya Orbitz'in arama motorunda (Lisp'de yazılmıştır) görebileceğiniz matematik türünden bahsediyorum.

Bu yönelim, gerçek dünyadaki programlama problemlerini çözmeye çalışan fonksiyonel programcılar için bazı önemli sonuçlara sahiptir:

1. İşlevsel programlama zorunlu olandan daha bildiricidir; öncelikle bilgisayara nasıl yapılacağını değil, ne yapacağını söylemekle ilgilidir.

2. Nesneye yönelik programlar genellikle yukarıdan aşağıya doğru oluşturulur. Bir sınıf tasarımı oluşturulur ve ayrıntılar doldurulur. İşlevsel programlar, alt düzeyden, daha üst düzey işlevlerle birleştirilen küçük, ayrıntılı işlevlerden başlayarak oluşturulur.

3. Fonksiyonel programlama, karmaşık mantığın prototipini oluşturmak, organik olarak değişebilen ve gelişebilen esnek programlar oluşturmak ve ilk tasarımın belirsiz olduğu yazılımlar oluşturmak için avantajlara sahip olabilir.

4. Nesneye yönelik programlar, iş alanları için daha uygun olabilir, çünkü sınıflar, nesneler arasındaki mesajlar ve yazılım kalıpları, iş alanıyla eşleşen, iş zekasını yakalayan ve belgeleyen bir yapı sağlar.

5. Tüm pratik yazılımlar yan etkiler (G / Ç) ürettiğinden, tamamen işlevsel programlama dilleri, matematiksel olarak saf kalırken (monadlar) bu yan etkileri üretmek için bir mekanizma gerektirir.

6. Fonksiyonel programlar, matematiksel yapıları nedeniyle daha kolay kanıtlanabilir. Haskell'in tip sistemi, çoğu OO dilinin bulamadığı şeyleri derleme zamanında bulabilir.

Ve bunun gibi. Bilgi işlemdeki pek çok şeyde olduğu gibi, nesne yönelimli diller ve işlevsel diller farklı ödünleşmelere sahiptir.

Bazı modern OO dilleri, kullanışlı fonksiyonel programlama kavramlarından bazılarını benimsemiştir, böylece her iki dünyanın da en iyisini elde edebilirsiniz. Linq ve onu desteklemek için eklenen dil özellikleri buna iyi bir örnektir.

Önemli bulduğum ve diğer cevaplarda ele alınmayan bir yönü vurgulamak istiyorum.

Her şeyden önce, sorunları ve çözümleri arasındaki temsili boşluğun, arka planlarına ve daha aşina oldukları kavramlara göre programcının zihninde daha fazla olabileceğini düşünüyorum.

OOP ve FP verilere ve operasyonlara iki farklı perspektiften bakarlar ve Robert Harvey'in zaten işaret ettiği gibi farklı ödünleşimler sağlarlar.

Farklı olmalarının önemli bir yönü, yazılımınızı genişletmelerine izin vermeleridir.

Veri türlerinin bir koleksiyonunun ve bir işlem koleksiyonunun olduğu durumu göz önünde bulundurun, örneğin farklı görüntü formatlarınız var ve görüntüleri işlemek için bir algoritma kütüphanesi tutuyorsunuz.

İşlevsel programlama, yazılımınıza yeni işlemler eklemenizi kolaylaştırır: kodunuzda yalnızca yerel bir değişikliğe ihtiyacınız vardır, yani farklı giriş veri biçimlerini işleyen yeni bir işlev eklersiniz. Öte yandan, yeni formatlar eklemek daha karmaşıktır: daha önce uyguladığınız tüm işlevleri değiştirmeniz gerekir (yerel olmayan değişiklik).

Nesne yönelimli yaklaşım bunun için simetriktir: her veri türü tüm işlemlerin kendi uygulamasını gerçekleştirir ve çalışma zamanında doğru uygulamayı seçmekten sorumludur (dinamik dağıtım). Bu, yeni bir veri türü (örn. Yeni bir görüntü formatı) eklemeyi kolaylaştırır: sadece yeni bir sınıf ekler ve tüm yöntemlerini uygularsınız. Öte yandan, yeni bir işlem eklemek, o işlemi sağlaması gereken tüm sınıfları değiştirmek anlamına gelir. Birçok dilde bu bir arabirimi genişleterek ve onu uygulayan tüm sınıfları uyarlayarak yapılır.

Bu farklı genişletme yaklaşımı, OOP'nin, işlem kümesinin, bu işlemlerin üzerinde çalıştığı veri türleri kümesinden daha az değiştiği bazı sorunlar için daha uygun olmasının nedenlerinden biridir. Tipik bir örnek GUI'lerdir: Tüm widget'ları uygulamaları gerektiğini operasyonların sabit bir dizi (var paint, resize, moveve benzeri) ile genişletmek istediğiniz widget bir koleksiyon.

Yani, bu boyuta göre, OOP ve FP kodunuzu düzenlemenin sadece iki speküler yoludur. Bkz. SICP , özellikle Bölüm 2.4.3, Tablo 2.22 ve Mesaj iletimi paragrafı .

Özetleme: OOP'de işlemleri düzenlemek için verileri, FP'de verileri düzenlemek için kullanırsınız. Her yaklaşım, bağlama göre daha güçlü veya daha zayıftır. Genel olarak, bu ikisinin hiçbirinin problem ve çözüm arasında daha yüksek bir temsili boşluğu yoktur.

Çoğu işlevsel dil Nesneye Yönelik değildir. Bu, hiçbir nesneye sahip olmadıkları anlamına gelmez (kendileriyle ilişkili belirli işlevleri olan karmaşık türler anlamında). Haskell, java gibi Listeler, Haritalar, Diziler, her çeşit Ağaç ve daha birçok karmaşık türe sahiptir. Haskell Listesi veya Harita modülüne bakarsanız, çoğu eşdeğer OO dili kitaplığı modülündeki yöntemlere çok benzer bir dizi işlev görürsünüz. Kodu incelerseniz, bazı türler (veya kesin olarak kurucuları) ve yalnızca modüldeki diğer işlevler tarafından kullanılabilen işlevlerle benzer bir kapsülleme bile bulacaksınız.

Haskell'de bu tiplerle çalışma şekliniz genellikle OO yolundan pek farklı değildir. Haskell'de diyorum ki

  null xs
  length xs

ve Java’da

  xs.isEmpty
  xs.length

Domates, domates. Haskell işlevleri nesneye bağlı değildir, ancak türüyle yakından ilişkilidir. ¨Ah, ama , say diyorsun ki, ¨ Java’da , o nesnenin gerçek sınıfına hangi uzunluk yöntemine uygun olduğunu çağırıyor¨. Sürpriz - Haskell tip sınıflarıyla (ve diğer şeylerle) polimorfizm de yapıyor .

Haskell, ben varsa olduğunu - tamsayılar koleksiyonu - bu koleksiyon bir liste veya dizi veya dizi, bu kodu önemli değil ister

  fmap (* 2) is

tüm öğeleri ikiye katlayarak bir koleksiyon döndürür. Polimorfizm , spesifik tip için uygun harita fonksiyonunun çağırılacağı anlamına gelir .

Bu örnekler, gerçekte, gerçekten karmaşık türler değildir, ancak aynı şey daha zor problemler için de geçerlidir. İşlevsel dillerin karmaşık nesneleri modellemenize ve belirli işlevleri bunlarla ilişkilendirmenize izin vermediği fikri yanlıştır.

İşlevsel ve OO stili arasında önemli ve önemli farklılıklar vardır , ancak bu cevabın onlarla uğraşması gerektiğini düşünmüyorum. İşlevsel dillerin sorunların ve görevlerin sezgisel modellenmesini önleyip önlemediğini (veya engellediğini) sordunuz. Cevap hayır.

FP gerçekten temsili boşlukta bir azalma için çabalamaktadır:

İşlevsel dillerde çokça göreceğiniz bir şey, dili (aşağıdan yukarıya tasarım kullanarak) Gömülü Etki Alanına Özgü Dil (EDSL) haline getirme pratiğidir . Bu, işletme endişelerinizi programlama dilinde alan adınız için doğal bir şekilde ifade etmenin bir yolunu geliştirmenizi sağlar. Haskell ve Lisp bu konuda gurur duyuyorlar.

Bu yeteneği sağlayan şeyin bir kısmı (hepsi değilse de), temel dil (ler) in kendisinde daha fazla esneklik ve ifade gücüdür; birinci sınıf fonksiyonlar, yüksek dereceli fonksiyonlar, fonksiyon kompozisyonu ve bazı dillerde cebirsel veri türleri (AKA ayrımcı sendikalar) ve operatörleri * tanımlama yeteneği ile, şeyleri ifade etme konusunda OOP ile olduğundan daha fazla esneklik vardır. muhtemelen sorun alanınızdaki şeyleri ifade etmenin daha doğal yollarını bulacağınız anlamına gelir. (Birçok OOP dilinin, son zamanlarda bu özelliklerin çoğunu, onlarla başlamıyorsa, benimsediği bir şey söylemeliyiz.)

_{* Evet, birçok OOP dilinde standart operatörleri geçersiz kılabilirsiniz, ancak Haskell'de yenilerini tanımlayabilirsiniz!}

İşlevsel dillerle (çoğunlukla F # ve Haskell, bazı Clojure ve biraz Lisp ve Erlang) çalışma deneyimime göre, sorunlu alanı OOP ile yaptığımdan daha kolay bir şekilde haritaya yerleştiriyorum - özellikle cebirsel veri türlerinde, derslerden daha esnek buluyorum. FP ile, özellikle Haskell ile başlarken beni bir döngü için atmış olan bir şey, emir veya OOP dillerinde alışkın olduğumdan biraz daha yüksek bir seviyede düşünmem / çalışmam gerektiğiydi; bununla da biraz uğraşıyor olabilirsiniz.

Niklaus Wirth'in söylediği gibi, "Algoritmalar + Veri Yapıları = Programlar". Fonksiyonel programlama algoritmaları organize etme yolu ile ilgilidir ve veri yapılarını düzenleme yolları hakkında çok fazla şey anlatmaz. Gerçekten de mutable (Lisp) ve değişmez (Haskell, Erlang) değişkenleri olan FP dilleri vardır. FP'yi bir şeyle karşılaştırmak ve karşılaştırmak istiyorsanız, zorunlu (C, Java) ve bildirimsel (Prolog) programlamayı seçmelisiniz.

OOP ise veri yapıları oluşturmanın ve bunlara algoritmalar eklemenin bir yoludur. FP, OOP'lara benzer veri yapıları oluşturmanızı engellemez. Bana inanmıyorsanız Haskell tipi bildirimlere bir göz atın. Bununla birlikte, çoğu FP dili işlevlerin veri yapılarına ait olmadığını ve aynı ad alanında olması gerektiğini kabul eder. Bu, işlev kompozisyonu aracılığıyla yeni algoritmalar oluşturmayı basitleştirmek için yapılır. Gerçekten de, bir işlevin hangi girdiyi aldığını ve hangi çıktıyı ürettiğini biliyorsanız, neden hangi veri yapısına ait olduğu da önemli olsun? Örneğin, addişlevin neden bir Tamsayı türü örneğinde çağrılması ve yalnızca iki Tamsayı bağımsız değişkeninden geçmek yerine bir bağımsız değişken iletilmesi gerekir?

Bu nedenle, FP'nin neden çözümleri genel olarak anlaşılmasını zorlaştırması gerektiğini anlamıyorum ve yine de yaptığını sanmıyorum. Bununla birlikte, deneyimli bir zorunlu programcının zorunlu olanları kesinlikle zor programlardan daha zor anlayacağını ve tam tersini aklınızda bulundurun. Bu, Windows'a benzer - Windows ortamıyla rahat olmak için 10 yıl yatırım yapan kişiler bir aylık kullanımdan sonra Linux'u zor bulduğunda ve Linux'a alışkın olanlar Windows'da aynı üretkenliği elde edemediğinde Linux ikilemi. Dolayısıyla, bahsettiğiniz 'temsili boşluk' çok özneldir.