부작용은 자연스러운 현상이라고 생각합니다. 그러나 그것은 기능적 언어에서 금기와 같은 것입니다. 이유는 무엇입니까?
내 질문은 기능적 프로그래밍 스타일에 관한 것입니다. 모든 프로그래밍 언어 / 패러다임이 아닙니다.
답변
부작용없이 함수 / 메소드를 작성 하면 순수한 함수 이므로 프로그램의 정확성을 쉽게 추론 할 수 있습니다.
또한 이러한 기능을 쉽게 작성하여 새로운 동작을 만들 수 있습니다.
또한 컴파일러가 함수 결과를 기억하거나 공통 하위 표현식 제거를 사용할 수있는 특정 최적화가 가능합니다.
편집 : Benjol의 요청에 : 많은 상태가 스택에 저장되기 때문에 (Jonas가 여기에서 호출 한 것처럼 제어 흐름이 아닌 데이터 흐름 ), 독립적 인 계산 부분의 실행을 병렬화하거나 달리 재정렬 할 수 있습니다 서로. 한 부품은 다른 부품에 입력을 제공하지 않기 때문에 독립적 인 부품을 쉽게 찾을 수 있습니다.
스택을 롤백하고 컴퓨팅 (예 : 스몰 토크)을 재개 할 수있는 디버거가있는 환경에서 순수한 기능을 사용하면 이전 상태를 검사 할 수 있기 때문에 값이 어떻게 변경되는지 매우 쉽게 확인할 수 있습니다. 돌연변이가 많은 계산에서는 구조 / 알고리즘에 do / undo 작업을 명시 적으로 추가하지 않으면 계산 기록을 볼 수 없습니다. (이것은 첫 번째 단락과 연결됩니다. 순수한 함수를 작성하면 프로그램의 정확성을 쉽게 검사 할 수 있습니다.)
답변
함수형 프로그래밍 에 관한 기사에서 :
실제로 응용 프로그램에는 부작용이 필요합니다. 함수형 프로그래밍 언어 Haskell의 주요 공헌자 인 Simon Peyton-Jones는 다음과 같이 말했습니다. “결국 모든 프로그램은 상태를 조작해야합니다. 상자가 뜨거워진다 ” ( http://oscon.blip.tv/file/324976 ) 핵심은 부작용을 제한하고 명확하게 식별하며 코드 전체에 흩어지지 않도록하는 것입니다.
답변
기능 프로그래밍은 부작용을 제한하여 프로그램을 이해하고 최적화하기 쉽게 만듭니다. Haskell조차도 파일에 쓸 수 있습니다.
본질적으로 함수형 프로그래머는 부작용이 악하다고 생각하지 않으며 부작용의 사용을 제한하는 것이 좋다고 생각합니다. 나는 그것이 단순한 구별처럼 보일 수 있지만 모든 차이를 만듭니다.
답변
몇 가지 참고 사항 :
-
부작용이없는 기능은 병렬로 간단하게 실행할 수 있지만 부작용이있는 기능은 일반적으로 일종의 동기화가 필요합니다.
-
부작용이없는 함수는 정확한 결과를 얻는 한 함수가 실제로 실행 되었는지 여부는 중요하지 않기 때문에보다 적극적인 최적화 (예 : 결과 캐시를 투명하게 사용)를 허용합니다.
답변
나는 주로 현재 기능 코드에서 일하고 있으며, 그 관점에서 맹목적으로 명백해 보입니다. 부작용은 코드를 읽고 이해하려는 프로그래머 에게 큰 정신적 부담을줍니다. 한동안 해방 될 때까지 그 부담을 느끼지 못하고 갑자기 부작용이있는 코드를 다시 읽어야합니다.
이 간단한 예를 고려하십시오.
val foo = 42
// Several lines of code you don't really care about, but that contain a
// lot of function calls that use foo and may or may not change its value
// by side effect.
// Code you are troubleshooting
// What's the expected value of foo here?
함수형 언어에서 나는 그것이foo 여전히 42 라는 것을 알고 있다. 나는 심지어 사이에있는 코드를 보거나, 훨씬 덜 이해하거나, 호출하는 함수의 구현 을 볼 필요조차 없다 .
동시성, 병렬화 및 최적화에 관한 모든 것이 훌륭하지만 컴퓨터 과학자들이 브로셔에 적어 놓은 것입니다. 누가 당신의 변수를 변형시키는 지 궁금하지 않고 매일 매일 연습하는 것이 정말 좋습니다.
답변
부작용을 일으키는 것이 불가능한 언어는 거의 없습니다. 완전히 부작용이없는 언어는 매우 제한된 용량을 제외하고는 사용하기가 엄청나게 어렵습니다.
부작용이 왜 악으로 간주됩니까?
프로그램이하는 일을 정확히 추론하고 예상 한 일을한다는 것을 증명하기가 훨씬 더 어렵 기 때문입니다.
매우 높은 수준에서 블랙 박스 테스트만으로 전체 3 계층 웹 사이트를 테스트한다고 상상해보십시오. 물론 규모에 따라 가능합니다. 그러나 분명히 많은 중복이 진행되고 있습니다. 이 경우 이다 버그가 (즉,이 부작용과 관련된) 버그가 진단 및 해결하고, 수정이 테스트 환경에 배포 될 때까지, 당신은 잠재적으로 더 테스트를 위해 전체 시스템을 망가뜨릴 수있다.
혜택
이제 축소하십시오. 부작용이없는 무료 코드를 작성하는 데 상당히 능숙하다면, 기존 코드가 무엇을했는지 추론하는 데 얼마나 더 빠릅니까? 단위 테스트를 얼마나 빨리 작성할 수 있습니까? 어떻게 확신 당신은 어떤 부작용과 코드가 버그가없는 보장 된 것으로, 사용자가이 버그에 대한 노출 제한 할 수 있음을 느낄 것 않았다 가 있습니까?
코드에 부작용이없는 경우 컴파일러에서 수행 할 수있는 추가 최적화가있을 수도 있습니다. 이러한 최적화를 구현하는 것이 훨씬 쉬울 수 있습니다. 부작용이없는 코드에 대한 최적화를 개념화하는 것이 훨씬 더 쉬울 수 있습니다. 즉, 컴파일러 공급 업체는 부작용이있는 코드에서는 불가능한 최적화를 구현할 수 있습니다.
또한 코드에 부작용이없는 경우 동시성을 구현, 자동 생성 및 최적화하는 것이 훨씬 간단합니다. 모든 조각을 임의의 순서로 안전하게 평가할 수 있기 때문입니다. 프로그래머가 고도의 동시 코드를 작성하도록 허용하는 것은 컴퓨터 과학이 해결해야 할 다음의 큰 도전과 무어의 법칙 에 대한 나머지 몇 가지 헤지 중 하나로 널리 알려져 있습니다.
답변
부작용은 코드에서 “누수”와 비슷하며 나중에 나 자신이나 의심하지 않는 동료가 처리해야합니다.
함수형 언어는 코드를 문맥에 덜 의존적이고 모듈화하는 방법으로 상태 변수와 가변 데이터를 피합니다. 모듈화는 한 개발자의 작업이 다른 개발자의 작업에 영향을 미치거나 손상시키지 않도록합니다.
팀 규모에 따른 개발 속도의 확장은 오늘날 소프트웨어 개발의 “성배”입니다. 다른 프로그래머와 함께 작업 할 때 모듈성만큼 중요한 것은 거의 없습니다. 가장 간단한 논리적 부작용조차도 공동 작업을 매우 어렵게 만듭니다.