이 발표에서 야론 민스키는 제인 스트릿이라는 회사에서 왜 오캐믈이라는 변방의 언어로 모든 시스템을 구축하고 개발하게 되었는가를 설명한다. 먼저 그는 일반적인 프로그래밍 언어를 4개의 범주로 나누어 설명한다. 아래와 같이 좌측 열 위쪽에 있는 언어들은 파이썬, PHP 같은 언어들인데 이들은 일반적으로 스크립트 언어라고 불리우는 것들로, 짜기 쉽고 간편하지만 컴파일되는 언어가 아니라 컴파일 되는 언어보다 속도가 매우 느리다는 단점이 있다.(언어의 종류에 따라서는 100배까지도!) 그에 반면 좌측 열 아래쪽에 있는 언어들은 C#, 자바같은 일반적인 언어들인데, 이들은 컴파일되어 빠르고 좋은 성능을 가지는 언어인 것을 보여준다.
여기서, 좌측열과 우측열의 명령형 언어와 함수형 언어를 구분하는 차이점은 함수형 언어는 함수의 형태를 언어단에서 처리할 수 있고, 순수한 프로그래밍(Pure Style of Programming)이 가능하다는 점이다. 여기서 첫 번째로 언급한 함수의 형태를 언어단에서 처리 가능하다는 점은, 함수가 언어에서 데이터로 다루어져 인자로 전달되거나 값으로 반환되어 사용될 수 있다는 것이고, 두 번째로 순수한 프로그래밍이 가능하다는 점은 프로그램을 짜는 데 있어서 사이드 이펙트(Side Effect)가 없다는 점이다. 사이드 이펙트란 프로그램에 주어진 입출력 외의 다른 Mutable한 행동이 가능하다는 것인데, 그는 이것이 없는 것을 함수형 언어의 큰 장점으로 꼽고 있다.
왜 사이드 이펙트가 없는 것이 좋은가?
이 발표에서 그는 Pure Programming의 장점에 대해서 이야기한다. 프로그램이 Pure하다는 것은 프로그램의 변수가 중간에 변하지 않고 그대로 전달된다는 의미인데, 이는 값 중심 프로그래밍의 핵심 아이디어이다. Pure한 언어, Mutation이 없는 언어가 왜 중요한가(Why it matters?)에 대해서는 타당한 이유가 있다. 가장 핵심은 프로그램 내 Mutable이 있다면, 그 프로그램을 이해하기 어려워진다는 것이다. 그는 여기에서 Mutable한 프로그램의 존재를 통신 채널이 있는 프로그램들이 서로 정보를 주고 받고 하는 것과 비슷하다고 표현하며, 이러한 행동이 위험하다고 이야기 한다. 프로그램내 값들이 이야기하지 않는(doesn't talk) 것이 이해하기 쉽고, 더 좋은 프로그램이라는 것이다.
요약하자면, Immutability Simplifies Things
그럼 본격적으로, OCaml을 쓰는 이유? 아니 써야만 하는 이유는?
[파이썬/오캐믈 두 개의 맵(딕셔너리) 차이 비교 예제]
위에서 두 예제의 차이가 보이는가? 두 프로그램은 모두 두 개의 맵(딕셔너리)을 받아 일치하지 않는 키들을 모아 반환하는 기능을 구현한 코드이다. 위 프로그램은 파이썬, 아래는 오캐믈로 작성된 코드이다. 만약 당신이 눈치가 빠르다면 위 프로그램 중 첫 번째 프로그램은 버그가 내재해 있다는 것을 알아차렸을 것이다. 위 mismatch.py의 find_mismatches() 함수에서 두 번째 인자인 딕셔너리 d2가 비어있는 상태로 전달되었을 때, 4번째 라인의 d2[key]를 접근하는 과정에서 에러가 발생할 것이다. 파이썬 딕셔너리에서는 key 값이 존재하지 않을 때, exception을 발생시키기 때문이다.(lua에서는 null을 반환한다고 한다.)
반면에 오캐믈은 어떨까. mismatch.ml의 코드가 약간 복잡해보이지만, 설명하자면 다음과 같다. Map은 오캐믈에서 key와 value 쌍들의 리스트를 가지는 딕셔너리와 유사한 자료구조이고, Map.to_sequence는 Map 자료구조의 데이터를 sequencial하게 늘어놓는 함수이다. 그리고 Sequence.filter_map은 주어진 sequence에 대해 iteration을 도는 함수이다. 여기서 나오는 match ~ with 문은 map2의 키값에 매핑되는 데이터를 보고 특정 행동을 하도록 구현된 코드이다. 만약 여기에서 파이썬 예제에서와 같은 map2의 키가 비어있는 상황을 고려하지 않을 경우, 즉 None 케이스를 지워버릴 경우 어떻게 될까?
8: this pattern-matching is not exhaustive. Here is an example of a case that is not matched: None
펑! 컴파일러는 이렇게 에러를 발생시키고, 컴파일 자체를 제한시킨다. 위 에러 메세지는 map2의 key 값에 대응되는 데이터의 타입에 대해서 패턴 매칭 구문이 완전히 짜여지지 않았다고 컴파일러가 경고하는 것이다.(정확히 말하자면 컴파일러 내부의 타입 체커가 경고한다.) 이렇듯, 오캐믈은 언어 자체의 feature로 타입에 대해서 case analysis를 하나하나 정교하게 하기 때문에 프로그램의 correctness를 보장할 수 있다. 위 파이썬 예제에서와 같은 에러는 오캐믈 프로그램에서 발생하지 않는다.
1. 표현력이 좋고(Expressive), 가벼운(lightweight) 타입(시스템)
이렇듯 오캐믈은 강력한 타입 시스템과 타입 체커를 가지고 있다. 제인 스트릿과 같이 트레이딩 한번 한번이 정말 중요한 회사는 조금의 오차나 실수도 용납하지 않는 프로그램을 만드는 걸 원할 것이다. 그리고 오캐믈의 타입시스템은 이러한 상황에서 정말 좋은 툴이 된다. 이것은 마치 컴파일러가 case analysis를 통해서 타입 정적분석을 하는 것과 같다. 오캐믈의 타입 시스템이 타입으로 발생할 수 있는 모든 버그를 예방해주기 때문에 오캐믈로 짠 프로그램은 타입 에러로 부터 안전할 수 있고(type safe), 이로 인해 수반되는 피해를 예방할 수 있다.
오캐믈의 타입시스템은 마치 잔소리하는 nanny처럼 귀찮고 깐깐하게 프로그램을 들여다보며 타입 버그를 예방하고, correctness를 잡아주어, 프로그램을 less error-prone하게 만들어준다.
[자바/오캐믈 타입 정의 구현체 예시]
타입의 정의 또한 표현력이 좋아지고, 간단해진다. 좌측이 자바의 타입 정의의 구현체 예제, 우측이 오캐믈. 자바는 훨씬 더 verbose하다.(이것은 자바에서 naturally express되는 기능이 아니라 이렇게 장황하고 길게 표현된다.)
2. Dynamic Range
훌륭한 개발자라면 사뭇 상황에 맞는 적절한 프로그래밍 언어를 사용할 줄 알아야한다. 오캐믈은 또한 광범위한 용도로 프로그램을 만드는 데에도 사용할 수 있다. 야론 민스키는 다음과 같은 이유로 오캐믈이 여러가지 목적성을 가진 프로그램을 짜는 데 적합하다고 주장한다.
OCaml is ...
- Concise
- Has type system
- Easy to work with
3. Teaching & Hiring
오캐믈은 가르치기 쉽고, 사람을 뽑는 데 있어서 좋은 기준이 되는 프로그래밍 언어가 된다. 그는 방학동안 인턴으로 제인 스트릿에 들어와 오캐믈을 처음 배우고 익혀서 작은 프로젝트를 할 수 있었던 하버드와 MIT 학생들의 예시를 든다. 그들은 대부분 3,4주의 짧은 인턴 기간이었지만 그 동안 오캐믈을 새롭게 익히고 작은 규모의 프로젝트를 문제없이 소화할 수 있었다고 한다.
If a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.
Paul Graham, The Python Pradox
그는 또한 2004년 Python Paradox라는 강연의 폴 그레이엄의 말을 인용한다. 해당 강연에서는 소수가 사용하는 언어인 파이썬 개발자들이 다른 언어를 사용하는 개발자들보다 똑똑하다는 점을 예시를 들어 이야기하며(물론 야론 민스키는 그 당시에는 파이썬 개발자 수가 적었지만 지금은 발에 치이게 많아졌다고 이야기한다.) 소수가 사용하는 언어를 쓰는 개발자들이 더 훌륭하다는 이야기를 한다. 야론 민스키는 오캐믈이 이러한 입지에서 바라볼 수 있다는 점을 이야기하였다.
4. Tools & Libraries
unpopular한 언어인 오캐믈의 최대 취약점은 사용자가 적은 만큼 커뮤니티도 작다는 점인데, 그럼에도 불구하고 아래와 같은 훌륭한 툴과 라이브러리를 보유하고 있다.
- opam
- merlin
- ocp-indent
- codoc
- extension points
- module aliases
이 포스팅은 Jane Street의 개발자 Yaron Minsky의 오캐믈에 대한 강연 내용을 번역/정리한 것 입니다. 오역 및 잘못 된 내용이 있다면 댓글로 남겨주세요.
