Fonksiyonel programlama okunabilirliği [kapalı]

Bunu merak ediyorum çünkü herhangi bir fonksiyonel dili öğrenmeden önce hatırlıyorum, hepsini korkunç, korkunç, korkunç okunamaz buldum. Şimdi Haskell ve f # biliyorum, daha az kod okumak için biraz daha uzun sürüyor, ama bu küçük bir kod bir zorunlu dilde eşdeğer bir miktardan çok daha fazlasını yapar, bu yüzden net bir kazanç gibi hissediyor ve son derece değilim işlevsel olarak uygulanmaktadır.

İşte sorum, OOP milletinden sürekli olarak fonksiyonel tarzın korkunç derecede okunaksız olduğunu duyuyorum. Durumun bu olup olmadığını merak ediyorum ve kendimi kandırıyorum ya da fonksiyonel bir dil öğrenmek için zaman ayırırlarsa, tüm stil artık OOP'tan daha okunamaz olmaz mı?

Herhangi bir kanıt gördü ya da herhangi bir şekilde böyle söyleyecek kadar sık ​​sık gördükleri herhangi bir anekdot var mı? İşlevsel olarak yazmak gerçekten daha düşük okunabilirliğe sahipse, kullanmaya devam etmek istemiyorum, ancak durumun bu olup olmadığını gerçekten bilmiyorum ..

Kod okunabilirliği çok özneldir . Bu nedenle, farklı insanlar aynı kodu okunabilir veya okunamaz olarak değerlendirir.

Bir ödev, x = x + 1bir matematikçiye garip geliyor, çünkü bir ödev yanıltıcı bir şekilde karşılaştırmaya benziyor.

Basit bir OOP tasarım modeli, bu kalıplara aşina olmayan biri için tamamen belirsiz olacaktır. Singleton'u düşünün . Birisi "Neden özel bir kurucuya ihtiyacım var? Gizemli yöntem getInstance() nedir? Neden küresel bir değişken oluşturup orada bir nesne atamıyoruz?"

Aynısı bir FP kodu için de geçerlidir. Sahne arkasındaki mantıksal kalıpları bilmediğiniz sürece , çok temel bir şeyi anlamak bile çok zor olacaktır, örneğin bir işlevi başka bir işleve argüman olarak nasıl geçireceğiniz.

Bunu söyledikten sonra, FP'nin gümüş bir kurşun olmadığını anlamak gerekir. FP'nin uygulanmasının zor olacağı birçok uygulama vardır ve bu nedenle daha kötü okunabilir bir koda yol açacaktır .

Kısa cevap:

İnsanlara fonksiyonel programlama kodunun okunmasının zor olduğunu söyleyen unsurlardan biri, daha kompakt bir sözdizimini tercih etmesidir.

Uzun cevap:

Fonksiyonel programlamanın kendisi okunabilir veya okunamaz olamaz, çünkü bu bir kod yazma tarzı değil, bir paradigmadır. Örneğin C # 'da fonksiyonel programlama şöyle görünür:

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

ve Java, C # veya benzeri dillerde yeterli deneyime sahip herhangi bir kişi tarafından okunabilir kabul edilir.

Dil sözdizimi, popüler OOP dillerine kıyasla birçok işlevsel dil için (Haskell ve F # dahil) daha kompakttır ve sade İngilizce sözcük yerine sembollere tercih eder.

Bu, FP dışındaki diller için de geçerlidir. Popüler OOP dillerini, daha fazla İngilizce kelime kullanma eğiliminde olan daha az popüler olanlarla karşılaştırırsanız, sonuncusu programlama deneyimi olmayan kişiler için anlaşılması daha kolay olur.

Karşılaştırmak:

public void IsWithinRanges<T>(T number, param Range<T>[] ranges) where T : INumeric
{
    foreach (var range in ranges)
    {
        if (number >= range.Left && number <= range.Right)
        {
            return true;
        }
    }

    return false;
}

için:

public function void IsWithinRanges
    with parameters T number, param array of (Range of T) ranges
    using generic type T
    given that T implements INumeric
{
    for each (var range in ranges)
    {
        if (number is from range.Left to range.Right)
        {
            return true;
        }
    }

    return false;
}

Aynı şekilde:

var a = ((b - c) in 1..n) ? d : 0;

hayali bir dilde şöyle ifade edilebilir:

define variable a being equal to d if (b minus c) is between 1 and n or 0 otherwise;

Kısa sözdizimi ne zaman daha iyidir?

Yeni başlayanlar için daha ayrıntılı sözdizimini anlamak daha kolay olsa da, deneyimli geliştiriciler için daha kompakt sözdizimi daha kolaydır. Daha kısa kod yazmak daha az karakter anlamına gelir, bu da daha fazla üretkenlik anlamına gelir.

Özellikle, bir kişiyi sözdiziminden çıkarılabilecek bir şeyi belirtmek için bir anahtar kelime yazmaya zorlamak mantıklı değildir.

Örnekler:

• PHP'de function, bunu yapmak için özel bir neden olmaksızın, her işlev veya yöntemden önce yazmanız gerekir .

• Ada, özellikle otomatik tamamlama ile doğru IDE olmadığından, geliştiricileri birçok İngilizce kelime yazmaya zorladığı için beni her zaman dehşete düşürdü. Son zamanlarda Ada'yı kullanmadım ve resmi eğitimleri bitti, bu yüzden örnek veremem; herhangi birinin bir örneği varsa, cevabımı değiştirmekten çekinmeyin.

• Sözdizimi 1..nbirçok FP (ve Matlab) 'de kullanılan, ile ikame edilmiş olabilir between 1, nya da between 1 and nya da between (1, n). betweenAnahtar kelime çok daha kolay dil sözdizimi aşina olmayan, ama yine de, iki nokta yazmak için çok daha hızlı insanlar için anlaşılması mümkün kılar.

Bunun nedenlerinden birinin fonksiyonel programlamanın çok daha soyut kavramlarla çalışma eğiliminde olduğunu düşünüyorum. Bu, kavramları bilen ve anlayan insanlar için kodu daha kısa ve daha okunabilir hale getirir (çünkü sorunun özünü uygun bir şekilde ifade ettikleri için), ancak bunlara aşina olmayan insanlar için okunamaz.

Örneğin, işlevsel bir programcı için, Maybemonad veya Eithermonad içindeki farklı noktalarda başarısız olabilecek bir kod yazmak doğaldır . Veya, Statemonad'ın yardımıyla durumsal bir hesaplama yazmak için . Ancak monad kavramını anlamayan biri için, bunların hepsi bir çeşit siyah büyücülük gibi görünüyor.

Bu yüzden, bir OOP çalışanlarından oluşan bir ekipte bile, işlevsel programlama parçalarını kullanmanın, bir işlevi veya kapanışları olan bir koleksiyon üzerinde eşleme gibi anlaşılması veya öğrenilmesi kolay kavramlar kullanması mantıklı olacağını düşünüyorum .

(Ve tabii ki, bir parça kod yazan programcıya da bağlıdır. Herhangi bir dilde korkunç bir şekilde okunamayan kod yazabilir, ayrıca güzel ve temiz bir tarzda yazabilirsiniz.)

Okunabilirliğin paradigmalar, modeller ve benzerleri ile ilgisi yoktur. Kod, sorunlu alanınızın anlambilimini ne kadar çok yansıtırsa, bu tür bir sorunlu alanın terminolojisi ve deyimleri ne kadar çok çalışırsa, o kadar okunabilir.

OOP kodunun hiç okunabilir olmamasının nedeni budur: birçok gerçek dünya probleminin doğal olarak hiyerarşik taksonomiler açısından ifade edilmemesi. Mesajları birbirine geçen nesneler tuhaf bir kavramdır ve "gerçek" olan her şeyden çok uzaktır. Şaşırtıcı bir şekilde, fonksiyonel deyimlere doğal olarak eşleştirilebilen çok daha gerçek dünya kavramları var. Sorunlar deklaratif olarak tanımlanma eğilimindedir, bu nedenle deklaratif bir çözüm daha doğaldır.

Bununla birlikte, gerçek dünyaya saf işlevsel, saf OOP, saf veri akışı veya saf olan her şeyden daha yakın olabilecek birçok anlambilim vardır. Ve bu nedenle, problem çözme için dil odaklı bir yaklaşım, mevcut tüm "saf" paradigmaları yenerek en okunabilir kodu üretir. Etki alanına özgü dillerle her sorun kendi doğal terminolojisinde ifade edilir. Ve fonksiyonel diller, DSL'lerin uygulanmasını kolaylaştırmada OOP ana akımlarından biraz daha iyidir (ancak daha iyi yaklaşımlar mevcuttur).

Kod okunabilirliği özneldir. Eminim bazı insanlar bunu anlama eksikliği nedeniyle eleştirir. Ortak örüntülerin uygulanma biçiminde doğal olarak farklı deyimler vardır. Örneğin, Ziyaretçi kalıbı, kalıp eşleşmesi olan bir dilde gerçekten anlamlı değildir .

Tür çıkarımı zor bir özellik olabilir. Genellikle, bu büyük bir gelişme hızlandırıcıdır, ancak kafa karıştırıcı hatalara yol açan bağlam eksikliği nedeniyle hangi türlerin dahil olduğunu anlamak bazen zor olabilir. Bu Fonksiyonel Programlama dilleri ile sınırlı değildir - C ++ şablonlarında da gördüm!

Modern diller çoklu paradigma olma eğilimindedir . Buna hem C # hem de F # dahildir. C # 'da fonksiyonel bir stil ve F #' da zorunlu bir stil yazmak mümkündür. İşlevsel dilleri eleştiren aynı kişiler muhtemelen nesne yönelimli dillerinde işlevsel kod yazarlar.

İşlevsel dillerde ticari gelişme hâlâ nispeten olgunlaşmamaktadır. Herhangi bir dilde kötü form olarak kabul edilecek bir takım hatalar gördüm. Gibi:

1. Dili öğrenirken (ve yeniden düzenleme yapmadan) tarzı değiştirmek tutarsızlığa yol açar.
2. Bir dosyada çok fazla.
3. Bir satırda çok fazla ifade var.