고토는 끔찍한 재난이었습니다. Mutable State는 New Goto입니다.

gotos가 나쁘다고 생각했다면 mutable state가 가져올 수있는 결과를 알고 있어야합니다.

Unsplash에 Mahir Uysal의 사진

goto진술은 아마도 초기 프로그래밍 언어에서 버그의 가장 큰 원인이었을 것입니다. 그러나 우리가 여전히 똑같은 끔찍한 결과와 함께 현대 프로그래밍 언어에서 매일 그것을 사용한다는 것을 아는 사람은 거의 없습니다.

약간의 역사

Unsplash에 bert brrr의 사진

초기 프로그래밍 언어에서는 함수, 루프 및 if 문이 출현하기 전에 goto프로그램 제어 흐름을 관리하는 유일한 방법이었습니다.

gotowhile 루프 대신 문이 사용 된 방법은 다음과 같습니다 .

초기에는의 사용 goto이 버그의 가장 일반적인 원인 중 하나였습니다.

출처 : xkcd.com

1959 년에 열린 ALGOL 이전 회의에서 Heinz Zemanek은 GOTO 성명서의 필요성에 대해 명백하게 의심을 던졌습니다. 그 당시에는 나중에 GOTO의 상징적 인 상대가 된 Edsger W. Dijkstra를 포함하여 아무도 그의 발언에 관심을 기울이지 않았습니다. 1970 년대와 1980 년대에는 "구조화 된 프로그래밍"패러다임을 선호하는 GOTO 문 사용이 감소했으며, goto는 "유지할 수없는 스파게티 코드"로 이어지는 비판을 받았습니다.

아마도 GOTO에 대한 가장 유명한 비판은 Edsger Dijkstra의 1968 년 편지 인 Go To Statement Thoughmful. 그 편지에서 Dijkstra는 프로그램의 정확성을 분석하고 확인하는 작업을 복잡하게했기 때문에 제한되지 않은 GOTO 문은 고급 언어에서 폐지되어야한다고 주장했습니다. 이 편지 자체는 1987 년 3 월 ACM (CACM)에 발송 된“ '고토가 유해한 것으로 간주 됨'이 유해한 것으로 간주 됨”편지와 Dijkstra의 On a Somewhat Disappointing Correspondence를 비롯한 다른 사람들의 추가 답변을 포함하여 논쟁을 불러 일으켰습니다.

— 위키 백과

저명한 컴퓨터 과학자 인 Edsger Dijkstra는 goto문은 프로그램의 정확성을 분석하고 검증하는 작업을 복잡하게했기 때문에 고수준 언어에서 폐지되어야합니다. ”라고 올바르게 언급했습니다 . 즉, "어떻게이 실행 시점에 도달 했습니까?"라는 질문에 답하는 것입니다. goto사용 되었을 때 정말 힘들었습니다 . 이로 인해 일반적으로 디버그 (및 이해하기)가 매우 어려운 스파게티 코드가 생성되었습니다.

컴퓨팅의 두 가지 기둥

Unsplash에 Pea의 사진

먼저 "컴퓨터는 무엇을합니까?"라는 근본적인 질문에 답해 보겠습니다.

컴퓨터는 기본적으로 데이터를 처리합니다. 컴퓨터가 수행하는 모든 작업은 항상 일종의 데이터 처리입니다. 따라서 해당 데이터를 처리하는 데이터와 코드가 있습니다. 프로그램은 일부 데이터를 입력으로 가져오고 다른 처리 된 데이터를 출력합니다. 데이터가 메모리에로드 될 때마다이를 프로그램 상태 라고합니다 . 모든 개체 필드와 변수는 상태입니다. 모든 배열, 사전 및 맵도 프로그램 상태의 일부입니다.

코드와 상태는 당연히 컴퓨팅의 두 가지 기둥이라고 할 수 있습니다.

암호

먼저 코드에 대해 이야기합시다.

예전 goto에는 특정 실행 지점에 도달 한 방법을 말하기가 어려웠 기 때문에 사용 이 눈살을 찌푸 렸습니다. 고맙게도 구조화 프로그래밍 혁명, 루프, 함수 및 if 문이 도입되었습니다. 이로 인해 프로그램의 논리를 훨씬 쉽게 따를 수있게되었고, "이 실행 지점에 어떻게 도달 했습니까?"라는 주요 질문에 답할 수있게되었습니다. 훨씬 쉽게.

상태

두 번째 기둥은 어떻습니까? 이것은 일이 흥미로워지는 곳입니다. 일반적인 프로그램에서 "어떻게이 특정 상태에 도달 했습니까?"라는 질문에 쉽게 대답 할 수 있습니다.

사실은 아닙니다. 프로그래머가 어려운 버그를 디버깅하는 데 몇 시간, 경우에 따라 며칠을 보내는 것은 드문 일이 아닙니다. 시간은 주로 "왜 상태가 변경 되었습니까?"라는 질문에 답하는 데 사용됩니다.

이 게시물은 Jessica Joy Kerr의 트윗에서 영감을 받았습니다.

공감할 수 있습니까? 나는 여전히 일부 객체 지향 프로그램을 디버깅하는 고뇌를 기억합니다. 힘든 버그를 고치는 데 며칠을 보냈지 만 다른 곳에서 문제가 발생하도록했습니다.

고토의 사촌

Unsplash에 Tirza van Dijk의 사진

"어떻게이 특정 상태에 도달 했습니까?"라는 질문에 답할 수 있었으면 좋겠습니다. "이 실행 시점에 어떻게 도달 했습니까?"라는 질문에 답할 수있는 것처럼 매우 바람직합니다.

안타깝게도 Java, C #, JavaScript, TypeScript, Python 등의 주류 프로그래밍 언어에는 상태를 효율적으로 관리하기위한 기본 제공 구조가 없습니다. 예, 저는 현대 가비지 수집 프로그래밍 언어의 메모리 관리가 우리가 옛날에 가졌던 것 malloc(C에서 생각)보다 큰 발전이라는 데 동의합니다 . 가비지 수집은 컴퓨터 과학의 가장 큰 발전 중 하나입니다. 수동 메모리 관리 (및 메모리 누수)에 대해 걱정할 필요가 없으면 생산성이 크게 향상됩니다.

그러나 주류 프로그래밍 언어는 여전히 개발자에게 상태 관리 제약을 적용하는 기본 제공 방법을 제공하지 않습니다. 이것은 상태로 발을 쏘는 것을 매우 쉽게 만듭니다. goto옛날에 s로 발에 자신을 쏘는 것이 매우 쉬 웠던 것처럼 .

우리는 어떻게 상태와 함께 발을 쏠 수 있습니까?

일반적으로 코드베이스의 모든 함수는 프로그램 상태의 모든 부분을 변경할 수 있습니다. 이것은 어떤 객체 / 메소드가 다른 객체의 내부 상태에 영향을 줄 수있는 기본 제공 제한이 거의 또는 전혀없는 객체 지향 프로그래밍과 같은 프로그래밍 패러다임으로 더욱 악화됩니다.

간단한 예

간단한 예를 살펴 보겠습니다.

11 행은 Before: [3, 5, 4, 1, 2, 9].

15 행은 After:[]. 숫자가 보이지 않습니다.

놀랐나요? 이것은 작동중인 변경 가능한 상태입니다.

다음은 joinNumbers위에서 사용 된 구현입니다 .

numbers.shift4 행 의 메소드는 실제로 numbers전달 된 배열을 변경했습니다. numbers.shift메소드는 배열의 첫 번째 요소를 반환하고 실제로 원래 배열에서 값을 제거하고 마지막에 배열을 비워 둡니다.

이러한 버그는 간단한 프로그램에서 잡기 어렵지 않을 수 있습니다. 그러나 프로그램이 커질수록 상태가 복잡 해짐에 따라 디버깅도 훨씬 더 복잡해집니다.

동시성을 위해 만들어지지 않음

변경 가능한 상태에는 또 다른 주요 단점이 있습니다. 동시성에서는 잘 작동하지 않습니다. 요즘 프로세서는 더 빨라지지 않습니다. 무어의 법칙의 한계에 도달하려고합니다. 프로세서는 주로 더 많은 프로세서 코어를 사용함으로써 더욱 강력 해집니다. 따라서 다중 코어를 잘 활용하도록 프로그램을 설계해야합니다. 동시 프로그래밍에서 가변 상태는 우리의 친구가 아닙니다.

왜 그렇게 나빠요?

여러 코어가 모두 동일한 공유 메모리에 액세스하고 변형 할 때마다 필연적으로 서로의 발가락을 밟아 경쟁 조건이 발생합니다. 일반적으로 이것이 변경 가능한 상태로 해결되는 방법은 잠금, 뮤텍스, 모니터 등과 같은 구조를 사용하는 것입니다. 스레드가 동기화 될 때까지 기다리면 실제로 여러 코어가 관련 될 때 성능이 저하됩니다. 또한 코드 복잡성을 크게 증가시키는 동시에 디버깅을 훨씬 더 어렵게 만듭니다.

가변 상태를 사용한 프로그래밍 은 단일 코어 프로세서 시대에 만들어진 " 명령형 프로그래밍 패러다임 "이라고도합니다 . 과거에는 메모리가 매우 제한되어 있었고 가능한 한 많은 메모리를 재사용하는 방식으로 프로그램을 작성하는 것이 유일한 선택이었습니다 (예 : 공유 변경 가능 상태 사용). 오늘날 우리는 프로그램에 더 많은 RAM을 사용할 수 있으며 모든 것을 공유하는 방식으로 프로그램을 작성하는 것이 더 이상 필요하지 않습니다 (사실 더 이상 합리적이지 않습니다).

징계의 필요성

변이 가능한 상태는 당연히 "상태 관리에 대한 절제되지 않은 접근 방식"이라고 할 수 있습니다.

이것이 Redux와 같은 국가 관리 라이브러리의 인기가 높아지는 이유 중 하나입니다. 그러나 그러한 도구를 적절하게 사용하려면 숙련되고 훈련되어야합니다. Redux가 부적절하게 사용되어 효과적으로 도구를 쓸모 없게 만드는 사례를 보았습니다.

해결책이 있습니다

Unsplash에 Pablo Heimplatz의 사진

요점을 집으로 돌리기 위해 변경 가능한 상태는 상태 관리에 대한 훈련되지 않은 접근 방식입니다. 예, 변경 가능한 상태는 실제로 goto상태입니다. 와 마찬가지로 goto, 프로그램 흐름을 관리하는 데있어 절제되지 않은 접근 방식입니다. 변경 가능한 상태는 수십 년 전에 프로그램을 괴롭혔던 동일한 문제입니다. 이번에는 코드 대신 상태를 다루고 있습니다.

우리 대부분은“어떻게이 주에 도착 했습니까?”라는 복잡한 질문에 답하기 위해 열심히 노력하고 있습니다. "어떻게이 실행 시점에 도달 했습니까?"라는 이전 질문 대신

우리는 불필요한 질문에 답하는 대신 실제 문제를 해결하고 가치를 제공하는 데 시간을 투자해야합니다.

해결책은 무엇입니까?

“대형 개체 지향 프로그램은 가변 개체의 큰 개체 그래프를 작성할 때 복잡성이 증가하는 데 어려움을 겪고 있다고 생각합니다. 메서드를 호출 할 때 어떤 일이 발생하고 부작용이 무엇인지 이해하고 염두에 두려고 노력합니다.”

Rich Hickey , Clojure 제작자

해결책은 가변 상태와 완전히 반대입니다.

불변 상태 에 대해 이야기하고 있습니다.

아주 간단한 아이디어입니다. 함수는 새 값만 반환 할 수 있으며 전달 된 값을 변경할 수 없습니다.

오늘날 불변의 값을 가진 프로그래밍은 점점 더 인기를 얻고 있습니다. 같은 최신 UI 라이브러리조차도 React불변의 값으로 사용하도록되어 있습니다. 불변성 데이터 값에 대한 최고 수준의 지원을 제공하는 언어는 단순히 불변성이 코드에서 전체 버그 범주를 제거하기 때문에 더 높은 순위를 매길 것입니다.

좋아요,하지만 정확히 불변 상태는 무엇입니까? 간단히 말해서, 대부분의 프로그래밍 언어의 문자열처럼 변경되지 않는 데이터입니다. 예를 들어 문자열을 대문자로해도 원래 문자열은 변경되지 않습니다. 대신 항상 새 문자열이 반환됩니다.

변경된 것도없고 공유 된 것도 없습니다. 이제까지.

불변성은이 아이디어를 더욱 발전시키고 아무것도 변경되지 않도록합니다. 원래 배열을 변경하는 대신 항상 새 배열이 반환됩니다. 사용자 이름을 업데이트 하시겠습니까? 새 사용자 개체는 이름이 업데이트 된 상태로 반환되며 원래 개체는 그대로 유지됩니다.

변경 불가능한 상태에서는 아무것도 공유되지 않습니다. 따라서 더 이상 스레드 안전성의 복잡성에 대해 걱정할 필요가 없습니다. 불변성은 코드를 병렬화하기 쉽게 만듭니다.

상태를 변경 (변경)하지 않는 함수를 순수 라고 하며 테스트하고 추론하기가 훨씬 쉽습니다. 순수 함수로 작업 할 때 함수 외부에 대해 걱정할 필요가 없습니다. 작업중인이 기능에 집중하고 다른 모든 것은 잊어 버리십시오. (객체의 전체 그래프를 염두에 두어야하는 OOP와 비교할 때) 개발이 얼마나 쉬워 지는지 상상할 수 있습니다.

이 기사의 뒷부분에서 순수 함수에 대해 더 자세히 다룰 것입니다.

불변 상태의 예

array.sort 원래 배열을 제자리에 정렬하는 대신 새 배열을 반환합니다.

이전 섹션의 예제는 변형을 방지하기 위해 다음과 같은 방법으로 쉽게 다시 작성할 수 있습니다.

그리고 실제로이 접근 방식은 예상되는 결과를 생성합니다.

Before: [3, 5, 4, 1, 2, 9]
After: [1, 2, 3, 4, 5, 9]

사실, 당신은 이미 다른 언어로이 아이디어를 접했습니다. 대부분의 프로그래밍 언어에서 문자열은 변경할 수 없습니다. string.toUpperCase()원래 문자열을 변경하지 않고 항상 새 문자열을 반환합니다. 문자열로 작업하는 것은 기본적으로 문자열을 제자리에 변경하도록 설정했다면 끔찍했을 것입니다.

숫자로 작업하는 것도 불변입니다. 에서와 같이 덧셈 함수 2+2add(a, b). 원래 숫자를 변경하지 않고 전달 된 값의 합계 인 새 숫자를 반환합니다.

불변 상태의 장점

불변 상태는 변경 가능 상태에 비해 많은 장점이 있습니다.

  • 프로그램 을 추론하기더 쉬워집니다 (시간이 지남에 따라 변경되는 객체에 대해 걱정할 필요가 없음)
  • 동시성 : 불변 데이터는 여러 스레드간에 정보를 공유하는 데 적합합니다. 동시 소프트웨어와 불변 상태는 하늘에서 만들어진 일치입니다.
  • 연결 : 변경 불가능한 데이터에 대한 작업은 연결 하기 쉽습니다. 예를 들어 "a" + "b" + "c"(으로 생각할 수 있습니다 "a" + "b") + "c" == "ab" + "c". 이는 +연산자가 변경 불가능하고 부작용없이 항상 새 문자열을 반환하도록 보장 되기 때문에 가능 하며 원래 문자열을 변경하지 않고) .
  • 예측 가능 : 변경 불가능한 데이터는 수정할 수 없습니다. 즉, 상태가 매우 예측 가능하며 항상 동일합니다.
  • 비교 : 두 데이터 구조에 대해 값 비싼 심층 평등 비교를 수행하는 대신, 거의 즉각적인 해시를 간단히 비교할 수 있습니다.
  • 테스트 : 불변 데이터 구조를 사용하는 함수는 일반적으로 부작용이 없기 때문에 테스트하기가 매우 쉽습니다.

불변 상태로 변경 될 때마다 일부 데이터 구조의 새로운 사본을 생성한다는 것을 눈치 채 셨을 것입니다. 100,000 개가 넘는 항목의 배열을 반복해서 복사한다고 상상해보십시오. 속도가 느리 겠죠? 이것은 낭비 아닌가?

네, 그렇습니다.

이것이 함수형 프로그래밍 언어가 영구 데이터 구조 라는 개념을 사용하는 이유 입니다. 이것은 단순히 변경이있을 때마다 전체 데이터 구조의 깊은 복사본을 만들 필요가 없음을 의미합니다.
복사본을 만드는 대신 영구 데이터 구조는 원하는 변경 사항을 추가하면서 이전 데이터 구조에 대한 참조를 단순히 재사용합니다.

영구 데이터 구조

영구 바이너리 트리를 구현하는 방법은 다음과 같습니다.

Wikimedia Commons에서 Vineet Kumar의 일러스트레이션

xs트리 를 변경할 때마다 원래 트리는 수정되지 않습니다. 대신 새 트리 ys가 생성됩니다. 이 트리에는 원래 트리 d'b노드로 연결되는 자체 수정 된 루트 노드 가 있습니다 xs. g', f'그리고 e노드는 새에 다른 ys나무 - 그러나 여전히 재사용 h원본 노드 xs트리를.

안타깝게도 주류 프로그래밍 언어에는 일반적으로 적절한 영구 데이터 구조에 대한 기본 제공 지원이 없습니다. Redux 및 Immutable.js와 같은 라이브러리를 사용하는 솔루션은 허용되지만 적절한 상태 관리 기능 (예 : 변경 불가능한 데이터 구조)을 언어에 내장하는 것이 좋습니다. 훌륭한 (그다지 좋지 않은) 프로그래밍 언어 목록을 보려면 " 이 현대적인 프로그래밍 언어 로 인해 고통을받을 것 "을 읽어보십시오 .

불변 / 영구 데이터 구조를 완전히 지원하는보다 현대적인 언어로 전환하는 것이 불가능하다면 어떻게해야합니까? 그런 다음 항상 선택한 언어에 변경 불가능한 데이터 구조에 대한 지원을 추가하는 라이브러리를 찾고있을 수 있습니다.

기능적 시대가 다가오고 있습니다

Unsplash에 Ameer Basheer의 사진

불변 상태보다 한 단계 더 나아가 코드를 더 좋게 만들고 싶다면 함수형 프로그래밍에 익숙해지는 것이 좋습니다.

저는 함수형 언어가 전임자들의 실수로부터 배웠기 때문에 함수형 프로그래밍이 미래라고 믿습니다. 그리고 저는 혼자가 아닙니다. 함수형 프로그래밍은 전 세계적으로 엄청난 인기를 얻고 있습니다.

함수형 프로그래밍은 컴퓨터 과학의 최고의 아이디어를 결합하여 개발자의 생산성을 높이는 동시에 강력하고 확장 가능한 소프트웨어를 작성할 수 있도록합니다.

함수형 프로그래밍을 그렇게 훌륭하게 만드는 것은 무엇입니까?

첫째, 함수형 프로그래밍은 불변 상태를 많이 사용하고 함수형 프로그래밍 언어는 불변 데이터 구조에 대한 최고 수준의 지원을 제공합니다 (여기서 반복 할 필요 없음).

“저는 이것을 제 10 억 달러 실수라고 부릅니다. 그것은 1965 년에 널 참조의 발명이었습니다. 그 당시 저는 객체 지향 언어에서 참조를위한 최초의 포괄적 인 유형 시스템을 설계하고있었습니다. 내 목표는 모든 참조 사용이 절대적으로 안전해야하며 컴파일러가 자동으로 검사를 수행하도록하는 것이 었습니다. 그러나 단순히 구현이 너무 쉽기 때문에 null 참조를 입력하려는 유혹에 저항 할 수 없었습니다. 이로 인해 수많은 오류, 취약성 및 시스템 충돌이 발생했으며, 이는 아마도 지난 40 년 동안 수십억 달러의 고통과 피해를 입혔을 것입니다. "

— null 참조의 발명가 Tony Hoare

Null은 값의 부재를 처리하는 끔찍한 방법입니다. Null 참조는이를 발명 한 Tony Hoare에 의해 "10 억 달러의 실수"라고 불립니다.

널 참조가 잘못된 이유는 무엇입니까? Null 참조는 유형 시스템을 중단합니다. null이 기본값이면 코드의 유효성을 확인하기 위해 더 이상 컴파일러에 의존 할 수 없습니다. nullable 값은 폭발을 기다리는 폭탄입니다. null이라고 생각하지 않았지만 실제로는 null 인 값을 사용하려고하면 어떻게 될까요? 런타임 예외가 발생합니다.

우리가 다루는 값이 null이 아닌지 확인하기 위해 수동 런타임 검사에 의존해야합니다. 정적으로 형식화 된 언어에서도 null 참조는 형식 시스템의 많은 이점을 제거합니다.

실제로 이러한 런타임 검사 (때때로 null guards 라고 함 )는 잘못된 언어 디자인에 대한 해결 방법입니다. 그들은 우리 코드를 상용구로 흩뿌립니다. 그리고 최악의 경우 null을 확인하는 것을 잊지 않을 것이라는 보장이 없습니다.

함수형 프로그래밍은 Option패턴 사용을 장려하므로 개발자는 존재하지 않을 수있는 값을 명시 적으로 확인해야합니다. 더 나은 기능적 프로그래밍 언어는 컴파일 타임에 값이 없거나 없는지 유형 검사합니다. 일반적으로 Option패턴이 사용됩니다.

오류 처리

예외를 잡는 것은 오류를 처리하는 좋은 방법이 아닙니다. 예외를 던지는 것은 괜찮습니다. 그러나 프로그램이 복구 할 방법이없고 충돌해야하는 경우와 같은 예외적 인 상황에서만 가능합니다. null과 마찬가지로 예외는 유형 시스템을 중단합니다.

예외가 오류 처리의 주요 방법으로 사용되는 경우 함수가 예상 값을 반환할지 아니면 폭발할지 여부를 알 수 없습니다. 예외를 던지는 함수도 작성이 불가능합니다.

분명히 일부 데이터를 가져올 수 없기 때문에 전체 애플리케이션이 충돌하는 것은 좋지 않습니다. 그러나 우리가 인정하는 것보다 더 자주 이런 일이 발생합니다.

한 가지 옵션은 발생한 예외를 수동으로 확인하는 것이지만이 접근 방식은 취약하고 (예외 확인을 잊어 버릴 수 있음) 많은 소음을 추가합니다.

함수형 프로그래밍은 일반적으로 예외 사용을 권장하지 않습니다. 대신 Result패턴이 사용됩니다 (가능한 오류가 컴파일 타임에 유형 검사 될 수 있음).

동시성

내가 이미 말했듯이, 우리는 무어의 법칙의 끝에 도달했습니다. 프로세서는 더 이상 빨라지지 않을 것입니다. 우리는 멀티 코어 CPU 시대에 살고 있습니다. 모든 최신 애플리케이션은 다중 코어를 활용해야합니다.

불행히도 오늘날 사용되는 대부분의 프로그래밍 언어는 단일 코어 컴퓨팅 시대에 설계되었으며 단순히 다중 코어에서 효과적으로 실행할 수있는 기능이 없습니다.

동시성에 도움이되는 라이브러리는 나중에 고려할 사항입니다. 처음에는 동시성을 위해 설계되지 않은 언어에 반창고를 추가하기 만하면됩니다. 이것은 실제로 좋은 개발자 경험으로 간주되지 않습니다. 현대 언어에서는 동시성 지원이 내장되어야하며 대부분의 기능적 언어는 동시성에 적합합니다.

순수 함수로 프로그래밍

명령형 프로그래밍과 달리 함수형 프로그래밍은 순수한 함수로 프로그래밍을 장려합니다.

순수한 함수는 무엇입니까? 아이디어는 매우 간단합니다. 순수한 함수는 동일한 입력이 주어지면 항상 동일한 출력을 반환합니다. 예를 들어 2 + 2는 항상를 반환 4합니다. 즉, 더하기 연산자 +는 순수 함수입니다.

순수 함수는 외부 세계와 상호 작용할 수 없습니다 (API 호출을하거나 콘솔에 쓰기를 통해). 상태를 변경할 수도 없습니다. 이것은 어떤 방법이든지 다른 객체의 상태를 자유롭게 변경할 수있는 OOP의 접근 방식과 정반대입니다.

순수한 함수를 불순한 함수로부터 쉽게 알 수 있습니다. 함수가 인수를 취하지 않거나 값을 반환하지 않습니까? 그렇다면 그것은 불순한 기능입니다.

다음은 몇 가지 불순한 함수의 예입니다.

그리고 몇 가지 순수한 기능 :

이러한 접근 방식은 매우 제한적으로 보일 수 있으며 익숙해지는 데 시간이 걸릴 수 있습니다. 처음에는 확실히 혼란 스러웠습니다!

순수 함수의 이점은 무엇입니까? 테스트하기가 매우 쉽습니다 (모의 및 스텁이 필요 없음). 순수 함수에 대한 추론은 쉽습니다. OOP와 달리 전체 애플리케이션 상태를 염두에 둘 필요가 없습니다. 현재 작업중인 기능에 대해서만 걱정하면됩니다.

순수한 기능을 쉽게 구성 할 수 있습니다. 순수 함수는 상태가 함수간에 공유되지 않으므로 동시성에 적합합니다. 순수한 함수를 리팩토링하는 것은 순수한 즐거움입니다 (의도 된 말장난). 복잡한 IDE 도구를 사용할 필요없이 복사하여 붙여 넣기 만하면됩니다.

함수형 프로그래밍은 순수 함수의 사용을 장려합니다. 코드베이스의 90 % 이상이 순수 함수로 구성 될 때 좋습니다. 일부 언어는 이것을 극도로 받아들이고 순수하지 않은 함수를 모두 허용하지 않습니다 (항상 좋은 생각은 아닙니다).

무엇 향후 계획?

읽어 주셔서 감사합니다. 불변 상태로 프로그래밍의 이점을 전달할 수 있었기를 바랍니다!

Object-Oriented Programming is The Biggest Mistake of Computer Science (It 's only about OOP) 를 읽으면 불변성의 주제를 더 잘 이해할 수 있습니다 .

최신 프로그래밍 언어에 대한 심층적 인 검토와 함수형 프로그래밍 언어에 대한 좋은 소개를 보려면 " 이 현대 프로그래밍 언어 로 인해 고통을받을 것 입니다."를 읽어보십시오 .

Suggested posts

캡슐보다 낫습니까?

캡슐보다 낫습니까?

새로운 논문에서 Geoffrey Hinton이 이끄는 연구팀은 신경망 (Transformers, Neural Fields, Contrastive Representation Learning, Distillation and Capsules)의 5 가지 발전의 강점을 결합하여이를 가능하게하는 비전 시스템 "Glom"의 아이디어를 상상합니다. 고정 아키텍처가있는 신경망을 사용하여 이미지를 각 이미지에 대해 서로 다른 구조를 가진 부분 전체 계층 구조로 구문 분석합니다. 심리적 증거는 인간이 시각 장면을 부분 전체 계층으로 파싱하고 부분과 전체 사이의 관점 불변 공간 관계를 모델링한다는 것을 보여줍니다.

소프트웨어 개발 프로젝트를위한 최고의 개요를 작성하는 5 가지 팁

소프트웨어 개발 프로젝트를위한 최고의 개요를 작성하는 5 가지 팁

작성자 : Jessica Fender 이미지 및 헤더 이미지 출처 : Pixabay 프리랜서, 소프트웨어 개발 기업 직원 또는 회사 소유주이든 관계없이 항상 새로운 비즈니스를 찾고 있습니다. 비즈니스를 찾는 데있어 중요한 부분은 잠재 고객의 요구에 신속하고 적절하게 대응하는 것입니다.