Fonksiyonel programlama kodda karmaşıklık ekler mi? [kapalı]

Geçtiğimiz yıl boyunca (Java geçmişinden gelen) Scala kodu yazıldım . Vals, vaka sınıfları, harita / filtre / lambda fonksiyonları, çıkarımlar ve tür çıkarımı ile nasıl daha basit ve daha temiz bir kod oluşturabileceğinizi gerçekten sevdim. Daha çok Akka tabanlı bir uygulama için kullandım.

Bu yıl, fonksiyonel programlamayı gerçekten seven yeni bir ekiple Scala projesinde çalışıyorum. Scalaz'ı yoğun bir şekilde kullanıyorlar ve kod her yerde uygulamalar, bağlam sınırları, okuyucu / yazar / eyalet monad ile dolduruluyor, hatta ana yöntem bir I / O monadına "sarılıyor". Onların mantığı, bu kodun doğru olduğunu ve her fonksiyonun yan etkiler içermediğini iddia ederek derleyicinin "bizim için çalışmasını" sağlamasıdır.

Yine de, benim bakış açımdan, tüm bu sözdizimi gerçekten iş mantığının önüne geçer. Örneğin, bir tür "MyBusinessObject" iyidir ve "List [MyBusinessObject]", "Option [MyBusinessObject]" veya "Future [MyBusinessObject]" gibi türler de iyidir. Hepsinin açık bir anlamı ve amacı var. Öte yandan, aşağıdaki gibi kodlayın:

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

programa karmaşıklık katıyor mu, yoksa ben bu programlamaya alışkın değil miyim?

Bunun işlevsel programlama ile hiçbir ilgisi yoktur - bu tür bir durumu başka herhangi bir programlama dili bağlamında bulabilirsiniz - okunabilirlik ve işleri basit tutmayla ilgili herhangi bir ortak duyguyu göz ardı edecek kadar "kendi" dilinin gelişmiş yapılarını seven geliştiriciler. C, C ++, Perl, Java, C #, Basic ve işlevsel olmayan diğer dillerde böyle bir durumla karşılaştım. Programcıların kodlara karmaşıklık katan fonksiyonel programlama değil.

Beni yanlış anlamayın, gelişmiş dil özelliklerinden kaçınmanızı önermiyorum - ancak verilen bağlamda doğru dengeyi bulmak önemlidir. Tüm dünyada 100.000'den fazla geliştiricinin kullanımı için genel bir kütüphane yazarken, yalnızca yerel ofisiniz için ayrı bir rapor oluşturucu yazarken uygulanacak farklı önlemler vardır.

Kodlama şekline en azından resmin bir parçası olduğuna alışmadığınızı söyleyebilirim. Seninle benzer bir durumdayım (C # 'dan F #' a geliyorum ve Haskell geçmişi olan insanlarla çalışıyorum) ve ilginç bir deneyim bulduğumda, kafamı duvara vurduğumda, özellikle kıvrılmış noktasız fonksiyon bileşimi, orada olanları asmak için. Bu kültürel bir şey.

Bu özel kod programa karmaşıklık ekleyip eklemediğine gelince - bilmiyorum. Genel bir kod parçasının karmaşık olabileceğini kabul etti. Ama bu bir iş programı, iş mantığının bir parçası değil. Kod tabanını daha karmaşık veya basit hale getirip getirmediğini bilmek istiyorsanız, bu kod parçası olmadan nasıl görünmesi gerektiğini düşünmeniz gerekir. Bu tür jenerik yapılarda genellikle karmaşık oldukları görülür, ancak tek bir ekrana sığabileceğiniz bir karmaşıklıktır. Aynı zamanda tüm kod tabanını biraz daha basit hale getirir. Bu özellikle monadlarda geçerlidir.

Sonra tekrar, @Doc Brown'un önerdiği gibi, 'sanat uğruna sanat' örneği de olabilir. Bunu da göz ardı edemezsiniz.

Ben genel fonksiyonel programlamada iddia ediyorum azaltır ve böylece kanununun nasıl çalıştığını anlamak için çalışırken dikkate alınması gereken durumlarda sayısını azaltarak, değişken durumunu ortadan kaldırarak karmaşıklığı.

Bununla birlikte, fonksiyonel programlama daha yüksek soyutlama derecelerini mümkün kılar ve son derece soyut bir kod son derece yararlı olsa da, anlaşılması zor olabilir, çünkü tanım gereği, anlayışınızı yönlendirmek için normalde kullanacağınız bağlamdan ayrılmıştır. İş nesneleriyle ilgili "Hepsinin açık bir anlamı ve amacı var" yorumunuz şüphesiz doğrudur, ancak bu mantığın zaten anladığınız bir ihtiyaç ve bağlama çok özel olduğu gerçeğinin bir yansımasıdır. Monad gibi bir yapının varlığı, çok az çaba ile çok yararlı bir şey yapmanıza izin verir, ancak web, bir Monad'ın ne olduğunu açıklamaya çalışan sayfalarla doludur. Bu sizin için bir soyutlama.

Ayrıca Scalaz, FP'yi uzun süredir yiyip soluyan insanlar tarafından yazıldı; Haskell'deki işlevselliği Scala'ya getirmek istediler. Bunu yaparken pedagojik olma girişiminde bulunmadılar. Scalaz, yazarlara açık ve anlaşılır görünen ama deneyimsiz olanlara yabancı görünen bir kelime ve stil kullanır. Geri kalanlarımıza kafa karıştırıcı yöntemler, Haskell geçmişleri göz önüne alındığında, yazarlar için o kadar açık görünüyordu ki, bir yorum bile garanti etmediler.

Ayrıca, işlevsel bir programlama dili olarak Scala, Scalaz yazarlarını bazı durumlarda daha çirkin kod yazmaya zorlayan bazı eksikliklere sahiptir (kısmen JVM'nin eksiklikleri vardır). Örneğin, genel kuyruk çağrısının ortadan kaldırılması, bazı kodlarda trambolin kullanımını zorlar ve "tür bir sistem" in olmaması tip imzaları zorlaştırabilir.

Ve son olarak, Scalaz kendini çok iyi kullanıyor. Bu, gücünün bir işareti olarak düşünülebilir, ancak başlatılmamışlar için kaynağı bir bulmaca yapabilir - baktığınız herhangi bir rastgele kod parçası, size yabancı görünen başka bir şeyden yararlanır.

Pes etme. Ve bu yardımcı olabilir.

Programa karmaşıklık katıyor mu, yoksa sadece bu şekilde programlamaya alışkın değil misiniz?

Sizce bu olasılıklar aynı şey değil mi?

İyi yazılmış kod, belirli programlama diline aşina olmayan kişiler tarafından okunabilir. Bazı diller (BASIC, Pascal, vb.) Daha önce hiç programlama dili görmemiş okul çocukları tarafından okunabilir ve anlaşılabilir.

Diğer dillerle ve Scala ile deneyime sahip olan (ve en azından bir hafta boyunca Scalaz ile çalışmış ve daha karmaşık şeyleri açıklamak için meslektaşları olan) birisinin hala kafası karışmışsa; o zaman karmaşıklığı arttırdığının kanıtı budur.