함수형 프로그래밍으로 코드가 복잡해 집니까? [닫은]

작년 한 해 동안 나는 스칼라 코드를 작성 했습니다 (자바 배경에서 나옴 ). Val, case 클래스, map / filter / lambda 함수, 암시 적 및 형식 유추를 사용하여 더 간단하고 깔끔한 코드를 만드는 방법이 정말 마음에 들었습니다. 나는 주로 Akka 기반 응용 프로그램에 사용했습니다 .

올해 저는 기능 프로그래밍을 정말 좋아하는 새로운 팀과 함께 스칼라 프로젝트를 진행하고 있습니다. 그들은 Scalaz를 많이 사용 하며 코드는 응용 프로그램, 컨텍스트 범위, 리더 / 라이터 / 상태 모나드로 어디에나 채워져 있으며 주요 방법조차 I / O 모나드에 "랩핑"되어 있습니다. 그들의 추론은 이것이 컴파일러가 코드가 정확하고 각 함수에 부작용이 없다고 주장하는데있어 "우리를 위해 일하게"한다는 것이다.

그럼에도 불구하고, 내 관점 에서이 모든 구문은 실제로 비즈니스 논리를 방해합니다. 예를 들어 "MyBusinessObject"유형은 "List [MyBusinessObject]", "Option [MyBusinessObject]"또는 "Future [MyBusinessObject]"와 같은 유형도 좋습니다. 그들은 모두 명확한 의미와 목적을 가지고 있습니다. 반면에 코드는 다음과 같습니다.

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
  }
}

프로그램에 복잡성을 추가합니까, 아니면이 프로그래밍 방식에 익숙하지 않은 것이 저입니까?

이것은 함수형 프로그래밍과 는 아무런 관련이 없습니다. 다른 프로그래밍 언어와 관련하여 이런 상황을 찾을 수 있습니다. "그들의"언어의 고급 구문을 너무 좋아하는 개발자는 가독성에 대한 상식을 무시하고 단순하게 유지하는 개발자입니다. C, C ++, Perl, Java, C #, Basic 및 기타 비 기능적 언어에서 이러한 상황이 발생했습니다. 프로그래머에게는 복잡한 코드를 추가하는 기능 프로그래밍이 아닙니다.

잘못 이해하지 마십시오. 고급 언어 기능을 사용하지 않는 것이 좋습니다. 그러나 주어진 상황에서 올바른 균형을 찾는 것이 중요합니다. 전 세계 10 만 명 이상의 개발자가 사용할 수있는 일반 라이브러리를 작성할 때는 지역 사무소에 대해서만 개별 보고서 생성기를 작성할 때 적용 할 수있는 방법이 다릅니다.

나는 그들이 코딩하는 방식에 적어도 익숙하지 않다고 말하고 싶습니다. 나는 C #에서 F #으로 와서 Haskell 배경을 가진 사람들과 함께 일하는 것과 비슷한 상황에 처해 있으며 재미있는 경험을 발견하는 동안 벽에 머리를 대고 엉키지 않는 순간이 있습니다. 특히 복잡한 점이없는 함수 구성으로 인해 진행중인 작업을 중단 할 수 있습니다. 문화적인 것입니다.

이 특정 코드가 프로그램에 복잡성을 추가하는지 여부는 알 수 없습니다. 일반적인 코드 조각 자체가 복잡 할 수 있다는 데 동의했습니다. 그러나 이것은 비즈니스 로직의 일부가 아닌 유틸리티입니다. 그것이 코드베이스를 더 복잡하게 만들거나 더 단순하게 만들고 있는지 알고 싶다면, 그 코드없이 어떻게 보일지 상상해야 할 것입니다. 일반적으로 이러한 일반적인 구성이 복잡한 경우가 많지만 단일 화면에 맞출 수있는 복잡성입니다. 동시에 전체 코드베이스를 상당히 단순하게 만듭니다. 이것은 특히 모나드의 경우입니다.

그런 다음 @Doc Brown이 제안한 것처럼 '예술을위한 예술'의 사례가 될 수도 있습니다. 어느 것도 배제 할 수 없습니다.

나는 일반적으로 함수형 프로그래밍에서 변경 가능한 상태를 제거 함으로써 복잡성을 줄임으로써 코드 섹션의 작동 방식을 이해하려고 할 때 고려해야 할 사례 수를 줄인다고 주장합니다.

그러나 함수형 프로그래밍은 더 높은 수준의 추상화를 가능하게하며, 매우 추상적 인 코드는 매우 유용 할 수 있지만 이해를 돕기 위해 일반적으로 사용하는 컨텍스트와 정의가 다르기 때문에 이해하기 어려울 수도 있습니다. 비즈니스 객체에 대한 "모두 명확한 의미와 목적을 가지고 있습니다"라는 의견은 의심 할 여지없이 사실이지만, 그 논리가 이미 이해하고있는 필요와 맥락에 매우 구체적이라는 사실을 반영한 것입니다. Monad와 같은 구문이 있으면 약간의 노력으로 무언가를 매우 유용하게 만들 수 있지만 웹에는 Monad가 무엇인지 설명하려는 페이지가 흩어져 있습니다. 그것은 당신을위한 추상화입니다.

또한 Scalaz는 FP를 오랫동안 먹고 호흡 한 사람들이 작성했습니다. 그들은 Haskell에서 사용할 수있는 기능을 Scala로 가져오고 싶었습니다. 그렇게하면서 그들은 교육학적인 시도를하지 않았다. 스칼라 즈 (Scalaz)는 어휘와 스타일을 사용하여 저자에게는 명확하고 솔직 해 보이지만 미숙 한 사람에게는 외계인입니다. 우리의 나머지 사람들에게 당혹스러운 방법은 저자에게 하스켈 배경을 감안할 때 너무 분명해 보였으므로 의견을 보증하지 않았습니다.

또한 기능적 프로그래밍 언어 인 Scala에는 Scalaz 작성자가 경우에 따라 못생긴 코드를 작성 해야하는 단점이 있습니다 (일부 JVM에는 단점이 있기 때문에). 예를 들어 일반적인 테일 콜 제거 기능이 없으면 일부 코드에서 트램펄린을 사용해야하며 "종류 시스템"이 없으면 형식 서명이 복잡해질 수 있습니다.

그리고 마지막으로, Scalaz는 그 자체를 잘 활용합니다. 그것은 그것의 힘의 표시로 생각할 수 있지만, 시작되지 않은 사람들에게는 소스를 퍼즐로 만들 수 있습니다-당신이 보는 임의의 코드 조각은 당신에게 외계인으로 보이는 다른 것을 사용할 것입니다.

잠깐만 그리고 이것은 도움 이 될 수 있습니다.

프로그램에 복잡성을 추가합니까, 아니면 이런 프로그래밍 방식에 익숙하지 않은 것입니까?

왜 이러한 가능성이 같지 않다고 생각합니까?

잘 작성된 코드는 특정 프로그래밍 언어에 익숙하지 않은 사람들이 읽을 수 있습니다. 어떤 언어 (BASIC, Pascal 등)는 프로그래밍 언어를 전혀 본 적이없는 학교 학생들이 읽고 이해할 수 있습니다.

다른 언어에 대한 경험과 스칼라에 대한 경험이있는 사람 (그리고 내가 일주일 이상 Scalaz와 함께 일했으며 더 까다로운 일을 설명 할 동료가 있다고 생각하는 사람)이 여전히 혼란 스러울 경우; 그것이 복잡성을 더했다는 증거입니다.