분명히 프로그래밍 언어 얘기를 하려던 게 아닌데….

세그먼테이션 위반, 널포인터 예외는 적절한 설계와 코딩스타일 습관 개선으로 99.9% 극복 가능합니다.

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

단위테스트, 기능테스트 빌드에서 발견되는 실수는 대체로 코딩 컨벤션과 무관한 것들인데, 예를 들면 테스트 전용 코드가 살아 있다든가, 덧셈 대신 뺄셈을 했다든가, Infty나 Div/0 체크가 없다든가....

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

이게 프로그램의 오작동을 일으킨다는 면에서는 같으나, 엄연히 다릅니다. 스펙의 불완전함이나 잘못된 구현은 프로그래머의 자유도 상에 있는 것이지만, 널포인터 오류는 언어 자체의 nothing-referentiable 기능과 밀접한 것입니다.

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

즉 널포인터가 존재하는 언어를 세그먼테이션이 된 환경에서 사용한다면, 널체크는 프로그래머의 의무입니다. 자유도 상에 있지 않습니다.

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

새 세대의 프로그래밍 언어는 프로그램의 구조와 역할 구성에 대한 패러다임을 제시함으로써 이전에 존재하던 부류의 프로그램 오류 발생을 원천적으로 방지한다. 이 중 구조 설계에 대한 자유를 최소로 제한하는 언어가 성공하며 이전 세대의 언어는 버려진다.

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

이를테면 이전의 어셈블리어에서 C 계열의 구조적 서브루틴 언어로 넘어오게 만든 종류의 습관적 오류는 서브루틴 인자 타입과 개수를 틀리는 오류였다.

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

그러니까 결론은 널포인터 오류를 습관으로 100% 잡을 분이 아니라면 Rust나 Go를 쓰세요

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015

덧붙이자면 멀티스레딩도 문제가 심각한데, 동시성 쪽은 새로운 언어에서 꽉 잡고 있고, 자동화된 성능분산은 C/C++ 라이브러리나 OpenMP에서 꽉 잡고 있어서... 답이 안보임 자살

— 32비트 부호 없는 어리 (@u32_t) August 2, 2015