대부분의 "잘 알려진"명령형 / OO 언어가 '아무것도없는'값을 나타낼 수있는 유형에 대한 확인되지 않은 액세스를 허용하는 이유는 무엇입니까?

나는 null(예를 들어) 대신에 ( 비) 편의에 대해 읽었습니다 Maybe. 읽은 후 이 글을 , 나는 그것을 사용하는 것이 훨씬 더 좋을 것이라고 확신하고있다Maybe (또는 무언가 유사). 그러나 모든 "잘 알려진"명령형 또는 객체 지향 프로그래밍 언어가 여전히 사용하고 있으며 null( '아무것도없는'값을 나타낼 수있는 유형에 대한 확인되지 않은 액세스를 허용 함 Maybe) 주로 기능적 프로그래밍 언어에서 사용됩니다.

예를 들어 다음 C # 코드를보십시오.

void doSomething(string username)
{
    // Check that username is not null
    // Do something
}

뭔가 나쁜 냄새가 난다 ... 왜 인수가 널인지 점검해야 하는가? 모든 변수에 객체에 대한 참조가 포함되어 있다고 가정해서는 안됩니까? 보시다시피, 문제는 정의에 의해 거의 모든 변수에 null 참조가 포함될 수 있다는 것입니다. 어떤 변수가 "널링 가능" 인지 아닌지 결정할 수 있다면 어떨까요? "NullReferenceException"을 디버깅하고 찾는 동안 많은 노력을 절약 할 수 있습니다. 기본적으로 어떤 유형도 null 참조를 포함 할 수 없다고 상상해보십시오 . 그 대신 변수가 실제로 필요한 경우에만 변수에 null 참조가 포함될 수 있다고 명시 적으로 언급 합니다. 그것이 아마도이면의 아이디어입니다. 경우에 따라 실패하는 함수가있는 경우 (예 : 0으로 나누기)Maybe<int>, 결과가 int 일 수도 있지만 아무것도 아니라고 명시 적으로 명시합니다! 이것이 null 대신 Maybe를 선호하는 이유 중 하나 입니다. 더 많은 예제에 관심이 있다면 이 기사 를 읽으십시오 .

사실 대부분의 유형을 기본적으로 널 입력 가능하게 만드는 단점에도 불구하고 대부분의 OO 프로그래밍 언어는 실제로이를 수행합니다. 그래서 내가 궁금해하는 이유는 다음과 같습니다.

• null프로그래밍 언어 대신 어떤 종류의 인수 를 구현 해야 Maybe합니까? 전혀 이유 가 있습니까? 아니면 단지 "역사적인 수하물"입니까?

이 질문에 대답하기 전에 null과 Maybe의 차이점을 이해해야합니다.

나는 그것이 주로 역사적인 수하물이라고 생각합니다.

가장 눈에 띄고 가장 오래된 언어 null는 C와 C ++입니다. 그러나 여기서는 null의미가 있습니다. 포인터는 여전히 상당히 숫자적이고 저수준 개념입니다. 그리고 C 및 C ++ 프로그래머의 사고 방식에서 다른 사람이 어떻게 말 했는가에 대해 포인터가 명확 null하지 않다고 명시 적으로 말해야한다는 것은 합리적이지 않습니다.

두 번째 줄은 Java입니다. Java 개발자가 C ++에 가장 가까이 다가가려고했기 때문에 C ++에서 Java로 더 간단하게 전환 할 수 있기 때문에 언어의 핵심 개념을 망치고 싶지는 않았을 것입니다. 또한 null초기화 후에 null이 아닌 참조가 실제로 올바르게 설정되어 있는지 확인해야하기 때문에 명시적인 구현 에는 훨씬 많은 노력이 필요합니다.

다른 모든 언어는 Java와 동일합니다. 일반적으로 C ++ 또는 Java가 수행하는 방식을 복사하며 암시 적 null참조 유형의 핵심 개념이 어떻게되는지를 고려할 때 explicit를 사용하는 언어를 설계하는 것은 실제로 어려워집니다 null.

사실, null좋은 생각입니다. 포인터가 주어지면이 포인터가 유효한 값을 참조하지 않도록 지정하려고합니다. 따라서 우리는 하나의 메모리 위치를 가져와 유효하지 않은 것으로 선언하고 해당 규칙 (종종 segfaults로 시행되는 규칙)을 고수합니다. 이제 포인터가있을 때마다 Nothing( ptr == null) 또는 Some(value)( ptr != null, value = *ptr) 가 포함되어 있는지 확인할 수 있습니다 . 나는 이것이 Maybe유형 과 동일하다는 것을 이해하기를 원합니다 .

이것의 문제점은 다음과 같습니다.

1. 많은 언어에서 유형 시스템은 널이 아닌 참조를 보장하도록 여기에서 지원하지 않습니다.

   많은 주류 명령형 또는 OOP 언어가 이전 시스템과 비교할 때 유형 시스템이 점진적으로 향상 되었기 때문에 이것은 역사적인 수하물입니다. 작은 변화는 새로운 언어를 배우기 쉽다는 장점이 있습니다. C #은 null을보다 잘 처리하기 위해 언어 수준 도구를 도입 한 주류 언어입니다.

2. API 디자이너는 null실패시 반환 할 수 있지만 실제 성공 자체에 대한 참조는 아닙니다. 종종 (참조없이) 사물이 직접 반환됩니다. 하나의 포인터 레벨을 평탄화 null하면 값 으로 사용할 수 없습니다 .

   이것은 디자이너 측의 게으름이며 올바른 유형 시스템으로 적절한 중첩을 적용하지 않으면 도움이 될 수 없습니다. 일부 사람들은 성능을 고려하거나 선택적인 검사 (컬렉션이 반환 null되거나 항목 자체 가있을 수 있지만 contains방법을 제공함) 를 통해이를 정당화하려고 시도 할 수 있습니다 .

3. Haskell에는 Maybe모나드 형식 에 대한 깔끔한 견해가 있습니다 . 이를 통해 포함 된 값에 대한 변환을보다 쉽게 ​​구성 할 수 있습니다.

   반면에 C와 같은 저수준 언어는 배열을 별개의 유형으로 취급하지 않으므로 우리가 기대하는 바가 확실하지 않습니다. 매개 변수화 된 다형성이있는 OOP 언어에서 런타임 확인 Maybe유형은 구현하기가 쉽지 않습니다.

내 이해는 null프로그래밍 언어를 어셈블리에서 추상화하기 위해 필요한 구조라는 것입니다. ^한 프로그래머는 포인터 또는 값을 등록 이었다는 것을 표시 할 수있는 능력이 필요 not a valid value하고 null그 의미에 대한 일반적인 용어가되었다합니다.

null개념을 나타내는 관습에 불과한 요점을 강조 하면서 실제 null사용 가능한 값은 프로그래밍 언어 및 플랫폼에 따라 달라질 수 있습니다.

당신이 새로운 언어를 설계하고 회피하고 싶어한다면 null하지만 사용하는 maybe대신에, 그때와 같은 더 자세한 설명 용어를 격려 것 not a valid value또는 navv의도를 나타냅니다. 그러나 그 비 가치 의 이름 은 비가 치가 귀하의 언어로 존재 하도록 허용 해야하는지 여부와는 별개의 개념입니다 .

이 두 지점 중 하나를 결정하기 전에 maybe시스템 의 의미가 무엇인지 정의해야합니다 . 이름 null의 의미 not a valid value가 바뀌 었거나 언어에 대한 의미가 다른 것을 알 수 있습니다.

마찬가지로 null액세스 또는 참조 에 대해 액세스 를 확인할지 여부에 대한 결정은 언어의 또 다른 디자인 결정입니다.

약간의 역사를 제공하기 위해 C프로그래머가 메모리를 조작 할 때 수행하려는 작업을 이해했다는 암시적인 가정이있었습니다. 어셈블리와 그 이전의 명령 언어에 대한 우수한 추상화 였기 때문에 프로그래머를 잘못된 참조로부터 안전하게 보호한다는 생각이 마음에 들지 않았다고 생각합니다.

일부 컴파일러 또는 추가 툴링은 유효하지 않은 포인터 액세스에 대한 검사 수단을 제공 할 수 있다고 생각합니다. 따라서 다른 사람들은이 잠재적 인 문제를 지적하고이를 방지하기위한 조치를 취했습니다.

언어를 허용할지 말지 여부는 언어로 달성하려는 목표와 언어 사용자에게 어느 정도의 책임을 지길 원하는지에 달려 있습니다. 또한 컴파일러가 해당 유형의 동작을 제한하도록 만들 수있는 능력에 달려 있습니다.

따라서 귀하의 질문에 대답하십시오 :

1. "어떤 종류의 논쟁…"-글쎄, 그것은 당신이 원하는 언어에 달려 있습니다. 베어 메탈 액세스를 시뮬레이트하려면 허용 할 수 있습니다.

2. "역사적인 수하물입니까?" 아마도 아닐 수도 있습니다. null확실히 여러 언어에 의미가 있고 그 언어의 표현을 이끌어내는 데 도움이됩니다. 역사적 선례는 더 최근의 언어와 그들의 허용에 영향을 미쳤지 null만 손을 흔들고 쓸모없는 역사적 수하물이라는 개념을 선언하는 것이 조금 큽니다.

¹ null 값과 객체 지향 언어에 대한 Hoare의 기여가 있지만 이 Wikipedia 기사를 참조하십시오 . 나는 명령형 언어가 Algol과 다른 가계도를 따라 진행되었다고 생각합니다.

인용 한 기사의 예제를 보면 대부분의 Maybe경우 코드가 단축되지 않습니다. 확인해야 할 필요는 없습니다 Nothing. 유일한 차이점은 타입 시스템을 통해 그렇게 할 수 있다는 것입니다.

나는 힘을 강요하지 말고 "기억하라"고 말합니다. 프로그래머는 게으르다. 프로그래머가 값이 될 수 없다고 확신 하면 null 포인터를 역 참조하는 것처럼 값을 확인하지 않고 Nothing역 참조합니다 Maybe. 최종 결과는 널 포인터 예외를 "역 참조 된 빈 어쩌면"예외로 변환하는 것입니다.

프로그래밍 언어가 프로그래머가 무언가를하도록 강요하는 다른 영역에도 동일한 인간 본성 원칙이 적용됩니다. 예를 들어, Java 디자이너는 사람들이 대부분의 예외를 처리하도록 강요하려고했기 때문에 예외를 자동으로 무시하거나 맹목적으로 전파하는 많은 상용구가 생겼습니다.

무엇을 만드는 Maybe결정의 많은 패턴 매칭 및 다형성 대신 명시 적 검사를 통해 만들어진 때 좋은 것은이다. 예를 들어, 별도의 기능을 만들 수 processData(Some<T>)와 processData(Nothing<T>)당신이 함께 할 수 없습니다 null. 오류 처리를 별도의 함수로 자동으로 이동합니다. 이는 항상 하향식으로 호출되지 않고 함수가 전달되고 느리게 평가되는 함수형 프로그래밍에서 매우 바람직합니다. OOP에서 오류 처리 코드를 분리하는 기본 방법은 예외입니다.

Maybe문제를 생각하는 매우 기능적인 방법입니다. 문제가 있으며 정의 된 값을 가질 수도 있고 없을 수도 있습니다. 그러나 객체 지향의 관점에서, 우리는 물건에 대한 그 아이디어 (값이 있든 없든 상관없이)를 객체로 대체합니다. 분명히 객체에는 값이 있습니다. 그렇지 않다면 우리는 객체가라고 말하지만 null실제로 의미하는 것은 객체가 전혀 없다는 것입니다. 객체에 대한 참조는 아무것도 가리 키지 않습니다. 번역 Maybe객체 지향 개념으로하는 것은 아무것도 소설을한다 - 사실, 그것은 단지 더 크게 어지러워 코드를합니다. 여전히 값에 대한 null 참조가 있어야합니다.Maybe<T>. 현재는 "아마도 점검"이라고하더라도 널 점검 (실제로 더 많은 널 점검을 수행하여 코드를 어지럽게해야 함)을 수행해야합니다. 물론, 저자가 주장한대로보다 강력한 코드를 작성 하겠지만, 언어를 훨씬 더 추상적이고 불분명하게 만들었 기 때문에 대부분의 경우 필요하지 않은 수준의 작업이 필요하기 때문에 그럴 경우라고 주장합니다. 스파게티 코드를 처리하는 것보다 새로운 변수에 액세스 할 때마다 어쩌면 확인을 수행하는 것보다 NullReferenceException을 기꺼이 한 번 복용합니다.

의 개념은 null쉽게 C로 거슬러 올라갈 수 있지만 문제가있는 곳은 아닙니다.

내가 선택한 일상 언어는 C #이며 null한 가지 차이점을 유지 합니다. C #에는 값 과 참조 의 두 가지 유형이 있습니다 . 값은 결코 될 null수 없지만 값이 완벽하지 않다는 것을 표현하고 싶을 때가 있습니다. 이를 위해 C #은 Nullable형식을 사용 하므로 int값과 int?nullable 값이됩니다. 이것이 참조 유형도 작동해야한다고 생각합니다.

참조 : null 참조는 실수가 아닙니다 .

널 참조는 도움이되고 때로는 없어서는 안될 (C ++에서 문자열을 리턴하거나 리턴하지 않는 경우 얼마나 많은 문제점이 있는지 고려하십시오). 실수는 실제로 널 포인터가 아니라 유형 시스템이 처리하는 방식에 있습니다. 불행히도 대부분의 언어 (C ++, Java, C #)는 올바르게 처리하지 못합니다.

함수형 프로그래밍은 유형 , 특히 객체 지향 프로그래밍보다 다른 유형 (튜플, 퍼스트 클래스 유형의 함수, 모나드 등)을 결합하는 유형에 관심이 많기 때문이라고 생각합니다 .

내가 생각하는 최신 버전의 프로그래밍 언어 (C ++, C #, Java)는 모두 일반적인 프로그래밍 형식이없는 언어 (C, C # 1.0, Java 1)를 기반으로합니다. 그것 없이는 널 입력 가능 객체와 널 입력 불가 객체 사이의 차이를 언어로 구울 수 있지만 (C ++ 참조와 같이 null제한 될 수 는 없지만 제한적 임) 훨씬 자연스럽지 않습니다.

근본적인 이유는 데이터 손상에 대해 프로그램을 "안전하게"만들기 위해 비교적 적은 수의 null 검사가 필요하기 때문입니다. 프로그램이 유효한 참조로 작성되었지만 그렇지 않은 배열 요소 또는 기타 저장 위치의 내용을 사용하려고하면 예외가 발생하는 것이 가장 좋습니다. 이상적으로는 예외는 문제가 발생한 위치를 정확하게 나타내지 만 중요한 것은 null 참조가 데이터 손상을 일으킬 수있는 곳에 저장되기 전에 어떤 종류의 예외가 발생한다는 것입니다. 어떤 방법으로 객체를 어떤 식 으로든 사용하지 않고 저장하지 않는 한 객체를 사용하려는 시도는 그 자체로 일종의 "널 체크"를 구성합니다.

null 이외의 특정 예외가 발생하지 않아야하는 곳에 나타나는 null 참조를 확인하려는 경우 NullReferenceException, 모든 곳에서 null 검사를 포함 해야하는 경우가 종종 있습니다. 반면에, null 참조가 이미 수행 된 것 이상으로 "손상"을 일으킬 수 있기 전에 일부 예외가 발생하도록 보장하는 것은 종종 비교적 적은 테스트가 필요합니다. 일반적으로 테스트는 개체가 그것을 사용하려고하지 않고 참조, 그리고 중 하나는 null 참조는 유효 하나를 덮어 쓸 것, 또는 그 프로그램의 상태를 잘못 해석 다른 측면에 다른 코드를 일으킬 것이다. 그러한 상황은 존재하지만 그다지 흔한 것은 아닙니다. 대부분의 우발적 인 null 참조는 매우 빠르게 포착됩니다그들의 확인 여부 .

" Maybe기록 된"널보다 높은 레벨의 구조이다. 더 많은 단어를 사용하여 정의하는 것은 아마도 "물건에 대한 포인터 나 아무것도 아닌 포인터"이지만 컴파일러는 아직 어느 것을 결정하기에 충분한 정보를 얻지 못했습니다. " 이렇게하면 작성하는 코드를 따라 잡을만큼 똑똑한 컴파일러 사양을 작성하지 않는 한 각 값을 지속적으로 명시 적으로 확인해야합니다.

null이 쉬운 언어로 Maybe를 구현할 수 있습니다. C ++의 형식은 하나입니다 boost::optional<T>. Maybe와 null을 동등하게하는 것은 매우 어렵다. 특히,가있는 경우 Maybe<Just<T>>null (이러한 개념이 없기 때문에)을 null에 할당 할 수 없지만 T**null이있는 언어의 경우 null에 할당하기가 매우 쉽습니다. 이것은 하나를 사용하도록 강제합니다 Maybe<Maybe<T>>. 이것은 완전히 유효하지만 해당 객체를 사용하기 위해 더 많은 검사를 수행해야합니다.

null은 정의되지 않은 동작이나 예외 처리가 필요하기 때문에 어쩌면 기능 언어 구문에 매핑하기 쉬운 개념이 아니기 때문에 어쩌면 기능을 사용합니다. 그러한 기능적 상황에서 그 역할을 훨씬 더 잘 채울 수 있지만 절차 적 언어에서는 null이 왕입니다. 그것은 옳고 그름의 문제가 아니라 컴퓨터가 원하는 일을하도록 더 쉽게 지시하는 문제입니다.