▲

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

 (lukeplant.me.uk)
1P by GN⁺ 1시간전 | ★ favorite | 댓글 1개
  • 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 장벽이 낮아, 아직 견해가 없거나 이해하지 못한 것에 대해 말하도록 강제하지 않는 특성을 가질 수 있음
  • 프로그래밍 언어가 강제하는 주제는 사용 언어에 대한 인식과 선택에 영향을 줄 수 있음

함께 보면 좋은 글 β

▲
GN⁺ 1시간전  [-]
Lobste.rs 의견들

  • 언어 설계는 프로그래밍 언어든 자연어든, 어떤 요소를 언어에 넣느냐로 사용자가 어디에 주의를 둬야 하는지를 정하는 일로 볼 수 있음
    C는 암묵적으로 “메모리 관리를 신경 써라”라고 하고, Haskell은 “변수와 표현식이 담을 수 있는 타입을 신경 써라”라고 함
    언어가 내가 실제로 주의를 두고 싶은 방향으로 이끌면 그 일에 잘 맞는 도구처럼 느껴지고, 그렇지 않으면 칵테일파티에서 조용히 말하는 사람을 들으려는데 방 건너편에서 누가 소리치는 느낌이 됨
    주의력은 가장 귀한 자원이라서, 도구가 그것을 어떻게 유도하고 형성하는지 의식할 필요가 있음

    • “언어가 말할 수 없는 것을 제한한다”는 발상에는 표현의 비중립성 같은 이름을 붙일 수 있을 듯함
      영어에서 “the”를 명시하거나 생략하는 표현은 대상의 특정성에 대해 중립적이지 않고, 터키어에서 miş를 쓰느냐 마느냐는 정보가 직접 얻은 것인지 전해 들은 것인지에 대해 중립적이지 않음
      이는 “언어가 말할 수 있는 것을 제한한다”는 표준적인 Sapir-Whorf 가설, 즉 표현의 중립성의 반대편으로도 볼 수 있음
      그러면 특정 주제에 대해 언어가 중립적인지 아닌지를 설명하고, 언어 설계자로서 사용자의 주의를 희석하거나 집중시키도록 조정할 수 있음. 예를 들어 가비지 컬렉션은 힙 할당에 대해 표현을 중립적으로 만들고, 효과 추적은 부작용과 입출력에 대해 표현을 비중립적으로 만듦

  • 글의 핵심을 완전히 잡았는지는 모르겠지만, Rust에 대해 오래 반복해 온 생각이 떠오름
    Rust는 참조를 다룰 수 있게 해주지만, 메모리 안전성을 보장하려고 엄격한 규칙을 둔 묘한 위치에 있음
    C++라면 무언가 참조여야 한다고 생각하면 그냥 참조로 만들고 문제가 없기를 바라고, Python이라면 그런 제어권이 없으니 데이터를 거리낌 없이 복사함
    그런데 Rust에서는 “복사는 비효율적이니 참조로 만들자”는 최적화 구덩이에 빠질 수 있고, 빌림 검사기가 소리치면 이 참조가 안전하다고 확신하면서도 한 시간 동안 코드를 리팩터링하게 됨
    좋은 Rust 프로그래머들은 “그냥 .clone, RC, Box 등을 써라”라고 하고 동의하지만, 참조가 눈앞에 있고 안전하게 쓸 수 있을 것 같다는 사실은 그대로임
    그래서 빌림 검사기를 달래려고 더 나쁘게 만들기로 했다는 이상한 느낌이 남고, “빌림 검사기는 나한테 너무 과하다”고 포기하는 사람들이 왜 나오는지도 이해됨

    • 이건 글에서 다루려던 내용과 꽤 맞닿아 있음. Rust는 다른 언어가 요구하지 않는 선택들을 생각하고 결정하게 만들고, 그만큼 언어를 쓰는 부담도 힘도 함께 커짐

  • 주제가 좋고, 터키어 문법 이야기가 조금 나오는 것도 반가움
    또 흔한 예로, 어떤 언어에서는 복수성 같은 세부 정보를 생략할 수 있는데 베트남어가 그런 경우임
    “exaggerated”라는 단어에 링크가 붙어 있는 걸 보고 “혹시 Arrival 관련 글인가?” 했는데 실제로 그랬던 것도 즐거웠음
    많은 사람이 좋아하는 영화지만, 개인적으로는 믿음을 유예하기 어려웠음. 과학소설이라면서 그 “과학”이 일종의 마법 같은 언어학처럼 느껴졌기 때문임

    • 복수성은 APL, Pandas, SQL 같은 것으로 덮어 보려는 바로 그 지점이라고 봄
      대부분의 애플리케이션 프로그래밍 언어는 단일 값을 일종의 원자적 기반으로 삼음. 그 위에 리스트나 맵을 만들 수 있지만, 이것들도 결국 하나의 단일한 사물이고 미묘하게 서로 호환되지 않는 경우가 많음
      Rust에서는 이런 구조 사이를 복사하는 일이 잦고, SQL에서는 그 문제를 덜 신경 쓰는 대신 인덱스와 질의 계획을 신경 써야 함. 특히 데이터베이스가 내가 묻고 싶은 걸 복잡하게 만드는, 명백히 어리석은 계획을 세울 때 그렇고, SQL NULL은 건드리지도 말자
      결과적으로 우리 소프트웨어 대부분은 개별 값 수준까지 믿기 어려울 정도로 과도하게 지정되어 있고, PC 성능은 1000배 좋아졌는데도 최선의 UI 지연 시간은 예전의 10배가 됨
      객체 지향 프로그래밍 교조주의도 부분적으로 책임이 있음. 비동기도 한 번 시도했지만, 독립적인 작업들을 하나씩 await하는 식으로 나무만 보고 숲을 잃는 상태로 너무 쉽게 퇴화함
      https://www.uiua.org/ 는 행복할 것이라고 상상해야 함

  • 좋은 지점들임. 모든 현대 언어는 프로그래머가 잡초밭 속으로 들어가듯 세부 사항을 다루도록 강제하거나 아주 강하게 유도함
    스크립트 언어는 프로그램이나 웹 페이지처럼 조금 덜 세부적인 대상에 대한 연산을 제공하지만, 그래도 세부 사항을 없애지는 못함
    여전히 숫자, 문자열, 오류 코드 같은 아주 작은 세부를 생각하고 관리하게 만듦
    우리는 수년간의 훈련과 실무로 세부 사항 관리에 너무 익숙해져서, 세부의 관점으로 생각하지 않는 일이 매우 어려워짐

  • 가장 먼저 떠오른 건 객체나 모듈의 인터페이스였음
    프로그래밍 언어에서는 이게 아주 구체적인데, 자연어 대화에서는 훨씬 흐릿함
    또 다른 예는 C++의 제네릭과 Python의 제네릭 차이임. C++에서는 매우 의도적으로 다뤄야 하지만, Python에서는 타입 힌트를 무시하면 꽤 암묵적으로 처리됨

  • “역 Sapir-Whorf는 언어가 말할 수 없는 것을 제한하거나, 어떤 것을 말하지 않기 어렵게 만들거나, 심지어 어떤 것을 생각하지 않기 어렵게 만든다”는 부분은 문법 > 관용구 > 표준 라이브러리 > 서드파티 라이브러리 > 생태계라는 피라미드처럼 보임
    “생각하지 않기 어렵다”는 부분은 표현하기 어렵거나 중요한 제약이 있는 문제에 초점을 맞추는 듯함
    익숙함은 위와 아래에서 안쪽으로 작동하고, 사람들은 각 층에서 코드를 쓰는 방식으로 자신의 배경을 드러냄

  • 영어를 15년 넘게 읽고 쓰고 말했는데도 “I live in London”과 “I'm living in London”이 다르다는 걸 몰랐음
    내가 London에 사는 건지, 지금 London에 살고 있는 건지도 모르겠음 😅

    • “I'm living in London”은 “I am living in London”으로 풀어 보면 조금 도움이 됨
      여기서 동명사형을 일반 형용사로 바꿔 “I am cold”라고 해보면, 지금 춥다는 뜻이지 어떤 슈퍼빌런처럼 영구히 차갑다는 뜻은 아니라고 받아들일 것임
      마찬가지로 “I am living in London”은 현재 London에 살고 있지만 미래에는 바뀔 수 있음을 암시함
      또한 항상 London에 산 것은 아니라는 뉘앙스도 있음. “I am cold”가 적어도 한 번은 충분히 따뜻한 온도를 겪어 봐서 지금 상태를 “정상”이 아니라 “춥다”고 알아차린다는 뜻을 어느 정도 품는 것과 비슷함
답변달기