타입 검사, 그 다음 이야기

문제는 타입 검사를 _없애는 것_이 아니라, 타입 검사를 비켜놓고 필요할 때만 쓰는 것이다.

계층화된 타입 검사.

"알 필요가 있는 것만".

전송 계층은 바이트를 옮긴다. 그 이상에 대해 타입 검사를 적용하면 안 된다. 바이트 패킷 내부에 무엇이 있는지 알 필요가 없어야 한다.

각 계층은 자신의 일을 하는 데 필요한 만큼만 타입을 검사하고, 그 이상의 세부를 추론하려 들지 말아야 한다.

이건 지금 우리의 프로그래밍 언어들이 하는 일과 대부분 반대다. 언어들은 맨 아래까지 전부 타입을 검사한다. 그리고 타입 검사를 별도의 도구로 대하지 않고 언어 곳곳에 뿌려대서, 디테일이 너무 많아져 오히려 이해를 어렵게 만든다.

우리는, 이를테면, 관심 있는 사람을 위해 옆에 프로로그(Prolog) 규칙을 써서 엔티티가 무엇인지 설명해 두고, 실제 타입 검사는 프로로그 엔진이 하게 둘 수 있다(본질적으로 타입 체커가 하는 일이기도 하다).

나는 소프트웨어 LEGO®를 원한다.

소프트웨어 LEGO®를 가질 수 없는 이유는 우리의 API가 디테일로 너무 어지럽기 때문이다.

내 경험으로, 프로그램이 5줄밖에 안 될 때는 타입 검사가 전혀 필요 없었다. 블랙박스(소프트웨어 LEGO® 블록)를 만들 수 있을 때 그 경험을 다시 얻게 된다. 작은 블랙박스 안에서 벌어지는 일은 너무 적어서 전부 파악할 수 있고, 그럴 땐 그 어떤 화려한 도구도 필요 없다.

요령은 그 작은 감각을 프로그램 전체에 끝까지 유지하는 것이다.

어떻게?

아키텍처를 무한한 함수 캔버스처럼 만들지 말고, 작은 블랙박스들로 이루어진 트리(그래프가 아님)처럼 구성하라.
작은 블랙박스가 다른 작은 블랙박스 안의 함수를 _호출_하지 못하게 하라. 그들은 잘 정의되고 명시적인 ports(포트)를 통해 mevents(이벤트 주도, 비동기 메시지 전달, 제어 흐름 영향 없이 순수 데이터플로)만 보낼 수 있어야 한다.
"발사하고 잊기"(fire and forget), 즉 "발사하고 반환값을 기다리기"가 아니라.
팬아웃을 허용하라. 하나의 작은 블랙박스가 자신의 출력 포트 중 하나로 _mevent_를 내보내면, 그 _mevent_는 여러 수신자에게 복사될 수 있다. (저수준 효율이 걱정된다면 copy-on-write 같은 것을 강제하라.)
어떤 작은 블랙박스도 자신의 출력을 다른 작은 블랙박스로 직접 배포하지 못하게 하라. 이 작업은 부모에게 맡겨라. 부모는 디스패처 또는 _라우터_와 같다.
배선에 타입을 하드코딩하지 마라. 작은 블랙박스가 보낸 출력은 수신자가 기대하는 것과 일치해야 한다. 그렇지 않으면 그것은 "버그"로 간주된다. 깐깐하게 하고 싶다면 동적 타입 검사를 쓰면 된다. 반대로, 블랙박스 내부가 충분히 단순해서 이해가 쉽다면, 프로그래머/아키텍트는 연결이 타당한지 "눈으로" 볼 수 있고, 상기시켜 주는 화려한 툴이 필요 없다.

암시적 타입으로

이것은 작동하는 컴파일러의 최상위 계층이다.