역 Sapir-Whorf와 프로그래밍 언어

• Inverse Sapir-Whorf는 언어가 무엇을 생각하기 어렵게 만드는지가 아니라, 무엇을 말하지 않기 어렵게 만들고 어떤 정보를 드러내도록 강제하는지에 초점을 둠
• 영어의 현재 시제, 성별 대명사, 프랑스어의 성별 명사, 터키어의 mış 과거형은 임시성, 성별, 정보 출처나 신뢰도 같은 정보를 말하도록 화자를 밀어붙임
• 프로그래밍 언어에서도 계산 순서, async 여부, 메모리 할당과 해제, 스코프, 타입처럼 개발자가 관심 없을 수 있는 주제를 코드에 포함하도록 강제하는 경우가 많음
• Python이나 Javascript의 async, C의 메모리 관리, Rust의 수명(lifetime), 정적 타입 언어의 타입 표기는 선택을 명시하게 만들며, Haskell은 비엄격 의미론과 엄격성 분석으로 일부 선택을 언어에 맡길 수 있음
• 더 접근하기 쉬운 프로그래밍 언어는 Inverse Sapir-Whorf 장벽이 낮아, 아직 이해하지 못했거나 견해가 없는 주제에 대해 말하도록 덜 강제하는 특성을 가질 수 있음

Inverse Sapir-Whorf가 뜻하는 것

• Sapir-Whorf 가설은 단순화하면 사용하는 언어가 사고에 영향을 준다는 생각임
• 강한 형태의 Sapir-Whorf, 특히 언어가 사고를 통제하거나 특정 생각을 하려면 특정 언어가 필요하다는 언어 결정론은 오늘날 언어학에서 널리 진지하게 받아들여지지 않음
• 어떤 언어에 문법적 시제가 없다고 해서 그 화자가 시간에 대해 더 제한적으로 생각한다는 결론은 나오지 않으며, 시간을 표현하는 다른 방법은 항상 있음
• 구어가 특정 영역의 지각, 기술, 태도에 영향을 줄 수 있다는 근거는 꽤 있지만, 큰 직접 효과를 입증하기는 보통 어려움
• Inverse Sapir-Whorf는 언어가 무엇을 말하거나 생각하기 어렵게 만드는지가 아니라, 무엇을 말하지 않기 어렵게 만드는지에 초점을 둠
• 이 관점에서는 언어가 어떤 정보를 말하도록 밀어붙이거나, 어떤 생각을 피하기 어렵게 만드는지가 핵심임

자연어에서 드러나는 강제성

• 영어 현재 시제의 임시성과 영속성

  • “I’m living in London”과 “I live in London”은 모두 런던에 산다는 뜻이지만, 전자는 그 상태가 임시적이라는 정보를 드러냄
  • 비원어민은 이 차이를 알아차리지 못할 수 있고, 원어민도 무의식적으로만 받아들일 수 있음
  • “임시적”이라는 의미는 실제 거주 기간보다 런던을 얼마나 좋아하는지와 더 관련될 수도 있음
  • 영어에서는 시제를 선택해야 하며, 보통 무의식적으로 선택하기 때문에 언어가 거주 기간이나 감정 같은 정보를 드러내도록 만듦

• 영어·터키어·프랑스어의 성별 대명사와 명사

  • 영어의 일상적 발화에서는 특정인을 가리킬 때 보통 “he”나 “she”를 써야 함
  • “singular they”는 존재하지만, 성별을 알고 있거나 추정하는 특정인을 말할 때는 매우 자연스럽지 않음
  • 터키어는 he/she/it에 해당하는 “o” 하나를 사용하며, 이런 성별 대명사의 부재가 사람의 성별에 대해 생각하거나 말하는 것을 막지는 않음
  • 이 지점에서 일반적인 Sapir-Whorf를 뒷받침하기는 어렵지만, 영어 대명사는 원하든 원하지 않든 성별을 말하도록 밀어붙인다는 점에서 Inverse Sapir-Whorf가 뚜렷함
  • 아는 사람을 익명으로 말하려 할 때도 “him”이나 “her”를 무심코 쓰면 성별이 드러나 식별이 쉬워질 수 있음
  • 프랑스어에서는 명사가 성별을 가지며, “my friend”를 번역할 때 “mon ami”와 “mon amie”, 또는 “mon copain”과 “ma copine” 중 하나를 골라야 해 정보를 드러내게 됨
  • 소유 대명사도 영어와 프랑스어 모두 성별화되어 있지만, 영어의 his/her는 소유자의 성별을, 프랑스어의 son/sa는 소유 대상의 성별을 가리켜 서로 다른 정보를 드러냄

• 터키어 “mış” 과거형

  • 터키어에는 단순화하면 영어의 단순 과거와 비슷한 일반 과거형, 그리고 “mış” 형태라는 두 가지 주요 과거 시제가 있음
  • “mış” 형태는 여러 기능을 가지며, 과거 사건을 말할 때는 정보가 전해 들은 것이거나 신뢰성이 낮을 때 사용됨
  • “Fred가 월요일에 출근했는가?”라는 질문에 직접 봤다면 일반 과거형 “geldi”를 쓰고, 들은 정보라면 “gelmiş”를 씀
  • 영어에서는 단순 과거형만으로 정보의 출처나 신뢰도를 특정하지 않고 말할 수 있지만, 터키어에서는 특정 상황에서 확신 수준이나 직접 목격 여부를 포함하도록 강제됨
  • “mış” 형태가 있기 때문에 일반 과거형은 중립적 선택이 아니며, 두 선택지 중 더 적합하지 않을 때는 부자연스러워짐
  • 터키어에서 “mış” 접미사가 문장 마지막 단어 끝에 올 때가 많아, 영어 문장을 끝낸 뒤 “이건 전해 들은 정보이고 직접 본 것이 아니다”라는 표지를 넣지 않았다는 사실을 알아차리고 끝에 “mış”를 덧붙이는 습관도 생길 수 있음
  • 영어에서도 “apparently” 같은 단어로 같은 내용을 쉽게 표현할 수 있지만, 영어는 이를 명시하도록 강제하지 않고, 터키어는 상당히 강제함

• 원어민이 잘 못 보는 언어의 강제성

  • 이런 차이는 다른 언어를 배우거나 자기 언어를 외국인에게 가르치려 할 때까지 잘 알아차리기 어려움
  • 단순 현재와 현재 진행을 고르는 대부분의 순간에는 그 선택이 무엇을 암시하는지 의식적으로 생각하지 않음
  • 언어가 어떤 표현을 강제할 때 항상 무언가를 포함하는 형태로만 나타나지는 않고, 생략을 통해서도 의미가 고정될 수 있음
  • “I love cake”는 일반적인 케이크를 말하고, “I love the cake”는 특정 케이크를 말함
  • 첫 문장에서 “the”가 없기 때문에 전체 케이크를 가리킨다는 점이 명확해지며, 특정 케이크라면 “the”나 “this” 같은 표지를 반드시 써야 함
  • 다른 언어에는 이 구분에 직접 대응하는 표현이 없을 수 있음

프로그래밍 언어에서의 Inverse Sapir-Whorf

• 프로그래밍 언어에서는 일반적인 Sapir-Whorf도 더 성립에 가까울 수 있음
• Python이나 Haskell 같은 언어에서는 메모리 할당에 대해 말하기가 어렵지만 불가능하지는 않음
• 프로그래밍 언어의 한계는 보통 그 언어에서 표현하기 어려운 것들로 이야기됨
• Hillel Wayne의 Sapir-Whorf does not apply to Programming Languages는 이 주제를 더 자세히 다룸
• Inverse Sapir-Whorf 관점에서는 프로그래밍 언어가 실제로 관심 없는 주제까지 말하도록 강제하는지가 핵심임
• 이런 강제성은 여러 언어를 배울 때 생기는 외국어 학습자 같은 관점이 있어야 보이기 쉬움

프로그래밍 언어의 주요 예시

• 계산 순서

  • 대부분의 언어는 계산이 수행될 순서를 표현하도록 강제함
  • Python의 x = some_func(y + 1, z + 2)는 y + 1을 먼저 계산하고, z + 2를 계산한 뒤, 두 값을 some_func의 인자로 넘기는 순서를 말함
  • 이 순서를 의식하지 않을 수 있지만, Python에서는 위 계산을 표현하면서 순서를 함께 지정하지 않는 방법이 없음
  • 대부분의 언어가 비슷하지만, 일부 언어에서는 평가 순서가 매우 복잡해짐
  • Haskell의 some_func (y + 1) (z + 2) 같은 동등한 표현은 비엄격 의미론 때문에 평가 순서를 전혀 지정하지 않음
  • 이 특성은 아직 정의하지 않은 값을 참조하는 Tying the knot 같은 기법을 가능하게 함

• async 함수 색깔

  • async 함수 색깔은 좋은 예시임
  • Javascript나 Python처럼 명시적인 async 키워드가 있는 언어에서는 코드가 동기인지 비동기인지 말해야 함
  • 동기 함수에서는 async 키워드를 생략하는 방식으로 표현하지만, 여전히 두 선택지 중 하나를 고르는 것임
  • 이 주제에 대해 양가적일 수 있는 코드를 작성할 방법은 없음

• 메모리 할당과 해제

  • 가비지 컬렉션)이 없는 대부분의 언어는 메모리 할당과 해제를 말하도록 강제함
  • C 같은 언어에서는 보통 이를 상당히 명시적으로 처리하거나 스택 할당을 암묵적으로 쓰지만, 어느 쪽이든 선택해야 함
  • 다른 언어에서는 이 문제가 더 숨겨질 수 있지만 사라지지는 않음
  • Rust에서는 이 문제가 수명(lifetime)이나 명시적 참조 카운팅에 대한 이야기로 바뀜
  • “이 메모리가 언제 할당되고 해제되는지 신경 쓰지 않으니 알아서 처리해 달라”는 선택지는 실제로 제공되지 않음
  • 메모리 할당을 말하지 않는 데도 비용이 있음
  • 그런 언어는 거의 확실히 많은 값을 힙에 두고 런타임 가비지 컬렉터를 필요로 함
  • 대신 언어가 선택할 자유를 크게 가질 수 있으며, Haskell은 예를 들어 엄격성 분석을 통해 이런 선택을 할 때가 많음

• 스코프

  • 알려진 모든 현대 언어는 스코프에 대해 생각하게 만듦
  • 많은 경우 스코프는 변수를 물리적으로 배치한 위치로 표현되며, 다른 동작을 원하면 Python의 global이나 nonlocal 같은 추가 문법을 써야 함
  • 스코프에 대해 전혀 생각하고 싶지 않다면 어셈블리로 내려가 단일 전역 주소 공간을 감수해야 할 가능성이 큼

• 타입

  • 정적 타입 언어는 보통 모든 변수의 타입에 대해 생각하고 말하도록 강제함
  • 타입 추론은 더 지능적인 청자가 문맥에서 더 많은 것을 알아듣는 것처럼 이 부담을 줄여 주지만, 대화 자체는 여전히 존재함
  • 순수 동적 타입 언어도 Python의 isinstance 검사처럼 타입을 말할 수 있게 해주지만, 더 부자연스럽고 기술적으로도 다른 것임
  • 점진적 타입 언어의 매력 중 하나는 Inverse Sapir-Whorf 문제를 실제로 피하고, 선호에 따라 타입에 대해 말하거나 말하지 않을 자유를 준다는 점임
  • 실제로 얼마나 잘 작동하는지는 확실하지 않으며, 기존 코드베이스의 관례와 사용하는 린터가 항상 어느 방향으로든 압력을 가함

접근하기 쉬운 언어와 낮은 장벽

• 더 “접근하기 쉬운” 또는 “읽기 쉬운” 프로그래밍 언어의 많은 특징은 Inverse Sapir-Whorf 관점에서 분석될 수 있음
• 이런 언어는 Inverse Sapir-Whorf 장벽이 낮아, 아직 견해가 없거나 이해하지 못한 것에 대해 말하도록 강제하지 않는 특성을 가질 수 있음
• 프로그래밍 언어가 강제하는 주제는 사용 언어에 대한 인식과 선택에 영향을 줄 수 있음