슭의 개발 블로그

다른 Iterator (a.k.a 반복자)를 받아 새로운 반복자를 반환하는 함수를 iterator adapter 라고 부른다. adapter라는 이름은 GoF의 디자인 패턴 중 하나인 adapter pattern 에서 온 말이라고 한다. 그런데 실제로는 adapter pattern보다는 decorator pattern 에 해당하기 때문에 이름을 신경쓰면 용도를 헷갈릴 수 있다. 그러니 이름에 대해서는 크게 신경 쓰지 않는 것이 좋다. 이름에 대한 불평은 그만하고 iterator adapter가 무엇을 하는가? iterator adapter는 반복자가 순회하면서 할 일을 더해준다. 무슨 말인지는 실제 구현체를 보면 쉽게 이해할 수 있을 것이다. map 함수는 대표적인 adapter다. 함수형 언어를 써본 사람이라면 많이 익숙할 map 함수가 반환하는 반복자는 기존의 값을 새로운 값으로 변환한 값을 순회한다. 이 외에도 표준 라이브러리에 이미 다양한 adapter가 구현돼있다. 이중 가장 많이 사용되는 것은 반복문과 같이 사용하기 좋은 adapter들이다. 조건을 만족하는 값만 돌려주는 filter , 지정 된 몇 개의 값만 반환하는 take , 반대로 몇 개의 값은 생략하고 반환하는 skip , 몇 개씩 값을 건너뛰며 순환하는 step_by 와 같은 adapter가 대표적인 예시다. 이런 adapter를 반복문과 함께 사용하면 복잡한 조건 처리를 쉽게 표현할 수 있다. 이 외에도 영원히 종료하지 않고 순환하게 만드는 cycle 이나, 순환하는 값에는 변환을 주지 않고, 사이드이펙트를 발생시키기만 하는 inspect 도 많이 사용된다. adapter를 사용할 때 주의해야 할 점이 하나 있다. adapter가 반환하는 것 역시 반복자일 뿐이다. 실제로 반복자를 사용하기 전에는 adapter가 지정한 일을 수행하지 않는다. 쉽게 말해 실제로 값이 필요할 때까지 실행을 미루는 lazy evaluation 을 한다는 것이다. 따라서 아래와 같은...

최적화는 귀찮다. 눈에 띄는 실수를 한 게 아니면 어떻게 고쳐야 할지 감이 오지도 않고, 대부분의 최적화는 가독성을 떨어뜨리기 때문에 버그가 발생할 확률이 늘어난다. 하지만 어떤 최적화 테크닉은 코드를 크게 수정하지 않고 큰 성능 향상을 가져온다. 메모이제이션 이 그 대표적인 예제다. 계산이 무겁거나, 디스크의 값을 읽거나, 네트워크 통신처럼 근본적으로 시간이 오래 걸리는 일은 그 실행 결과를 저장했다 재사용하는 것만으로 큰 성능향상을 가지고 온다. 파이썬은 메모이제이션을 쉽게 적용할 수 있는 데코레이터 를 제공한다. functools 모듈의 lru_cache 데코레이터 가 이것이다. 이 데코레이터를 붙이면 함수의 실행 결과를 캐싱해준다. 캐시의 크기는 maxsize 로 지정할 수 있다. 저장할 실행 값이 이 개수를 넘어가는 경우 LRU 알고리즘 에 따라 가장 오래전에 사용한 결과를 지우고 새 값을 캐싱한다. lru_cache 를 사용하면 쉽게 최적화할 수 있지만 아무 함수에나 사용할 수 있는 건 아니다. 함수의 인자를 캐시키로 사용하기 때문에 함수의 실행 결과가 함수의 인자 이외에 다른 요소에 의존적인 함수에는 사용하지 못한다. 즉, 랜덤 요소가 들어가거나 시간에 따라 결괏값이 변하는 함수에는 사용하면 안 된다. 결정성이 보장되는 함수에만 사용할 수 있다는 것은 모든 캐시의 공통적인 특성이다. 여기에 더해 파이썬이 제공하는 lru_cache 는 그 구현상의 문제로 한 가지 제약이 더 있다. 이 데코레이터는 값을 저장하기 위해 인자를 키로 가지는 dictionary 를 사용한다. 따라서 모든 인자가 hashable 타입이어야 한다. 다시 말해 mutable 하지 않은 dictionary, set, list 등을 인자로 받는 함수는 이 데코레이터를 사용해 캐싱할 수 없다. 이런 타입을 인자로 받던 함수는 그 인자를 frozenset 이나 tuple 같은 immutable 타입으로 변환해야 한다. 게다가 keyword argument 를...

Java나 C++ 같은 언어에서는 조건 반복문 과 for-each 반복문 에 같은 for 키워드를 사용한다. 하지만, Rust 는 조건 반복문에는 while 키워드 을 for-each 반복문에는 for 키워드를 사용한다. Rust는 여기에 하나의 반복문을 더 제공한다. loop 반복문이다. 이는 while true 라고 쓰는 것과 같이 같은 코드를 무한히 실행한다. 실제로 무한 반복이 필요한 경우에도 사용되고, 반복문의 조건을 하나의 표현식으로 서술하기 힘들어 break 문으로 뺄 때에도 사용된다. 하지만 loop 가 while true 와 완전히 같은 코드는 아니다. loop 는 while 문과 다르게 그 자체로 값을 가진다. break 문 뒤에 값을 적으면 이 값이 반복문 전체의 값이 된다. 그렇다면 다른 반복문은 값을 가지지 않는데 loop 문만 값을 가지는 이유는 무엇일까? 일반적으로 반복문이 끝나는 데는 두 가지 조건이 있다. 주어진 조건이 끝나는 것과 break 문을 만나는 것이다. 평범한 반복문에서도 같은 문법을 써서 break 문을 만났을 때의 값은 정하게 할 수는 있지만, 조건이 끝나 반복문이 종료되는 경우 값을 지정할 수 없다. 그래서 일반적으로 반복문은 값을 가지지 않는다. 하지만 loop 문은 종료 조건이 없기 때문에 끝나기 위해서는 항상 break 문을 만나야 한다. 이런 특징 덕분에 loop 는 다른 반복문과 다르게 구문 자체가 값을 가질 수 있다. Rust에서는 for-each 반복문을 for-in 반복문이라고 부른다. 실제로 for value in values 라고 코드를 작성하기 때문이다. 그렇다면 여기서 values 에 들어갈 수 있는 값은 어떤 값일까? 내가 만든 타입을 for-in 반복문에 사용하고 싶으면 어떻게 해야 할까? 값을 순회할 수 있는 타입은 모두 for-in 반복문에 사용할 수 있다. Rust에서는 Iterator 가 순회할 수 있는 타입을 의미한다. 다시 말해 for-in 반복문은 Iter...

프로그램에서 반복문은 크게 두 가지로 나눌 수 있다. 하나는 특정 조건을 만족할 때까지 같은 코드를 반복하는 것이다. 포트란으로부터 시작해서 C를 거쳐 대부분의 프로그래밍 언어들은 기본적으로 이런 형태의 반복문을 제공한다. 예를 들면 C의 while 문이나 for 문이 그렇다. 이것들은 주어진 조건이 성립하는 동안 정해진 코드를 실행한다. 혹은 특정 범위의 모든 값에 대해 같은 코드를 실행하기도 한다. 이런 반복문은 C++에서는 range-based for loop , C#과 Java는 foreach 문 , JavaScript는 for ... of 문으로 부르는 등 다양한 이름으로 불린다. 이런 종류의 반복문을 부르는 이름은 언어마다 다르지만, 편의를 위해 이 글에서는 이것을 for-each 문으로, 임의의 조건을 걸 수 있는 반복문을 조건 반복문으로 부르도록 하겠다. for-each 반복문은 사실 조건 반복문을 특정한 조건에서만 사용할 수 있도록 특수화시킨 것으로 볼 수도 있다. 실제로 C++의 range-based for loop나 Rust의 for loop 는 조건 반복문의 syntactic sugar로 설명하기도 한다. C++이나 Java 등의 언어는 원래 for-each 반복문이 없었다. 그래서 조건 반복문을 이용해야 했기 때문에 off-by-one-error 같은 실수가 종종 발생했다. 이에 대한 해결책이 없었던 것은 아니다. 예를 들어 Lisp 같은 언어는 이미 for each 반복문을 가지고 있었다. 하지만 언어 스펙을 변경하는 것은 큰일이기 때문에 많은 언어들이 새 문법을 추가하지 않고 해결하고자 했다. C++의 이터레이터를 이용하는 algorithm 라이브러리 가 이런 경우다. 하지만 이런 해결책은 함수를 인자로 받는 higher-order function 을 쓰기 때문에 for 문을 쓸때보다 사용하기 불편하거나 코드를 읽기 어려워지는 경우가 있는 것은 사실이었다. 그래서 Java, C++, JavaScript ...

누군가가 나에게 러스트 가 다른 언어와 다른 가장 큰 차이가 뭐냐고 묻는다면, 라이프타임이라고 대답할 것이다. 그래서 러스트를 처음 배우는 사람들이 러스트의 적응하는데 가장 어려운 부분도 이것이라고 생각한다. 특히 함수의 경우 라이프타임을 표기하는 파라미터는 생략이 가능해서 이 생략 규칙에 익숙하지 않은 사람은 함수가 의미하는 것을 이해하지 못하기도 한다. 일단 함수를 정의할 때는 크게 신경 쓰지 않아도 된다. 러스트는 분석 도구가 매우 잘 만들어져 있다. 지금까지 나온 어떤 언어보다 잘 돼 있다고 말하고 싶을 정도다. 어떤 라이프타임을 생략할 수 있는지 확실치 않은 경우는 모든 레퍼런스에 파라미터를 적어주고 clippy 를 사용하면 어떤 파라미터가 필요 없는지 친절하게 알려준다. 이에 따라 코드를 다듬으면 된다. 문제는 다른 사람이 작성한 함수를 읽을 때이다. 라이프타임에 따라 함수의 의미가 달라진다. 때문에 라이프타임을 정확히 파악하지 못하면, 코드를 잘못 이해하는 경우가 생긴다. 생략된 라이프타임 파라미터가 어떤 값이 되는가는 생략된 라이프타임이 함수의 인자에 사용됐는가 결괏값에 사용됐는가에 따라 다르다. 우선 입력에 사용된 라이프타임이 생략된 경우는 간단하다. 전부 다른 파라미터로 생각하면 된다. 다시 말해서, 입력에 사용된 라이프타임은 다른 라이프 타임과 관계없다면 모두 생략할 수 있다. std::cmp::Ord::cmp(&self, other: &Self) -> Ordering 가 2개의 레퍼런스 타입을 받지만, 라이프타임이 명시되지 않은 이유가 이 때문이다. 결괏값에 사용된 라이프타임을 생략하는 것은 이보다 약간 더 복잡하다. 우선 출력에 사용된 라이프타임은 특정한 두 경우만 생략될 수 있다. 첫 번째 경우는 함수의 인자에 단 하나의 라이프타임만 사용된 경우이다. 함수의 인자에 라이프타임 파라미터가 하나만 사용된 경우, 결괏값에 생략된 라이프타임 파라미터는 전부 인자의 라이프타임으로 간주한다. 예를 들어 std...

모든 일에서 데드라인을 지키는 것은 중요하다. 마감을 지키는 것은 일의 기본이다. 특히 팀으로 작업하는 일에서는 더더욱 그렇다. 소프트웨어 개발의 많은 일은 파이프라인 형식으로 진행되기 때문에, 내가 약속한 일정을 못 맞추면, 내 일만 뒤로 밀리는 것이 아니라 협업 중인 다른 사람의 일정에까지 영향을 주는 경우가 많다. 하지만 일정을 맞추는 것은 어렵다. 그게 뭐가 어렵냐고 생각할 수 있는데 정말 어렵다. 언제나 이번만큼은 예외라고 생각하지만, 언제나 일정은 틀어진다. 심지어 예상보다 오래 걸릴 것이라는 경험을 바탕으로 계산보다 일정을 길게 잡아도 여전히 마감을 못 지킨다. 이런 현상을 호프스태터의 법칙 이라고 부른다. 그렇다면 호프스테터의 법칙은 왜 생길까? 일정 예측이 틀리는 이유를 알아보기 전에 우선 짚고 넘어갈 것이 있다. 어떤 프로젝트는 일정을 맞출 수 없다. 애초에 부족한 시간이 주어진 경우가 그렇다. 아쉽게도 많은 프로젝트에서 일정은 기술적 요인만으로 결정되지 않고, 다른 사업적 이유로 결정된다. 이런 경우는 답이 없다. 하지만 이런 것은 "프로젝트가 * 같았다"라고 말하지 예측이 실패했다고는 하지 않는다. 이 글에서 말하는 일정 예상이 틀렸다고 말하는 것은 기술적 요인을 충분히 고려하여 일정을 잡았어도 예상한 경우보다 많이 걸리는 경우를 말한다. 애초에 이루어질 수 없는 스케줄을 주고 일정 예측에 실패했다고 말하는 것은 그냥 양심 없는 짓이다. 일정이 틀린 이유를 물어보면 다양한 답이 나온다. 과거에 작업했던 코드에서 버그가 있어 수정하느라 늦었다고 하는 경우도 있고, 스펙이 완전치 않아 스펙을 보완하느라 늦어졌다고 하기도 한다. 레거시 코드를 다루는 경우 기존 코드를 완전히 이해하지 못한 채로 시작을 해 늦어졌다고 하기도 한다. 어떤 경우는 구현해야 할 기능에 대한 지식이 부족하여 일정을 잘못 예상했다고 대답하는 경우도 있다. 이 모든 것들은 일정 예측이 틀리는 타당한 이유이긴 하지만 근본적인 이유는 아니다. 만...

트위터에서 이상한 글을 봤다. TypeScript 가 선언한 Promise.all 이 iterable 을 받지 않고 인자 개수 제한이 있다는 것이다. 근데 그럴 리가. TypeScript쯤 되는 프로젝트에서 무언가가 스펙과 다른 것으로 보인다면, 코드를 잘못 이해했을 확률이 높다. 코드를 다시 확인해보자. 당연히 iterable 을 인자로 받는 Promise.all 선언 도 있다. 다만, 이 선언이 es2015.promise.d.ts 가 아닌 es2015.iterable.d.ts 에 있을 뿐이다. 타입스크립트 컴파일러 옵션 중 --lib 으로 사용할 라이브러리를 지정할 수 있다. 대부분 es2015 , es2018 같은 식으로 버전을 지정하여 포함하는 것이 일반적이라 잘 알려지지 않았지만, es2015.symbol 로 Symbol 에 대한 선언만 포함하거나, es2015.promise 로 Promise 에 대한 선언만 포함하는 것이 가능하다. 각 라이브러리는 서로 간에 의존성이 없도록 작성돼 있으며, 특히 iterable 에 관련된 선언은 전부 es2015.iterable 에서 선언한다. 예를 들어 Map 이나 Set 은 es2015.collection 에 선언돼 있지만, iterable 을 반환하는 entries , values , keys 등의 선언은 전부 es2015.iterable 에 선언돼 있다. 마찬가지로 iterable 을 인자로 받는 Promise.all 함수도 es2015.iterable에 선언돼있다. iterable 을 받는 Promise.all 함수 선언은 es2015.iterable 에 선언돼 있는데, es2015.promise 에 10개가 더 선언돼있다. 이들은 무엇일까? 사실 이 함수들은 배열을 인자로 받는 함수가 아니라 tuple 을 인자로 받는 함수 선언이다. JavaScript 에는 임의 개수의 원소를 가지는 배열은 있지만, 고정된 개수의 원소를 가지는 tuple은 없다. 그래서 tuple이 필요할 때 배열을 사...