저자의 초기 프로그래밍 경험과 파이썬에 대한 불호
저자는 프로그래밍 첫사랑으로 루비를 꼽으며, 스몰토크와 리스프에서 영감을 받은 루비의 유연하고 표현적인 디자인에 매료되었습니다. 그러나 진정한 프로그래밍의 이해는 스킴을 통해 재귀와 불변성을 먼저 배우면서 시작되었다고 회고합니다. 이러한 배경에서 파이썬은 여러 면에서 저자의 취향과 맞지 않았습니다.
- 표현식(Expression)이 아닌 구문(Statement):
if문이 표현식이 아닌 구문으로 작동하여 조건부 변수 할당이 번거로웠습니다. - 제한적인 람다(Lambda): 루비나 스키머에게 필수적인 람다가 파이썬에서는 구문을 허용하지 않는 왜곡된 형태로 제공되어 불만이 컸습니다.
- ‘하나의 방식’ 철학: 파이썬의 “일을 하는 한 가지 방법만 있다”는 철학이 저자가 선호하는 방식과 달랐습니다.
타입 시스템의 영향과 언어 선택 기준의 변화
프론트엔드 개발에서 타입스크립트를 접하며 저자의 언어에 대한 관점은 크게 변화했습니다. 타입스크립트의 강력한 타입 시스템은 동적 언어의 단점을 보완하고, 정적 분석을 통해 “나쁜” 언어 기능조차 용인될 수 있음을 깨닫게 했습니다.
- 타입스크립트의 역할: 동적 언어 위에 구축된 타입 시스템의 ‘황금 표준’으로, 복잡한 실제 자바스크립트 코드를 모델링하며 언어의 성공에 기여했습니다. 특히 타입 레벨 프로그래밍 잠재력을 높이 평가했습니다.
- 러스트(Rust) 경험: 러스트를 통해 변이성(mutability)도 괜찮을 수 있음을 배우며, 기능적 프로그래밍 관점에서 벗어나 유연한 사고를 하게 되었습니다.
- 정적 분석의 가치: 타입 내로잉(type narrowing), 제어 흐름 기반의 타입 검사, 변수 초기화 검사 등을 통해 언어의 특정 결함을 상쇄할 수 있다는 점을 인지했습니다.
파이썬의 진화와 저자의 긍정적 변화
과거와 달리 파이썬은 상당한 발전을 이루었으며, 이는 저자의 인식을 바꾸는 결정적인 계기가 되었습니다.
- 타입 힌트(Type Hints): 저자가 가장 좋아하는 기능으로, 타입 검사기 생태계에 정보를 제공하고 Pydantic과 같은 라이브러리가 스키마 검증 및 웹 API 정의를 간소화하는 데 활용될 수 있습니다. 별도의 빌드 단계 없이 언어에 내장되어 도입 비용이 없다는 점을 높이 평가합니다.
- 매치(Match) 구문: 구조 분해(destructuring)를 포함한 매치 구문의 도입은 언어의 표현력을 향상시켰습니다.
print함수의 변화:print가 더 이상 구문이 아닌 일반 함수로 변경되어 유연성이 증대되었습니다.- 기타 선호 기능:
- 키워드 인수(Keyword Arguments): 함수 정의에서 특별한 선언 없이 인수 이름을 키워드로 사용할 수 있는 점을 높이 평가합니다.
- 네임스페이스(Namespaces): 잘 설계된 네임스페이스는 코드 조직화에 유리합니다.
- 컴프리헨션(Comprehensions) 및 제너레이터 함수(Generator Functions): 제한적인 람다의 단점을 보완하며, F#의 시퀀스 표현식과 유사하게 깔끔한 코드 작성을 가능하게 합니다.
- ‘하나의 방식’의 재해석: 여러 사람이 협업하는 프로젝트에서는 “하나의 방식”이 오히려 장점이 될 수 있음을 인정합니다.
루비의 정체와 작별의 시사
반면 루비는 지난 10년간 큰 변화를 겪지 않았습니다. 레일스와 같은 대규모 애플리케이션을 위한 성능 개선이나 몇몇 흥미로운 기능 추가가 있었지만, 타입 힌트와 같은 ‘게임 체인저’급의 변화는 없었습니다.
- 루비의 변화 부족: Matz(마츠모토 유키히로)가 타입 시스템에 큰 관심을 보이지 않는다는 점을 지적하며, 루비가 다른 언어들처럼 진화하지 못했음을 아쉬워합니다.
- 루비에 대한 감정 변화: 여전히 스크립트 작성에 루비를 사용하지만, 과거와 같은 즐거움을 느끼지 못하고 루비의 특이한 점들에 더욱 짜증을 느끼게 되었다고 고백합니다.
- 파이썬에 대한 갈망: 키워드 인수, 타입 힌트, 네임스페이스 등 파이썬의 기능들을 루비에서 그리워하게 되면서, 저자 자신이 루비에게 너무 많이 변했다는 결론에 도달합니다.