정적 타입과 삽

1 hour ago 1

(carefully.understood.systems)

2000년대부터 2010년대 초까지 정적 타입의 인기가 줄었다가 2010년대 중후반 다시 늘어난 이유는 정적 타입 시스템의 품질 향상으로 설명됨
동적 타입 시스템은 변수와 필드의 상태·내용을 사람이 직접 판단해야 하며, 컴퓨터가 돕지도 방해하지도 않는 맨손으로 땅 파기에 비유됨
초기 Java나 C++98 같은 과거의 정적 타입 시스템은 nullable과 non-nullable 포인터 구분도 돕지 못하고, 타입 이름을 반복 작성하게 만드는 종이 삽에 비유됨
TypeScript, Haskell, MyPy, Swift, Rust 같은 현대 타입 시스템은 null 처리, 합 타입·유니언 타입, 타입 추론을 통해 프로그램 오류 확인과 상태 표현을 더 잘 지원함
IDE의 메서드 이름 자동완성 같은 기능이 널리 퍼지면서, 정적 타입 시스템에 넣은 정보가 오류 검사 외에도 생산성 이점으로 이어짐

핵심 주장

90년대와 2000년대 초에 널리 쓰인 초기 Java나 C++98의 정적 타입 시스템은 nullable 포인터와 non-nullable 포인터를 구분하는 단순한 작업도 제대로 돕지 못함
과거의 정적 타입 시스템은 합 타입이 없고 곱 타입만 있는 구조로 설명됨
과거의 정적 타입 시스템은 타입 이름을 곳곳에 수동으로 작성하게 만들었음
BufferedReader bufferedReader = new BufferedReader(new FileReader(filename)); 같은 코드는 작은 재난으로 표현됨

TypeScript, Haskell, MyPy, Swift, Rust 같은 현대 타입 시스템은 nullable 타입과 non-nullable 타입을 구분하는 방법을 제공함
Haskell은 Maybe t, TypeScript는 T | null, Swift는 T?, Rust는 Optional<T>를 예로 들며, 타입 시스템이 null 검사가 필요한 위치와 누락 여부를 알려줄 수 있음
실제로 런타임에서 null pointer 오류를 거의 보지 않게 된다고 설명됨
현대 타입 시스템은 합 타입이나 유니언 타입 중 하나 이상을 제공하며, "Make invalid states unrepresentable" 실천을 가능하게 함
이 방식은 상태 머신을 나타내는 객체에서 각 필드가 관련 상태일 때만 존재하도록 표현할 수 있게 함
현대 타입 시스템은 타입 추론을 제공하며, 컴파일러가 let x = 5;를 숫자로 판단할 수 있으면 let x: number = 5;를 작성할 필요가 없음

메서드 이름 자동완성 같은 IDE 기능이 널리 퍼지면서 정적 타입 시스템의 유용성이 더 커짐
90년대에는 Intellisense가 Visual Studio의 핵심 기능이었지만, 2020년대에는 비슷한 기능이 거의 모든 IDE와 에디터에서 제공됨
정적 타입 시스템에 넣은 정보는 프로그램 오류 검사뿐 아니라 추가적인 생산성 이점을 만들어냄
좋은 동적 타입 시스템은 나쁜 정적 타입 시스템보다 낫지만, 지금은 과거보다 훨씬 더 나은 정적 타입 시스템을 사용할 수 있음