"추론하기 쉬운"-그게 무슨 뜻입니까? [닫은]

다른 개발자가이 문구를 사용하여 일부 패턴을 "광고"하거나 모범 사례를 개발하는 경우가 많이 들었습니다. 이 문구는 대부분 함수형 프로그래밍의 이점에 대해 이야기 할 때 사용됩니다.

"추론하기 쉬운"이라는 문구는 설명이나 코드 샘플없이 그대로 사용되었습니다. 그래서 그것은 다음 "버즈 (buzz)"단어와 같이되고, 더 "경험있는"개발자들이 대화에 사용합니다.

질문 : "추론하기 쉽지 않음"의 몇 가지 예를 제공하여 "추론하기 쉬운"예와 비교할 수 있습니까?

제 생각에는 "추론하기 쉬운"이라는 말은 "머리 속에서 실행하기 쉬운"코드를 말합니다.

코드 조각을 볼 때, 이름이 짧고 값이 적은 최소값으로 코드가 짧고 명확하게 작성된 경우 코드가 수행하는 작업을 정신적으로 수행하는 것이 (상대적으로) 쉬운 작업입니다.

이름이 나쁘고 값이 지속적으로 변하는 변수와 복잡한 분기가있는 긴 코드는 일반적으로 현재 상태를 추적하는 데 도움이되는 펜과 종이가 필요합니다. 따라서 이러한 코드는 머리 속에서 쉽게 처리 할 수 ​​없으므로 그러한 코드를 쉽게 추론 할 수 없습니다.

수행 할 작업을 예측하기 위해 몇 가지 사항을 고려해야하는 경우 메커니즘이나 코드를 쉽게 추론 할 수 있으며 고려해야 할 사항을 쉽게 사용할 수 있습니다.

출력이 매개 변수에있는 입력에 의해 완전히 결정되므로 부작용이없고 상태가없는 진정한 기능을 쉽게 추론 할 수 있습니다.

반대로 상태가있는 객체는 메서드를 호출 할 때 객체의 상태를 고려해야하기 때문에 상태를 가진 객체를 추론하기가 훨씬 어렵습니다. 즉, 객체가 다른 상태로 이어지는 원인을 고려해야합니다. 특정 상태.

전역 변수가 더 나쁩니다. 전역 변수를 읽는 코드에 대해 추론하려면 코드에서 해당 변수를 설정할 수있는 위치와 이유를 이해해야합니다. 그리고 모든 위치를 찾기가 쉽지 않을 수도 있습니다.

가장 어려운 이유는 공유 상태를 갖는 다중 스레드 프로그래밍입니다. 상태가있을뿐만 아니라 동시에 여러 스레드가 변경되므로 하나의 스레드에서 실행될 때 코드 조각이 무엇인지에 대한 이유 모든 단일 실행 지점에서 다른 스레드 (또는 그 중 일부)가 코드의 다른 부분에서 실행될 수 있으며 눈 아래에서 작동중인 데이터를 변경할 수 있어야합니다. 이론적으로, 그것은 뮤텍스 / 모니터 / 크리티컬 섹션 / 당신이 부르는 무엇이든 관리 할 수 ​​있지만 실제로 공유 상태 및 / 또는 병렬 처리를 매우 작게 제한하지 않으면 실제로는 실제로 그렇게 할 수있는 사람은 없습니다. 코드 섹션.

함수형 프로그래밍의 경우“추론하기 쉽다”는 의미는 대부분 결정적이라는 것입니다. 즉, 주어진 입력이 항상 동일한 출력으로 이어질 것을 의미했습니다. 해당 코드를 건드리지 않으면 프로그램에서 원하는 모든 것을 할 수 있습니다.

반면, OO는 생성 된 "출력"이 모든 관련 개체의 내부 상태에 의존하기 때문에 추론하기가 더 어렵습니다. 일반적으로 나타나는 예기치 않은 부작용 은 코드의 한 부분을 변경하면 관련이없는 부분이있는 것입니다.

... 함수 프로그래밍의 단점은 실제로 실제로 원하는 것은 IO와 관리 상태라는 것입니다.

그러나 추론하기가 더 어려운 다른 것들이 많이 있으며 @Kilian에 동의하면 동시성이 가장 좋은 예입니다. 분산 시스템도.

더 넓은 토론을 피하고 구체적인 질문을 해결하십시오.

"추론하기 쉽지 않음"의 몇 가지 예를 제공하여 "추론하기 쉬운"예와 비교할 수 있습니까?

나는 1983 년에 시작된 프로그래머 민속의 한 조각 인 "진짜 프로그래머 Mel의 이야기" 를 우리의 직업으로 간주합니다.

자체 참조 및 자체 수정 코드와 의도적으로 기계 버그의 악용을 포함하여 가능하면 비전 기술을 선호하는 프로그래머 작성 코드에 대해 이야기합니다.

명백한 무한 루프는 캐리-오버 플로우 오류를 활용하는 방식으로 코딩되었습니다. "주소 x에서로드"로 디코딩 된 명령어에 1을 추가하면 일반적으로 "주소 x에서로드"가 생성됩니다. 그러나 x가 이미 가능한 가장 높은 주소 인 경우 주소가 0으로 줄 바꿈되었을뿐만 아니라 opcode를 읽을 비트로 1이 전달되어 opload를 "load from"에서 "jump to"로 변경했습니다. 전체 명령이 "마지막 주소에서로드"에서 "점프에서 주소 0으로"로 변경되었습니다.

이것은 '추론하기 어려운'코드의 예입니다.

물론, 멜은 동의하지 않을 것입니다 ...

나는 예를 제시 할 수 있으며 매우 일반적인 예를 제시 할 수 있습니다.

다음 C # 코드를 고려하십시오.

// items is List<Item>
var names = new List<string>();
for (var i = 0; i < items.Count; i++)
{
    var item = items[i];
    var mangled = MyMangleFunction(item.Name);
    if (mangled.StartsWith("foo"))
    {
        names.Add(mangled);
    }
}

이제이 대안을 고려하십시오.

// items is List<Item>
var names = items
    .Select(item => MyMangleFunction(item.Name))
    .Where(s => s.StartsWith("foo"))
    .ToList();

두 번째 예에서는이 코드가 한 눈에 정확히 무엇을하고 있는지 알고 있습니다. 내가 볼 때 Select항목 목록이 다른 목록으로 변환되고 있음을 알고 있습니다. 이 표시되면 Where특정 항목이 필터링되고 있음을 알고 있습니다. 한눈에, 나는 그것이 무엇인지 이해 names하고 효과적으로 활용할 수 있습니다.

for루프를 볼 때 실제로 코드를 읽을 때까지 무슨 일이 일어나고 있는지 전혀 모릅니다. 때로는 모든 부작용을 설명하기 위해 추적해야합니다. 이름이 무엇인지 (유형 정의를 넘어서) 이해하고 효과적으로 사용하는 방법을 이해하려면 약간의 노력을 기울여야합니다. 따라서 첫 번째 예는 두 번째 예보다 추론하기가 어렵습니다.

궁극적으로 여기에서 추론하기 쉬운 것은 또한 LINQ 방법 Select과의 이해에 달려 Where있습니다. 당신이 그것들을 모른다면, 두 번째 코드는 처음에 추론하기가 더 어렵습니다. 그러나 한 번만 이해하면 비용을 지불합니다. for루프를 변경할 때마다 루프를 사용할 때마다 루프 를 이해하는 비용을 지불합니다 . 때로는 비용을 지불 할 가치가 있지만 일반적으로 "추론하기 쉬운"것이 훨씬 더 중요합니다.

관련 문구는 (I paraphrase)입니다.

그것은 코드가 "없다 할 충분하지 않습니다 명백한 버그를 "대신, "이 없어야 분명히 어떤 버그를 ".

비교적 "추론하기 쉬운"예는 RAII 일 수 있습니다 .

또 다른 예는 치명적인 포용을 피할 수 있습니다. 잠금을 잡고 다른 잠금을 획득 할 수 있고 많은 잠금이있는 경우 치명적인 포용이 발생할 수있는 시나리오가 있는지 확신하기 어렵습니다. "하나의 (전역) 잠금 만 있습니다"또는 "첫 번째 잠금을 유지하는 동안 두 번째 잠금을 획득 할 수 없습니다"와 같은 규칙을 추가하면 시스템을 비교적 쉽게 추론 할 수 있습니다.

프로그래밍의 핵심은 사례 분석입니다. Alan Perlis는 Epigram # 32에서 이것을 언급했다 : 프로그래머는 그들의 독창성과 논리에 의해서가 아니라 사례 분석의 완전성에 의해 측정되어야한다.

사례 분석이 쉬운 지 상황을 쉽게 추론 할 수 있습니다. 이것은 고려해야 할 경우가 거의 없거나 특별한 경우 가 거의 없다는 것을 의미합니다. 경우가 많을 수도 있지만 일부 규칙 성으로 인해 붕괴되거나 유도와 같은 추론 기술에 굴복 할 수도 있습니다.

예를 들어, 알고리즘의 재귀 버전은 일반적으로 명령 버전보다 추론하기 쉽습니다. 재귀 버전에 나타나지 않는 상태 변수를 지원하는 돌연변이를 통해 발생하는 불필요한 경우에는 기여하지 않기 때문입니다. 더욱이, 재귀의 구조는 수학적 증명-유도 패턴에 맞도록되어있다. 우리는 루프 변형과 가장 약한 엄격한 전제 조건과 같은 복잡성을 고려할 필요가 없습니다.

이것의 또 다른 측면은 케이스 공간의 구조입니다. 하위 사례 및 하위 사례가 포함 된 사례 등의 계층 적 사례 상황과 비교하여 사례로 편평하거나 대부분 평평한 부문이있는 상황에 대해 추론하기가 더 쉽습니다.

추론을 단순화하는 시스템의 특성은 직교성입니다 . 이는 하위 시스템을 결합 할 때 하위 시스템을 관리하는 사례가 독립적으로 유지되는 속성입니다. 어떠한 조합도 "특별한 경우"를 일으키지 않습니다. 4 개의 케이스가 3 개의 케이스와 직교로 결합 된 경우 12 개의 경우가 있지만 이상적으로는각 사례는 독립적 인 두 사례의 조합입니다. 어떤 의미에서는 실제로 12 가지 사례가 없습니다. 조합은 우리가 걱정할 필요가없는 "긴급한 사건과 같은 현상"입니다. 이것이 의미하는 바는 다른 서브 시스템에서 다른 세 가지를 고려하지 않고 생각할 수있는 네 가지 사례가 여전히 존재한다는 것입니다. 조합 중 일부를 특별히 식별하고 추가 논리를 부여해야하는 경우 추론이 더 어렵습니다. 최악의 경우, 모든 조합에는 특별한 처리가 있으며, 원래 4와 3 외에 12 개의 새로운 경우가 있습니다.

확실한. 동시성 사용 :

뮤텍스에 의해 시행되는 중요 섹션 : 하나의 원칙 (두 개의 실행 스레드가 동시에 중요 섹션에 들어갈 수 없음) 만 있기 때문에 이해하기 쉽지만 비효율과 교착 상태가 발생하기 쉽습니다.

대체 모델, 예를 들어, 잠금이없는 프로그래밍이나 배우 : 잠재적으로 훨씬 더 우아하고 강력하지만 이해하기 hellishly 열심히, 더 이상 같은 "지금 그 장소에이 값을 쓰기"로 (겉으로는) 기본 개념에 의존하지 수 있기 때문이다.

추론하기 쉬운 방법의 한 측면입니다. 그러나 사용할 방법을 선택하려면 모든 측면을 조합하여 고려해야 합니다 .

과제를 공식적인 추론으로 제한하자. 유머 론적이거나 독창적이거나 시적인 추론은 다른 법칙을 가지고 있기 때문입니다.

그럼에도 불구하고 표현은 희미하게 정의되어 있으며 엄격한 방식으로 설정할 수 없습니다. 그러나 그것이 우리를 위해 너무 어둡게 유지해야한다는 것을 의미하지는 않습니다. 구조가 몇 가지 테스트를 통과하고 다른 지점에 대한 표시를 얻는다고 상상해 봅시다. 모든 점에 대한 좋은 표시는 구조가 모든 측면에서 편리하므로 "추론하기 쉽다"는 것을 의미합니다.

"추론하기 쉬운"구조는 다음과 같은 장점을 가져야합니다.

• 내부 용어는 합리적이고 쉽게 구별되고 정의 된 이름을 갖습니다. 요소에 계층 구조가 있으면 부모 이름과 자식 이름의 차이가 형제 이름의 차이와 달라야합니다.
• 구조 요소 유형의 수가 적습니다.
• 사용 된 유형의 구조 요소는 우리에게 익숙한 것입니다.
• 이해하기 어려운 요소 (재귀, 메타 단계, 4+ 차원 지오메트리 등)는 서로 직접 연결되지 않고 격리됩니다. (예를 들어, 1,2,3,4..n. 차원 큐브에 대해 일부 재귀 규칙 변경을 생각하면 매우 복잡 할 것입니다. 그러나 이러한 각 규칙을 일부 공식으로 변환하면 n에 따라 모든 n- 큐브에 대한 공식과 개별적으로 그러한 공식에 대한 재귀 규칙이 있으며 두 구조를 개별적으로 쉽게 생각할 수 있습니다)
• 구조적 요소의 유형은 분명히 다릅니다 (예 : 0에서 1로 시작하는 혼합 배열을 사용하지 않음)

시험은 주관적인가? 예, 당연합니다. 그러나 표현 자체도 주관적이다. 한 사람에게 쉬운 것은 다른 사람에게는 쉽지 않습니다. 따라서 테스트는 도메인마다 달라야합니다.

추론 가능한 기능적 언어에 대한 아이디어는 그들의 역사, 특히 ML 은 계산 기능에 대한 논리가 추론에 사용 된 구문과 유사한 프로그래밍 언어로 개발 된 것에서 비롯됩니다 . 대부분의 기능적 언어는 명령형 언어보다 공식 프로그래밍 계산법에 더 가깝기 때문에 코드에서 추론 시스템의 입력으로의 변환은 덜 복잡합니다.

추론 시스템의 예를 들어, pi-calculus에서 명령형 언어의 각 가변 메모리 위치는 별도의 병렬 프로세스로 표시되어야하지만 기능 연산 시퀀스는 단일 프로세스입니다. LFC 정리 증명 자로부터 40 년 동안, 우리는 GB의 RAM을 사용하여 수백 개의 프로세스를 갖는 것이 문제가되지 않습니다. 필자는 수백 개의 행을 가진 표현에도 불구하고 수백 줄의 C ++에서 잠재적 교착 상태를 제거하기 위해 pi-calculus를 사용했습니다. 추론자가 약 3GB의 상태 공간을 소진하고 간헐적 인 버그를 치료했습니다. 이것은 70 년대 초에 불가능 했었거나 1990 년대 초에 수퍼 컴퓨터를 필요로했지만 비슷한 크기의 기능적 언어 프로그램의 상태 공간은 그 당시에 추론하기에 충분히 작았습니다.

다른 답변에서,이 문구는 명령형 언어에 대한 추론을 어렵게 만드는 많은 어려움이 무어의 법칙에 의해 침식 되더라도 버즈 프레이즈가되고 있습니다.

추론하기 쉬운 것은 문화적으로 특정한 용어이므로 구체적인 예를 제시하기가 매우 어렵습니다. 그것은 추론을 할 사람들에게 정해져있는 용어입니다.

"추론하기 쉬운"은 실제로 매우 자기 표현적인 문구입니다. 코드를보고 있고 그 일을 추론하고 싶다면 쉽게 =)

알겠습니다. 코드를보고 있다면 보통 코드가 무언가를하기를 원합니다. 당신이 생각하는대로 작동하는지 확인하고 싶습니다. 따라서 코드가 수행해야하는 작업에 대한 이론을 개발 한 다음 코드가 실제로 작동하는 이유를 논쟁하려고합니다. 컴퓨터가 아니라 사람처럼 코드를 생각하고 코드가 할 수있는 일에 대한 논쟁을 합리화하려고합니다.

"추론하기 쉬운"의 최악의 경우는 코드가하는 일을 이해하는 유일한 방법이 모든 입력에 대해 튜링 기계처럼 코드를 한 줄씩 통과하는 것입니다. 이 경우 코드에 대해 추론 할 수 있는 유일한 방법 은 자신을 컴퓨터로 만들어 머리에서 실행하는 것입니다. 이 최악의 사례는 RSA를 해독하는 다음 3 줄의 PERL과 같이 난독 화 된 프로그래밍 콘테스트에서 쉽게 볼 수 있습니다.

#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

다시 한 번 추론하기 쉬운 용어는 매우 문화적입니다. 고려해야 할 사항 :

• 추론 자에게는 어떤 기술이 있습니까? 얼마나 많은 경험?
• 추론자가 코드에 대해 어떤 종류의 질문을 할 수 있습니까?
• 추론자가 얼마나 확실해야합니까?

이들 각각은 "추론하기 쉬운"에 다르게 영향을 미칩니다. 추론의 기술을 예로 들어 보자. 회사에서 시작할 때 MATLAB에서 "추론하기 쉬운"스크립트를 개발하는 것이 좋습니다. 왜? 글쎄, 회사의 모든 사람들은 MATLAB을 알고있었습니다. 다른 언어를 선택하면 누구나 나를 이해하기가 더 어려울 것입니다. 신경 끄시는 MATLAB의 가독성는 것을 형편 이 그들을 위해 설계되지 않았기 때문에 단순히 일부 작업. 나중에 내 경력이 발전함에 따라 Python은 점점 더 대중화되었습니다. 갑자기 MATLAB 코드는 "추론하기 어렵다"가되었고 파이썬은 추론하기 쉬운 코드 작성에 선호되는 언어였습니다.

독자가 가질 수있는 idom도 고려하십시오. 특정 구문에서 FFT를 인식하기 위해 판독기에 의존 할 수 있다면 해당 구문을 고수하면 코드를 "추론하기가 더 쉽습니다". 이 도구를 사용하면 텍스트 파일을 FFT를 칠한 캔버스로 볼 수 있습니다. C ++를 사용하는 경우 독자가 std라이브러리에 얼마나 익숙한 지 알아보십시오 . 기능 프로그래밍을 얼마나 좋아합니까? 컨테이너 라이브러리에서 나오는 관용구 중 일부는 선호하는 관용적 스타일에 따라 매우 다릅니다.

또한 독자가 어떤 종류의 질문에 대답하고 싶은지 이해하는 것이 중요합니다. 독자들은 대부분 코드에 대한 피상적 인 이해에 관심이 있습니까, 아니면 장에서 벌레를 찾고 있습니까?

독자가 얼마나 확실해야하는지는 실제로 흥미로운 것입니다. 많은 경우에 헷갈리는 추론은 실제로 제품을 문 밖으로 가져 오기에 충분합니다. FAA 비행 소프트웨어와 같은 다른 경우에는 독자가 철저한 추론을 원할 것입니다. 특정 작업에 RAII를 사용한다고 주장한 사례가 발생했습니다. "단지 설정하고 잊어 버릴 수 있습니다. 올바른 일을 할 것입니다." 나는 내가 틀렸다는 말을 들었다. 이 코드에서 추론하려고하는 사람들은 "세부 사항을 잊고 싶어하는"사람들이 아니 었습니다. 그들에게 RAII는 매달린 차드와 같았으며, 당신이 범위를 벗어날 때 일어날 수있는 모든 일에 대해 생각하도록 강요했습니다.