상태 변경에 의존하지 않는 것이 좋은 이유는 무엇입니까?


16

이 질문은 /software/25569/is-haskell-worth-learning 질문에서 발생합니다

일반적으로 Haskell이 다른 언어로 코딩 기술을 향상시키는 방법에 대해 자주 반복되는 진술이 있으며, 이는 Haskell이 무국적자이기 때문에 좋은 일입니다.

왜?

나는 누군가가 이것을 왼손으로 타이핑하거나 하루 동안 눈을 감고 터치에 의존하는 것과 비교하는 것을 보았습니다. 분명히 그것보다 더 많은 것이 있습니까?

하드웨어 메모리 액세스 또는 성능이 크게 향상되는 것과 관련이 있습니까?


2
하스켈은 학문적입니다. Rich Hickey가 Clojure에 대해 강의하는 것을 보았습니다. 그는 살인자 실용적인 주장을합니다 (Javier의 3 점과 비슷하지만 간단한 방법으로 수행).
직업


6
Haskell이 "학문적"이라고해서 비실용적이거나 실용적이지 않다는 의미는 아닙니다.
Tikhon Jelvis

답변:


17

내 머리 꼭대기에는 적어도 세 가지 큰 장점이 있습니다.

  1. 프로그램을 수학적 표현에 더 가깝게 만듭니다. 수학에서는 x변하지 않고 방정식을 풀기 전까지는 그 값이 무엇인지 모릅니다.

  2. 결국,이 있습니다 (컴퓨터가 낮은 수준에서 작동하는 방법은 결국,) 상태 변화; 그러나 언어에 의해 특정 장소에 국한됩니다. 이를 통해 컴파일러는 다른 코드가 의존하는 것을 변경하지 않는다는 것을 알고 있기 때문에 코드를 최적화하여 코드를 최적화 할 수 있습니다.

  3. 동시 코드는 변경되지 않는 데이터에 액세스하기 위해 동기화 할 필요가 없으므로 SMP 공유 메모리 시스템 (오늘날의 모든 멀티 코어 시스템)과 느슨하게 연결된 클러스터 모두에서 동시성이 향상됩니다.


3
함수형 프로그래밍의 지지자들은 대부분의 스트레스 # 3, 즉 동시성 프 래밍이 쉬워졌습니다.
Mchl

4
@Mchl : 제 경험상 그들은 "이해하기가 쉽고 이해하기 쉬워요."에 가장 많은 스트레스를주었습니다. 언어 커뮤니티마다 다를 수 있습니다.
sepp2k

+1, 매우 완전한 답변. @ sepp2k : 둘 다 중요합니다. 프로그램에 대한 추론은 우리가 매일하는 일이며, 매우 숨겨진 기능으로 상태가 변경되지 않았 음을 확인할 필요가 없다면 고급 방법 만 읽고 진행 상황을 파악하는 것이 훨씬 쉽다는 것이 사실입니다. 하드웨어 측면 : 멀티 코어 및 멀티 프로세서로 갈수록 이동하고 있기 때문에 (가정용 컴퓨터가 멀티 프로세서를 사용하기까지는 시간이 걸리 겠지만) 동시 프로그래밍을 용이하게하는 언어가 중요합니다.
Matthieu M.

좋은 대답, # 2는 내가 대답이라고 생각한 것으로, 다중 처리 이점에 대해 자주 읽었지만 명확하게 훌륭한 직업으로 언급되는 경우는 거의 없습니다.
ocodo

1
@Yttrill, 기능적 언어는 가비지 수집에 의존하는 고유 한 것이 아니며 가비지 수집은 불변 데이터를 처리 할 때 훨씬 더 쉽습니다. 명령어 기반 아키텍처에서 계산을 수행한다는 것은 상태를 수정하는 것을 의미합니다. 즉, 기능적 언어가 병렬 처리가 더 어렵다는 것을 의미하지는 않습니다. 기능적 언어는 병렬 처리로 흔들립니다. 조회 데이터 병렬 Haskell은 명령형 언어에 추가하기가 거의 불가능한 기능입니다.
dan_waterworth

4

또 다른 장점은 커플 링 감소입니다. 다음과 같은 코드가 있다면 :

 function doStuff(x) { return x + y;}

그리고 다른 곳에서는 :

 function doOtherStuff(x) { y++; return y + x;}

두 함수는 내재적 으로 의존 합니다. 호출 doStuff이 호출 에 의해 영향을 받는다는 것을 쉽게 알 수있는 방법은 없습니다 doOtherStuff. 변경 가능한 상태가 없으면 연결을 명시 적으로 만들어야합니다.

물론, 이것은 모든 가변 상태 의 문제가 아니며 확산 가능한 가변 상태의 문제입니다. 실제 솔루션은 기본적으로 불변성을 가지고 있으며 변경 가능한 상태를 필요한 곳에 "마킹"하고 제한하는 방법입니다.


+1. 많은 숙련 된 프로그래머는 위와 같은 코드를 작성하지 않는 것을 알고 있으며 "이 상황에서 변경 가능한 상태가 좋지 않습니다"에서 "변경 가능하고 더 기능적으로 쓰는 상태의 양을 심각하게 줄이십시오"로 전환하는 것은 큰 단계가 아니지만 단계입니다. 실망스럽게도 몇 사람이 만들었습니다.
dan_waterworth

2

간단히 대답하면, 순전히 기능적인 언어로 이름을 볼 때 간단한 정의를 통해 관련 값이 무엇인지 알 수 있습니다. 변경 가능한 변수가있는 경우 마지막으로 실행 된 여러 할당 중 하나만 알 수 있으므로 제어 흐름도 분석해야합니다. 이는 제어 조건을 조건부로 설정하여 여러 가능성을 갖게합니다. 지수 폭발을 얻으려면 과제의 RHS 자체가 변수에 의존한다는 것을 고려해야하므로 재귀 적으로 변수를 분석해야합니다.

위의 분석에서 결론은 의도, 불변 및 의미를 설명하는 주석 없이는 불가능하다는 것입니다. 해석하기 어려울 수 있으며 의미가 실제 코드에서 준수되는지 확인하기가 어려울 수 있습니다.

이 답변은 기본적으로 @ Javier 's point 1의 확장입니다.

또한 사기성 OO 체제의 인기에 대한 설명이라고 생각합니다. OO를 사용하면 가변 상태가 캡슐화되어 돌연변이를 어느 정도 지역화하고 의미론을 훨씬 더 강력하게 표현하고 확인할 수 있으므로 분석이 훨씬 쉬워집니다.

함수형 프로그래밍은 답이 아닙니다. 정답은 유도 (기능) 및 공동 (프로 시저) 프로그래밍을 모두 지원하는 시스템이므로 올바른 도구는 상태 비 저장 및 상태 저장 프로그래밍을 모두 처리 할 수 ​​있습니다. 국가 관리 이론은 아직 초기 단계 인 반면 건설적인 (기능적) 이론은 잘 확립되어 있습니다.


함수형 프로그래밍과 명령형 프로그래밍을 혼합하는 것은 Haskell의 기능입니다. 정상적인 함수는 기능적이지만 상태 기반 계산은 do-notation으로 표현할 수 있으므로 변경 가능한 상태를 신중하게 격리하고 제어 할 수 있습니다. 이것이 가장 실용적인 STM 구현 언어가 Haskell 입니다.
Tikhon Jelvis

Do-notation은 실제로 상태 저장 계산 자체 를 수행 할 작업이 없습니다 . Do-notation은 모나드 함수 파이프 라인의 간단한 구문입니다. 상태 저장 계산은 모나드를 사용하여 표현할 수있는 것 중 하나이며 따라서 표기법입니다.
Jonathan Sterling

기능 및 명령 프로그래밍이 혼합되어 있으면 거의 모든 언어가 존재합니다. Haskell은 상태 저장 부분을 분리 할 수있는 방법을 제공했을 수도 있지만, 이것이 적절한 혼합이되지는 않습니다. 자선은 어떻게해야합니까 (IMHO)와 비슷합니다.
트릴

2

Haskell로 작성된 DBMS 인 Siege 의 저자로서 일부는 변경 가능한 상태에 대한 나의 견해를 충돌이라고 할 수 있습니다. 나는 다르게 보여주고 싶다.

변경 가능한 상태의 목적은 시스템의 현재 상태를 설명하는 것입니다. 블로그가 있고 데이터베이스에 의해 백엔드라고 가정하면 데이터베이스는 사용자가 쿼리하는 시점에 블로그에있는 게시물을 설명합니다. 그것. 현재 몇 개의 게시물이 있습니까?

이것을 사실을 전달하는 데 사용되는 불변 상태와 대조하십시오. 8 월 12 일에 몇 개의 게시물이 있습니까?

사실은 추론하기 쉽고 변경 가능한 상태는 아닙니다. 그러나 변하기 쉬운 상태는 우리의 마음의 범위에서 추방되어야하는 악의적 불순한 영향이 아니다. 우리는 종종 우리가 살고있는 변하기 쉬운 세상에 공존해야하며, 좀 더 드물게 사용해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.