함수 프로그래밍의 목표

Question

나는 항상 이것을 생각해 왔지만, 나는 확인이 필요하다. 함수형 프로그래밍의 목적은 작성된 프로그램을 수학적 증명으로 만드는 것이다. 프로그램이 올바르게 작성되면 "증명"되어 어떤 환경에서도 동일하게 작동 할 것으로 예상됩니다. 이것이 FP에서 불변이 필요한 이유입니다. 그렇지 않으면 상태 변경으로 예기치 않은 동작이 발생할 수 있으므로 "증명"의 정확성에 대한 보장이 없습니다.

Functional Programming을 기준으로 맞습니까?

Answer 1

너는 근거리에서 멀지는 않았지만 나는 그런 식으로 말하지 않을 것이다. 함수형 프로그래밍의 주된 목표는 프로그래머가 코드를 더 쉽게 추론 할 수 있도록하는 것이라고 생각합니다. 우리는 항상 정형화 된 형식을 가질 수있는 것은 아니며 실제로 대부분의 기능적 프로그래머는 자신의 프로그램을 위해 프로그래머를 구성하지 않습니다. 그러나 기능적 프로그램은 여전히 ​​생각하기 쉽습니다. 제 의견으로는 그것이 목표입니다. 그러나 어떻게 그리고 왜? 당신이 파일을 읽을 때이 배치 될 때

정적 대 동적

정적 개념은 코드와 관련이 있습니다. 동적 개념은 데이터가 프로그램을 통해 한 곳에서 다른 곳으로 흐르는 방법과 관련이 있습니다. 사람들은 동적으로 생각하는 것보다 훨씬 더 정적으로 생각합니다. 이 논쟁은 Dijkstra가 그의 세미 노트 논문 Go To Statement Considered Harmful에 작성한 것입니다. 논쟁은 코드 포인터가 동적으로 어떻게 움직이는 지 추적해야 할 필요가 있다면 코드를 이해하기 어렵다는 것입니다. 기본적으로 코드를 실행해야합니다. 이것은 적어도 코드 포인터가보다 정적 인 방식으로 동작하도록 요구하기위한 인수입니다. 따라서 대부분의 프로그래밍 언어는 GOTO를 구현하지 않고 대신 IF, FOR 및 WHILE을 허용합니다. 이를 구조화 프로그래밍이라고합니다. 이들은 더 정적이기 때문에 추론하기가 더 쉽습니다.

기능적 프로그래머가 제기 한 논거는 기능적 프로그램이 한 단계 더 제한되고 한 단계 더 정적이어서 한 단계 더 쉽게 추론 할 수 있다는 것입니다. 함수형 프로그램에서 코드는 값으로 평가되는 식으로, 어떤 일이 일어날 지 이해하기 위해 머리 속을 추적해야하므로 상태가 변하는 일련의 명령문이 아니라 결국 평가판이됩니다.

나는 함수형 프로그래밍을 사용하는 것이 쉽지 않다는 것을 말하지만, 논쟁은 쉽습니다. 작은 예제에서 이것을 시도해 보겠습니다. 표현식은 하위 표현식으로 구성되며 전체 표현식의 값을 이해하기 전에 하위 표현식을 먼저 평가하여 해당 값을 먼저 이해할 수 있습니다. 버그가있는 간단한 기능 프로그램으로이 작업을 시도해 보겠습니다. 다음은 하스켈 코드이다.

size l = 
    if null l 
    then 1 
    else 1 + size (tail l) 

total l = 
    if null l 
    then 0 
    else (head l) + total (tail l) 

average l = total l/size l 

"평균 [1,2,3]"을 평가하면 "1.5"가됩니다. 그건 맞지 않습니다! 내가 무엇을 할 수 있을지? 음 "평균 [1,2,3]"은 "1.5"로 감소했습니다. 평균에 대한 정의를 두 표현식으로 분리하면 "총계 l"과 "크기 l"이됩니다. 나는 인자 l이 [1,2,3]이므로 "total [1,2,3]"을 평가하고 "6"을 얻습니다. 그것이 올바르게 보이지만 "크기 [1,2,3]"는 "4"입니다. 아! 내 버그가 크기 함수에 있다는 것을 압니다. 그래서 나는 그것을 따라갈 것이고, "size [] == 1"로 끝나고 나의 기본 경우가 틀렸다는 것을 깨닫게 될 것이다. 나는 "then 0"이라고 써야했다.

대조적으로이 매우 유용한 추론 전략은 명령형 프로그래밍에서 작동하지 않습니다. 그 이유는 상태를 변경하는 프로세스에서 하위 명령문을 추출 할 수 없기 때문에 별도로 이해하기 위해서입니다. 성명서는 그 환경의 맥락을 벗어나 무의미하다. 동일한 버그를 가진 C 프로그램을 살펴 보겠습니다.내가 지난 번처럼

int average (int *l) { 
    int total = 0; 
    int size = 1; 
    int i; 
    for (i = 0; i < sizeof(l); i++) { 
     total = total + l[i]; 
     size = size + 1; 
    } 
    return total/size; 
} 

나는 여기에 같은 버그를 가지고 있지만 지금은 내가 어떻게 내 코드를 디버깅 할 수있는 간단한 문제로이 문제를 줄일 수있다? "size = size + 1"문은 내 프로그램의 하위 문 하나이지만 그 문맥 밖에서는 의미가 없습니다. 내 프로그램의이 하위 명령문이 독자적으로 올바르게 작동하는지 확인할 수는 없습니다. 디버거를 사용하고 로컬 상태를 추적하여 코드가 변경되는 것을주의 깊게 살펴보고 코드를주의 깊게 살펴볼 필요가 있습니다. 이것은 매우 역동적 인 과정입니다. 인간은 정적으로 훨씬 더 잘 생각합니다.

테스트 용이성

기능 프로그램은 단위 테스트에 용이하다. 예를 들어 이전의 평균 기능을 생각해보십시오. "size [] == 0"및 "size [1,2,3] == 3"과 같은 하위 표현식은 모두 완벽한 단위 테스트를 수행합니다. 특히 그들이 내가 과거에 실수를 저질렀다는 것을 알고 있다면!

이 프로그램을 리팩토링하거나 더 효율적으로 만들려고하는 경우를 상상해보십시오. 많은 작은 부품을 자동으로 테스트하는 것이 좋을 것입니다. 단위 테스트는 명령형 프로그래밍에서 확실히 가능하며 사람들은 항상 그렇게합니다.하지만 데이터를 가져 와서 데이터를 반환하고 항상 같은 방식으로 작동하는 함수가 있으면 단위 테스트는 그보다 더 쉽습니다.

사용 기능을 프로그래밍 할 때 할 수 있습니다 심지어 명령형 언어에서 사람들이 테스트하기 쉽도록하는 기능적인 방식으로 가능한 한 자신의 코드를 많이 작성해야한다고 생각 이러한 이유

. 그것에 대해 흑백이 될 이유는 없습니다. 그것은 도구가 아니라 종교입니다. 함수형 프로그래밍을 반으로 수행하면 코드의 테스트 가능성과 유지 관리 가능성을 크게 높일 수 있습니다. 나는 당신의 질문에 대답에서 많은 영감을 그린 실제로 하나

추가 읽기

한 큰이 주제에 기록 된 종이, 그리고 존 휴스에 의해 Why Functional Programming Matters입니다. 초급 프로그래머를 위해 고안된 전체 커리큘럼을보고 싶다면 How to Design Programs을 적극 권장합니다. 단위 테스트와 프로그램을 작고 이해하기 쉬운 하위 작업으로 나눠서 글쓰기를 쉽게 작성하는 데 중점을 둡니다. 그렇게함으로써 기능적 프로그래밍을 매우 강력하게 만드는 요소가 무엇인지 강조합니다.