함수형 프로그래밍을위한 정신 모델 또는 실제 메타 데이터

실제 세계에서 무언가를 참조하는 기능적 프로그래밍에 대한 좋은 정신 모델이나 은유를 가진 사람이 있습니까?

객체 지향 프로그래밍은 직관적으로 의미가 있습니다. 속성이있는 것들이 있으며 때로는 속성 (메소드)에 대한 작업을 수행하거나 계산을 수행 할 수도 있습니다. (예 : 자동차, 모양, 고양이).

나는 함수형 프로그래밍을 전혀 악용하지 않으며 두 가지 장점에 대한 토론에 관심이 없다. Object Oriented 프로그래밍에서와 같이 작동하려면 은유 또는 정신 모델이 필요합니다.

기능적 패러다임에서의 프로그래밍을위한 좋은 정신 모델이나 실제 은유는 무엇입니까? 기능 처리 기능으로 구성된 기능에 대해서는 확고한 장소가없는 기능이 있습니다.

함수형 프로그래밍은 결과를 달성하기 위해 작은 함수를 함께 붙이는 것입니다. 괜찮은 정신 모델은 (적어도 나에게는) 조립 라인입니다. 구성되는 각 기능은 조립 프로세스에서 한 단계 더 있습니다. 이 기능을 여기에서 고려하십시오.

smallest  = head . sort

Haskell에서이 함수는 목록에서 가장 작은 요소를 반환합니다. 조립 라인은 먼저 입력을 정렬 한 다음 첫 번째 요소를 반환합니다 (최소 정렬에서 가장 큰 정렬이라고 가정). 가장 작은 짝수 값만 얻으려면 다음과 같이 어셈블리 라인을 변경할 수 있습니다.

smallestEven = head . sort . filter even

컨베이어 벨트에서 한 걸음 더 나아가면됩니다.

간단히 말해서, 함수는 미가공 투입물 (부품)을 가공품 (출력)으로 전환하기 위해 취한 단계를 설명합니다.

기능 프로그래밍에 대한 좋은 정신 모델이 있습니까?

수학. 함수형 프로그래밍은 수학에서 영감을 얻어 모델링되었습니다. 수학 함수에는 상태가없고 부작용이 없으므로 FP에서도 마찬가지입니다. OO 스타일의 "어떻게해야합니까"접근 방식을 사용하지 않고 수학 함수 측면에서 FP에 대해 생각하면 좋은 모양이 될 것입니다. 그러나 OO 감도를 FP로 가져 오려고하면 현재와 반대로 수영하게됩니다.

방법에 대한 플립 책 ?

플립 북에서 각 페이지는 한 순간에 존재하는 세계를 나타냅니다. 이 프로그램에서 세계는 복합 데이터 구조로 표현됩니다 (예 : 정글에있는 나무에있는 고릴라의 손에있는 바나나가 있습니다). 각 후속 페이지는 이전 표현을 약간 수정하여 스토리를 진행시킵니다. FP에서 영구 데이터 구조는 이전 구조를 효율적으로 재사용하도록 설계되었으므로 변경은 완전히 새로운 변환이 아닌 델타 만 제공합니다.

분명하지 않은 것은 플립 북의 페이지도 무형 자산을 나타낼 것이라는 점입니다. 예를 들어, 고릴라가 바나나를 떨어 뜨리면 정글 바닥을 향한 중력과 가속도에 중력의 영향을 적용 할 수 있습니다. 이를 수용하기 위해 바나나에 속도와 궤적과 같은 속성을 첨부합니다.

우리의 프로그램에는 플립 북 페이지 (일명 세계 상태)를 인수로 받아들이고 새로운 페이지를 생성하는 함수가있을 것 입니다. 이런 식으로 우리의 이야기는 기존 물체의 상태를 실제로 바꾸지 않고 이야기됩니다. 효과적으로 계산하는 것을 사용하여 각 페이지를 최신 페이지로 대체합니다.

관계.

친구 : 두 사람이 주어지면 친구 관계는이 일반 법칙을 따릅니다.

1. 서로를 향해 선의를 가지고
2. 서로의 친구라고 생각합니다 (따라서이 관계에서 두 회원 모두 법을 준수해야합니다)
3. 서로 시간을 보내는 것을 즐긴다

Monoid : 여러 항목과 2 개의 항목을 가져 와서 1을 반환하는 함수가 주어지면, monoidal 관계는 이러한 일반 법칙을 따릅니다.

1. 다른 항목과 함께 함수에 전달 된 항목 중 하나 (ID 라고만 함)가 있습니다. 함수는 항상 다른 항목 (0 + 1 = 1)을 반환합니다 . 따라서 항목이 숫자 일 때 0은 ID입니다. 기능은 추가입니다)
2. 이 함수는 일관된 관계가없는 세트에서 아이템을 조작하거나 리턴 할 수 없습니다
3. 이 함수는 연관성이 있으며 다소 독립적 인 방식으로 항목과 함께 사용할 수 있습니다. 이는 * (b * c) = (a * b) * c를 의미하므로 a에 b * c 또는 c의 결과를 곱할 수 있습니다 a * b의 결과에 따라 결과는 먼저 수행하는 것과 동일합니다.

함수형 프로그래밍은 일반화에 관한 것입니다. 친구는 수많은 시나리오에서 볼 수있는 매우 일반적인 관계이지만 모든 다양한 형식에서 일반적으로 위의 법률을 따릅니다.

사물 간의 관계를 관리하는 법률을 인식하면 해당 유형의 관계가있는 사물 형식에서 작동하는 일반적인 구현을 만들 수 있습니다. 함수형 프로그래밍에서는 일반적으로 분류하고 처리 할 수 ​​있도록 사물 간의 관계를 식별하려고합니다.

당신은 현실 세계에서 은유를 원하십니까? 사물이 어떻게 관련되어 있는지 살펴보고 일반적인 법을 찾아보십시오 (법 이외의 사안이 다를 수있는 여러 시나리오에 적용 가능). 등록 점원과 상점의 구매자 사이에는 관계가 있으며, 일부 일반 법률이 있으며 POS 시스템 방식으로 일반적인 관계에있는 사람들의 목표를 용이하게하기 위해 소프트웨어가 개발되었습니다. 이와 유사하게 사물이 어떻게 관련되어 있는지를 규정하는 이러한 일반 법률을 볼 때 관계 인스턴스의 특정 사항이 아니라 소프트웨어를 작성할 때 해당 관계의 법률에 의존하기 시작할 수 있습니다.

모든 것이 가치이며, 부작용에 영향을 미치지 않으면 서 값에 함수를 적용하여 함수를 적용하여 새로운 값을 생성 할 수 있습니다.

함수형 프로그래밍에 대해 알아야 할 핵심은 모든 것이 가치라는 것입니다. 심지어 코드 자체도 '가치'입니다.

간단한 기능적 프로그래밍 환경의 가장 좋은 예는 모든 사람이 선호하는 비즈니스 도구 인 스프레드 시트입니다. 스프레드 시트의 모든 셀은 데이터이거나 함수의 결과입니다. 또한이 함수는 다른 셀을 제거하거나 수정할 수 없습니다.

때 대신의 기능 언어로 하나 개의 이동, 직교 격자 의A1 하고 B42, 기능은 이름이 있습니다. 그게 다야.

이것을 넘어서 추가 할 수있는 다른 측면이 있습니다. 그러나 그것은 핵심에서 기능적인 프로그래밍입니다. 리스트의 구조 나 사물 그룹에 대해 걱정할 필요가 없습니다. 함수형 프로그래밍은 값을 함수에 전달하고 메모리의 다른 곳에서 문제를 일으키지 않고 값을 되 찾는 것에 관한 것입니다.

그게 다야. 함수형 프로그래밍은 그리드가 아닌 이름을 가진 스프레드 시트입니다.

함수형 프로그래밍은 동작 에 대한 것으로 생각할 수 있습니다 . 프로그램은 컴퓨터가 실행하려는 동작에 대한 설명입니다. 함수는 기본 동작의 단위이며, 함수 구성은 작은 것에서 더 큰 행동을 만드는 한 가지 방법입니다.

OOP에서 코드 객체하고자 할 문제 영역에서 물체의 상태; 해당 도메인 개체의 변경 사항을 반영하기 위해 시간이 지남에 따라 변경됩니다. FP에서 값 은 도메인 개체의 상태를 나타냅니다 . 변경되지 않으며 단순히 다른 상태를 나타내는 다른 값을 만듭니다.

컴퓨터가 실제로 무엇을하고 있는지에 대해 기능 모델이 좀 더 정직하다는 것을 알았습니다. 결국, 나는 단지 new Tesla()얇은 공기 에서 벗어날 수 없습니다 . :)

문장은 다음과 같이 다소 비슷하다고 가정하면 객체 지향적보다 기능적입니다.

The brown cow is in the meadow across the deep river.

따라서 우리는 머리 문구를 찾은 다음 나머지를 찾아야합니다.

The cow (brown)
the meadow (across)
the river (deep)

한 번에 :

sentence: The cow ((the meadow (the river (deep)) (across)) brown)

구문 분석 트리 :

|                     sentence
|                      /         
|                  The cow
|                 /       \
|            the meadow   brown
|            /         \
|      the river      across
|              \
|              deep

Parsimony는 기능적 사고를 감염시킵니다.

Gottlieb Frege 1890 년대, Alan Turing (entschiedungsprobleme) 1930 년대, Noam Chomsky (1960 년대)의 모자.