언어 설계는 프로그래밍 언어든 자연어든, 어떤 요소를 언어에 넣느냐로 사용자가 어디에 주의를 둬야 하는지를 정하는 일로 볼 수 있음
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”가 적어도 한 번은 충분히 따뜻한 온도를 겪어 봐서 지금 상태를 “정상”이 아니라 “춥다”고 알아차린다는 뜻을 어느 정도 품는 것과 비슷함
Lobste.rs 의견들
언어 설계는 프로그래밍 언어든 자연어든, 어떤 요소를 언어에 넣느냐로 사용자가 어디에 주의를 둬야 하는지를 정하는 일로 볼 수 있음
C는 암묵적으로 “메모리 관리를 신경 써라”라고 하고, Haskell은 “변수와 표현식이 담을 수 있는 타입을 신경 써라”라고 함
언어가 내가 실제로 주의를 두고 싶은 방향으로 이끌면 그 일에 잘 맞는 도구처럼 느껴지고, 그렇지 않으면 칵테일파티에서 조용히 말하는 사람을 들으려는데 방 건너편에서 누가 소리치는 느낌이 됨
주의력은 가장 귀한 자원이라서, 도구가 그것을 어떻게 유도하고 형성하는지 의식할 필요가 있음
영어에서 “the”를 명시하거나 생략하는 표현은 대상의 특정성에 대해 중립적이지 않고, 터키어에서 miş를 쓰느냐 마느냐는 정보가 직접 얻은 것인지 전해 들은 것인지에 대해 중립적이지 않음
이는 “언어가 말할 수 있는 것을 제한한다”는 표준적인 Sapir-Whorf 가설, 즉 표현의 중립성의 반대편으로도 볼 수 있음
그러면 특정 주제에 대해 언어가 중립적인지 아닌지를 설명하고, 언어 설계자로서 사용자의 주의를 희석하거나 집중시키도록 조정할 수 있음. 예를 들어 가비지 컬렉션은 힙 할당에 대해 표현을 중립적으로 만들고, 효과 추적은 부작용과 입출력에 대해 표현을 비중립적으로 만듦
글의 핵심을 완전히 잡았는지는 모르겠지만, Rust에 대해 오래 반복해 온 생각이 떠오름
Rust는 참조를 다룰 수 있게 해주지만, 메모리 안전성을 보장하려고 엄격한 규칙을 둔 묘한 위치에 있음
C++라면 무언가 참조여야 한다고 생각하면 그냥 참조로 만들고 문제가 없기를 바라고, Python이라면 그런 제어권이 없으니 데이터를 거리낌 없이 복사함
그런데 Rust에서는 “복사는 비효율적이니 참조로 만들자”는 최적화 구덩이에 빠질 수 있고, 빌림 검사기가 소리치면 이 참조가 안전하다고 확신하면서도 한 시간 동안 코드를 리팩터링하게 됨
좋은 Rust 프로그래머들은 “그냥 .clone, RC, Box 등을 써라”라고 하고 동의하지만, 참조가 눈앞에 있고 안전하게 쓸 수 있을 것 같다는 사실은 그대로임
그래서 빌림 검사기를 달래려고 더 나쁘게 만들기로 했다는 이상한 느낌이 남고, “빌림 검사기는 나한테 너무 과하다”고 포기하는 사람들이 왜 나오는지도 이해됨
주제가 좋고, 터키어 문법 이야기가 조금 나오는 것도 반가움
또 흔한 예로, 어떤 언어에서는 복수성 같은 세부 정보를 생략할 수 있는데 베트남어가 그런 경우임
“exaggerated”라는 단어에 링크가 붙어 있는 걸 보고 “혹시 Arrival 관련 글인가?” 했는데 실제로 그랬던 것도 즐거웠음
많은 사람이 좋아하는 영화지만, 개인적으로는 믿음을 유예하기 어려웠음. 과학소설이라면서 그 “과학”이 일종의 마법 같은 언어학처럼 느껴졌기 때문임
대부분의 애플리케이션 프로그래밍 언어는 단일 값을 일종의 원자적 기반으로 삼음. 그 위에 리스트나 맵을 만들 수 있지만, 이것들도 결국 하나의 단일한 사물이고 미묘하게 서로 호환되지 않는 경우가 많음
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 am cold”라고 해보면, 지금 춥다는 뜻이지 어떤 슈퍼빌런처럼 영구히 차갑다는 뜻은 아니라고 받아들일 것임
마찬가지로 “I am living in London”은 현재 London에 살고 있지만 미래에는 바뀔 수 있음을 암시함
또한 항상 London에 산 것은 아니라는 뉘앙스도 있음. “I am cold”가 적어도 한 번은 충분히 따뜻한 온도를 겪어 봐서 지금 상태를 “정상”이 아니라 “춥다”고 알아차린다는 뜻을 어느 정도 품는 것과 비슷함