사고 도구로서의 Notation (1979)

 (jsoftware.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 표기법(Notation) 은 사고를 도와주는 중요한 도구로, 수학과 프로그래밍 언어 모두에서 핵심적인 역할을 함
  • APL 언어는 수학적 표기법의 장점을 프로그래밍 언어의 실행성과 보편성과 결합하려는 시도로 개발됨
  • 좋은 표기법의 특징은 간결성, 명확성, 제안성, 세부사항의 하위화, 공식 증명 가능성 등임
  • 다양한 수학적 구조(다항식, 변환, 그래프 등)를 APL로 효율적으로 표현하고 변환할 수 있음
  • 표기법의 도입과 학습은 문맥 안에서 자연스럽게 이루어져야 하며, 표기법의 구조성과 범용성 또한 중요함

사고 도구로서의 표기법

  • 화학, 식물학 등 과학 분야에서도 체계적 명명법이 학문의 발전을 촉진함
  • 조지 불은 언어 자체가 사고의 수단임을 강조했음
  • 수학적 표기법은 사고를 지원하는 언어의 대표적 사례로, 사고 부담을 줄이고 사고력을 증대시킴
  • A.N. 화이트헤드와 찰스 배비지가 수학 표기법의 중요성을 강조했음

프로그래밍 언어의 사고 도구로서의 가능성

  • 프로그래밍 언어는 범용성과 명확성이라는 강점을 가짐
  • 컴퓨터를 통한 아이디어 실험 및 명확한 사고 실험이 가능함
  • 그러나 대부분의 프로그래밍 언어는 수학적 표기법에 비해 사고 도구로서의 역할이 약함
  • APL은 명료성과 정밀성을 지향하여 사고를 지원하는 표기법으로 설계됨

좋은 표기법의 주요 특성

  • 문제 표현의 용이성: 문제에서 직접 파생되는 구조를 쉽게 표현할 수 있어야 함
  • 제안성: 표현된 형태가 유사하거나 확장된 문제를 암시해야 함
  • 세부사항의 하위화: 복잡한 세부사항을 단순화하여 사고를 돕는 구조 제공
  • 간결성: 최소한의 기호와 규칙으로 광범위한 표현을 가능하게 해야 함
  • 공식 증명 가능성: 표기법이 형식적 증명과 연역적 추론에 용이해야 함

APL의 기본 표기 기법 소개

  • 벡터, 행렬 등 배열 기반 구조를 자연스럽게 사용
  • 함수 및 연산자는 벡터/행렬을 요소별로 자동 적용
  • 리덕션(/), 스캔(\), 내적(.)과 같은 연산자(operators)로 함수 조합을 표현
  • ⍳, ⌽, ⍴, +, ×, * 등 기초 기호로 풍부한 수식 구성 가능
  • 모든 함수는 우측 우선 규칙을 따르며 괄호 없이 자연스러운 수식 작성 가능

문제 해결과 사고 촉진 예시

  • 삼각수, 계승 등 수학적 수열을 간단한 수식으로 표현
  • 다항식 표현과 곱셈, 미분 등 연산을 일관된 규칙으로 간명하게 처리
  • 그래프 이론(트리, 전이 클로저, 스패닝 트리)도 배열 연산으로 명확히 표현 가능
  • 순열, 부울 대수, 수 체계 변환(소수 분해) 등 다양한 분야에 확장 가능

공식 증명과 구조화된 사고

  • 모든 연산과 식은 명확히 실행 가능한 형태로 표현되므로 컴퓨터를 통한 자동 검증 가능
  • 수학적 귀납법, 완전 탐색, 항등식 열거 방식으로 다양한 공식 증명 예시 제시
  • 리덕션과 스캔의 분할(identity) 및 내적 연산의 결합성과 분배성 정식 증명
  • 뉴턴 대칭 함수, 다항식 곱셈 및 미분 공식 직접 증명

APL과 전통 수학 표기법 비교

  • APL은 함수의 명확한 정의, 일관된 배열 연산, 풍부한 기호 체계 제공
  • 모든 연산에 우선순위 규칙 대신 오른쪽 우선 실행 규칙 적용
  • 수학 기호 사용의 복잡성을 줄이고 형식적 조작(formal manipulation)을 지원
  • 구문이 간결하고 규칙이 일관되어 초보자와 숙련자 모두에게 유리함

표기법 도입과 학습 방법

  • 별도의 "언어 강의" 없이 문맥 속에서 필요한 표기만 자연스럽게 소개하는 방식을 강조
  • 구체적 문제 상황 속에서 새로운 기호를 직관적으로 학습
  • 표기법 자체의 난이도보다는, 표기법이 암시하는 다양한 가능성과 확장성을 인식하는 것이 중요함

APL 확장 가능성 및 제안

  • 복소수 처리를 포함한 함수 확장 제안
  • 넙(unique elements) 및 요약(summary) 함수 표준화 필요
  • 보다 일반화된 연산자(operator) 도입으로 벡터 미적분 등 추가 주제 지원 가능
  • 언어 설계의 명확성과 추론 능력 향상 목표

효율성과 명확성의 균형

  • 명확하고 분석 가능한 표기법을 먼저 정의한 후, 최적화를 통해 효율을 높이는 방식 권장
  • 알고리듬 명료화는 이후 최적화 및 컴파일러 최적화에도 도움을 줌
  • APL로 작성된 기본 표현은 학문적 탐구와 산업적 적용 모두에 기여 가능성

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 표기법을 셸 확장처럼 “표현식을 다른 표현식으로 치환하는 것” 정도로 보기 쉽지만, 실제로는 훨씬 깊음
    교수님이 위대한 발견이 종종 새 표기법과 함께 등장한다고 설명해 줬는데, 새 표기법은 “이 문제를 생각하는 새로운 방식”을 뜻함
    오늘날의 많은 미해결 문제도 강력한 표기법이 생기면 풀릴 수 있다고 봄

    • DSL/언어 주도 접근은 먼저 문제 공간에 직접 맞는 표기법을 만들고, 그다음 구현을 고민함
      이건 진짜 강력하지만 Lisp식에 가깝고, APL이나 Clojure식은 기본 타입을 정말 유용하게 만드는 쪽임
      데이터 구조 10개에 함수 10개씩보다, 데이터 구조 1개에 함수 100개를 두는 방식이라 APL에서는 DSL을 만들기보다 데이터를 아주 신중하게 설계하고 배치하면 나머지가 맞아떨어지는 식임
    • 표기법은 아이디어를 탐색하는 방식에 영향을 줌
      Richard Feynman은 십대 때 삼각법을 배우면서 사인과 코사인의 표기가 마음에 들지 않아 공식을 단순하게 만들고 잡음을 줄이려고 자기만의 수학 기호를 만들었음
      이후에도 Feynman diagrams나 slash notation처럼 물리학을 생각하는 방식과 표현 방식을 함께 새로 만들었음
    • 생각의 경제성과 인간공학 같은 게 있음
      작은 예로 CoffeeScript가 나왔을 때 람다 축약과 여러 문법 편의 덕분에 JavaScript를 쓰는 방식이 크게 바뀌었고, 생각하고 읽고 고치기 쉬워졌음
      SML/Haskell과 Lisp 계열도 비슷하게 느껴짐
    • 수학은 결국 기호를 이리저리 조작하는 일임
      Brian Greene과 Barry Mazur의 짧은 클립도 마음에 들 것 같음: https://youtu.be/8wQepGg8tHA

  • 역사적으로 APL을 밀어낸 건 이상한 키보드 말고도 IBM의 Lotus 1-2-3와 곧이어 나온 MS Excel이었음
    엔지니어, 학계, 회계사, MBA들은 TI-59나 HP-12C보다 나은 도구가 필요했는데, 컴퓨터과학 쪽은 기호 처리, AI, LISP에 몰두하고 있었고 결국 업계가 그 자리를 차지함
    APL은 스프레드시트보다 훨씬 큰 영향력을 갖고 더 많은 문제를 풀 수 있었을 텐데 아쉬운 우연임

    • APL은 절실하게 르네상스가 필요함
      원래 비전은 손으로 쓰는 일관되고 실행 가능한 수학 표기법이었지만, 끝내 달성되지 못했음
      관심 있다면 이 글을 읽어볼 만함: https://mlajtos.mu/posts/new-kind-of-paper
    • 이해하기로는 Dyalog가 운영 환경에 넣기 전까지 컴파일러를 무료로 제공함
      돈을 내지 않고 문제 해결을 할 수 있고, 유료 고객 앞에 컴파일 결과를 배포할 때 비용이 생김
      해법이 특정 부분집합에 맞으면 April로 옮겨 Common Lisp에서 제공하는 식으로도 갈 수 있음
      다만 APL 쪽 사람들은 대체로 매우 학구적이라 엔지니어링 작업을 빠르고 간결하게 해낼 수는 있지만, 평균적인 소프트웨어 회사에서 함수 랭킹이나 Naperian 함자 얘기를 꺼내면 동료들은 의료적 도움이 필요한지 의심할 수 있음
      소프트웨어 개발의 상당 부분은 고객과 사용자가 말하고 생각하는 방식을 표현하는 다소 형식적인 기술 언어를 발명하는 일인데, Iverson 계열 언어에서는 이게 쉽지 않음
      Java는 오랫동안 각 메서드에 어떤 비즈니스 단어가 들어오고 나가는지 명시하게 만들었고, 그런 점에서 조직의 개념을 코드에 매핑하기 쉬웠음
      APL에서도 데이터와 함수 이름을 붙일 수는 있지만, 긴 이름과 이름공간 구조를 들여와 외부 조직을 코드에 매핑하는 순간 간결함과 우아함을 잃음
      ML 계열의 정교한 타입 시스템에서도 개발자들은 발명된 준언어적 온톨로지와 조직·프로세스를 직접 연결하는 데 어려움을 겪고, 더 자주 수학적이거나 학술적인 개념을 택함
      양쪽을 모두 해낼 수 있는 사람이 있으면 가능하지만, 보통은 고객 세계로 번역하는 쪽만 잘해도 충분한 경우가 많음
    • APL은 일반 교육 과정에서 배우는 어떤 언어와도 매우 다른 기호 언어라, 스프레드시트에 비해 채택이 제한될 수밖에 없음
    • 아이러니하게도 최초의 스프레드시트인 APLDOT은 APL로 작성됐음

  • 작년에 The Array Cast가 1982년 Iverson 인터뷰를 다시 공개했음: https://www.arraycast.com/episodes/episode92-iverson
    꽤 흥미롭고 Turing 강연보다 접근하기 쉬운 편임
    1979년의 APL은 오늘날처럼 이상하고 변방의 언어가 아니었음
    그때는 프로그래밍 언어들이 지금처럼 전 세계적 대중 현상이 아니어서 거의 다 이상하고 변방에 가까웠고, C도 당시엔 꽤 새로웠음
    조금 너그럽게 보면 APL은 조밀한 C와 크게 멀지 않은 추상화처럼 보이며, 배열 위 포인터 조작을 직접 구현하지 않고 컴퓨터를 프로그래밍하게 해줬음

    • 1979년에는 많은 고등학교가 APL로 수학을 가르쳤음
      APL [1]이나 J [2] 문법으로 수학을 배우는 교재도 꽤 있음
      Iverson은 원래 APL을 수학을 위한 더 나은 문법으로 썼고, 프로그래밍 구현은 몇 년 뒤에 나왔음
      [1] https://alexalejandre.com/about/#apl
      [2] https://code.jsoftware.com/wiki/Books#Math_for_the_Layman
    • 세상에는 정말 기묘하게 좁은 주제의 팟캐스트가 많아서 늘 놀람
      예전에 지금은 중단된 타입 이론 팟캐스트를 들은 적이 있는데, 대단히 난해한 내용이었음

  • 기본 개념은 다른 유용한 개념들과 이어져 있음
    Sapir-Whorf 가설도 비슷한데, 뒤집어 생각할 때 더 흥미로움
    완벽하지 않은 언어에는 생각할 수 없거나 생각하기 어려운 것이 있고, 그렇다면 우리가 쓰는 언어로는 표현도 사고도 할 수 없는 것이 있는지 묻게 됨
    여기서 “언어”와 “생각”은 보통보다 넓게 볼 수 있음
    예를 들어 사회적 상호작용 규칙이 우리가 상호작용하는 방식을 결정하는가? Zeynep Tufekci는 “Twitter and Teargas”에서 Twitter가 플래시몹은 가능하게 하지만 지속적인 사회 변화는 어렵게 만든다고 말함
    누군가를 팔로우하거나, 댓글을 달거나, 좋아요를 누르는 같은 사회적 메커니즘이 서로 상호작용하는 방식을 결정하거나 가능하게 하는가? 다른 메커니즘이 더 나은 집단적 사고를 가능하게 할 수도 있음
    음악도 있음. 표기법이 아니라, 음악은 다른 방식으로는 잘 표현할 수 없는 무언가를 표현하는가?

    • 덜 완벽한 언어에서는 어떤 생각이 어려운 게 아니라, 애초에 그 생각이 떠오르지 않을 수 있음
      여러 외국어를 배운 입장에서, 특정 언어로만 생각할 수 있고 모국어인 영어로는 생각하기 어려운 것들이 많음
      예를 들어 우크라이나어와 러시아어의 “гулять”에는 영어가 포착하지 못하는 의미가 많아서, 그 언어들을 배우기 전에는 그런 의미들을 생각해 본 적이 없었음
      “Гулять”는 문자 그대로 “걷다”지만 경험을 찾아다니는 것, 성적 경험을 포함한 의미로도 쓰임
      누군가 너무 일찍 결혼했다며 “не нагулялся”, 즉 “충분히 걷지 못했다”고 불평할 수 있음
      영어에도 “sow his wild oats” 같은 비슷한 표현은 있지만, “걷다”라는 동사 하나에 그렇게 많은 의미가 담기면 삶을 걸어간다는 사고 자체가 달라짐
      아랍어를 배웠을 때도 그 언어로만 생기는 의미와 생각이 많았고, 영어로 설명이 불가능해서가 아니라 간결하게 표현할 표기법이 없어서 긴 글이 필요함
    • 은유와 유추도 비슷한 정신을 가짐
      어떤 사람은 언어를 통해 다른 생각으로 여행하는 것을 좋아하고, 어떤 사람은 그 가능성 앞에서 마비됨
      언제나 그렇듯 성공은 균형과 양쪽 모두에 있음

  • 수학자나 컴퓨터과학자에게는 너무나 명백한 사실인데도, 이 생각은 언어학자와 “교육자”들 사이에서 매우 논쟁적임
    언어학적 유사물은 Sapir-Whorf 가설인데, 어떤 언어를 배우느냐가 사고방식을 결정한다는 주장임
    자연어는 문화적 대상이고, 문화를 약한 부분순서로라도 매핑하는 일은 학계에서 금기처럼 여겨짐
    교육에도 큰 결과가 있는데, 학생들이 마주치는 문제를 진짜로 추론하게 해줄 표기법을 배우지 못하게 되는 경우가 있음
    이 부분은 솔직히 잘 이해가 안 됨

    • Sapir-Whorf가 더 원시적인 구성요소로 같은 아이디어를 만들 가능성을 부정하지는 않음
      어떤 언어 화자든 같은 수학이나 컴퓨터 프로그램을 배울 수 있다는 사실이 그걸 보여줌
      말이나 글로 된 언어가 사고에 꼭 필요한지도 의문임
      적어도 언어 없이도 가능한 사고의 큰 영역이 있고, 인간도 한때 말이 없거나 매우 적었으며, 소통하려는 생각과 의도가 단어와 언어를 만들었음
      그래서 배운 언어를 사고의 기본 모델로 보는 건 이상하게 느껴짐
    • Sapir-Whorf 얘기로 논쟁한 적이 있는데, 원래 생긴 맥락은 잘 모르지만 사람들이 인코딩의 아이디어를 경험 전체로 확장해 버린 것 같음
      예를 들어 어떤 사회가 바다 색과 풀 색을 같은 단어로 부른다고 해서, 두 색의 차이를 경험하지 못한다고 주장하기도 함
      경험을 비슷하게 기억으로 인코딩한다는 정도가 아니라, 차이를 보지 못한다는 식임
      어떤 언어에 없는 소리는 아예 듣지 못한다는 주장도 비슷함
      여기서의 표기법 논의는 그보다 어휘가 탐색에 쓰일 수 있다는 쪽에 가까움
      단순히 어떤 소리를 들었다가 아니라 음악을 들었고, 특정 화음 진행 등을 들었다고 말할 수 있게 되는 식임

  • 지금 APL로 프로젝트를 개발 중임
    오래 백로그에 있던 일이었지만 이제 실제로 코드를 쓰고 있음
    관심을 갖게 된 시점과 한 줄짜리 이상으로 쓸 수 있게 된 시점 사이에 꽤 긴 시간이 있었음
    그 과정 초기에 이 논문을 발견해 흡수하듯 읽었고, 지금은 그 개념들이 사고의 완전한 기반이 됐음
    실제로 건축 프로그램에서 NAATOT을 가르치고 있음
    소프트웨어 아키텍처가 아니라 건축 설계 쪽임
    Iverson의 핵심을 살리도록 편집한 버전을 쓰고, 실제 수학·프로그래밍은 요점을 보여주고 학생들이 설계와 표현 도구의 가능성을 다르게 생각하도록 도전할 만큼만 남겼음
    즉 아이디어를 형성하는 과정, 자기 자신과 타인에게 표현하는 방식 같은 것을 다룸
    더 느슨하고 열린 프로그램에서 할 기회가 있다면, 학생들이 건축 설계 영역에 적용할 자기만의 기호·표기 체계를 만드는 수업을 운영해 보고 싶음

  • 예전에 만들던 Freeform 노트 앱을 끝내지 못한 게 아쉬움
    SVG를 통해 독립형 웹페이지로 컴파일되는 앱이었고, STEM 분야에 흔한 기술적 콘텐츠에는 정말 멋진 아이디어였다고 봄
    예전 화학 노트 예시는 여기 있음: https://colbyn.github.io/old-school-chem-notes/dev/chemistry-1010---fall-2021/week-14-acids-and-bases.html

  • 몇 년 동안 APL을 일종의 마법처럼 보다가 올해 초 시간을 내서 배웠음
    APL로는 트윗 하나에 들어갈 만큼 엄청나게 많은 코드를 담을 수 있어서 놀라움
    재미있지만 쓰기는 어려웠음

    • 정도는 덜하지만 조밀한 NumPy 코드를 쓸 때마다 비슷하게 느낌
      쓰고 나면 거의 항상 “이걸 쓰는 데 이렇게 오래 걸렸다고?”라는 생각이 들고 다른 도구를 썼어야 했나 고민함
      하지만 실제로는 다른 도구가 훨씬 오래 걸렸을 것이라는 점이 직관에 잘 안 맞음
      어렵고 시간을 잡아먹는 것처럼 느껴지는 부분은 사실 문제 명세를 더 압축된 방식으로 정리하도록 강제받는 과정임
      더 가파르지만 훨씬 짧은 길을 오르는 것과 비슷해서, 더 힘들게 느껴지지만 실제로는 일이 적음
      그래서 APL을 배워 써야 할 것 같음
    • 공유할 만한 예제가 있는지 궁금함

  • “수학 표기법은 보편성이 부족하고, 주제·저자·문맥에 따라 다르게 해석되어야 한다”는 논문의 전제에는 개인적으로 동의하지 않음
    문제의 시각화와 인간공학에서 분리된 표기법에는 비용이 크다고 봄
    어떤 학자들은 복잡성을 많이 숨겨서 “유레카”식 깨달음이나 뜻밖의 동등성을 만들 수 있는 표기법을 선호하지만, 경우에 따라서는 오히려 흐리고 오류를 만들기 쉬움
    그래도 사고 과정을 전달하는 중요한 도구인 건 맞음
    어떤 영역이나 가까운 영역들에 하나의 표준 표기법만 두는 것은 추론과 문제 해결의 창의적·예술적·탐구적 측면을 꽤 억누른다고 생각함
    Terry Tao의 표기법 관련 훌륭한 설명도 있음: https://news.ycombinator.com/item?id=23911903

    • 이건 타입 있는 프로그래밍과 타입 없는 프로그래밍 논쟁처럼 느껴짐
      수학에는 Lean, Coq 같은 “엔터프라이즈” 추론 시스템을 만들려는 노력이 있고, 이런 경우에는 보편적 표기 체계가 타당함
      하지만 개인적 탐구라면 아무거나 끼워 맞추는 편이 더 나을 수 있음
      개인적으로는 교육에서 더 힘들었음
      대수 수업 등에서 교사가 표기법에 관한 개인적 결정과 선호를 일관되거나 솔직하게 다루지 않으면 힘들었고, 타입 이론과 기계적 증명 이론을 공부하면서 수학 실력이 크게 좋아졌음
    • 글에서 다루는 문제는 이런 다양한 표기들이 사실 그런 복잡함이 전혀 필요 없는 아주 기본적인 것에도 쓰인다는 데 있음

  • 논문의 “세부의 종속” 개념은 충분히 잘 파고들지 못했다고 봄
    APL 애플리케이션을 오래 읽고 쓰다 보니, 이 개념은 추상화와 근본적으로 다른 복잡성 관리 방식을 가리킨다는 걸 알게 됨
    우리는 API, 라이브러리, 모듈, 패키지, 인터페이스 같은 추상화 장벽에 둘러싸여 있고, 그 결과는 높은 추상화 탑, API를 붙이는 개발자, 하드웨어와의 단절, 성능 추론의 어려움 같은 익숙한 문제들임
    APL은 다른 접근을 매우 편하게 해줌
    추상화를 설계하는 대신, 단순한 표현식으로 쉽게 조작되도록 데이터를 신중히 설계함
    보통 라이브러리 함수나 DSL 용어가 있을 자리에 원시 연산을 직접 쓰는 식임
    예컨대 문자열 테이블, 키 배열, 값 배열로 벡터 값과 내부화된 키를 가진 해시맵 비슷한 구조를 만들고, 삽입·출력·삭제를 APL 표현식으로 바로 다룰 수 있음
    이 방식의 좋은 점은 각 표현식이 블랙박스가 아니어서 특정 필요에 맞게 자연스럽게 조정할 수 있다는 데 있음
    일반 해시맵 삽입이라면 새 키 추가 코드가 필요하지만, 여기서는 기존 키에 값만 추가하면 된다는 공통 불변식을 활용함
    라이브러리 API라면 쓰이지 않는 코드 경로, 여러 삽입 함수 변형, 또는 죽은 코드 제거를 위한 정교한 타입 추론이 필요했을 것임
    그런 접근은 도메인과 무관한 관심사를 코드베이스에 새게 만듦
    세부를 숨기는 대신 종속시키면 필요한 만큼 도메인별 세부에 접근할 수 있고, 관련 없는 세부는 필요할 때까지 배경에 조용히 남겨둘 수 있음
    물론 APL 표현식에 매우 익숙해야 하지만, Python 생태계 같은 것을 깊게 배우는 것보다 훨씬 더 큰 부담은 아니라고 봄
    실제로는 APL 기호들이 배경으로 사라지고, 영어 단어를 글자 단위가 아니라 단어·구 단위로 읽듯 의미 있는 구문으로 보이기 시작함

    • 거칠게 바꿔 말하면 “전부 인라인하라”는 뜻임
      대부분의 언어에서는 불가능하지만, 언어가 충분히 간결하고 표현력이 있으면 꽤 큰 범위에서 다시 가능해짐
      Arthur Whitney가 스크롤을 정말 싫어한다는 생각이 늘 떠오름
      파일 20개를 열어 놓고 “정의로 이동”을 따라다닐 필요도 없음
      전체 프로그램이 한 페이지에 들어오면 그런 것이 사라지고, 눈동자 움직임으로 탐색하게 됨
    • APL의 이상한 단어들이 마음에 듦
      진심으로 시간을 들여 배워야겠다고 느낌
      최근 몇 주 동안 겪은 고생과도 깊게 맞닿아 있음
      너무 강하게 결합된 레거시 Python 코드를 보고 있는데, 이전의 모든 “개선” 시도는 잘못된 데이터 모델 위에 추상화를 더 얹는 방식이었음
      코드를 선형으로 읽어서는 어떤 메서드가 입력 객체를 변경하는지 알 수 없음
      어떤 것은 변경하고 어떤 것은 안 하며, 때로는 변경 없이 같은 입력 인자를 그대로 반환하기도 함
      같은 인터페이스조차 공유하지 않는 여러 계산기를 팩토리가 돌려주는 우회로의 바다보다는, 차라리 분석하고 이해할 수 있는 마법 문자열이 낫겠음
    • 이건 의미 있는 관점에서 해시맵이 아님
      모든 연산이 O(n)이기 때문임
    • 그렇게 하면 추상화의 복잡성을 함수 코드에서 데이터 구조로 옮기는 것 아닌가 싶음
      일반 연산자를 쓸 수는 있지만, 값 쌍이 도메인 논리에서 무엇을 뜻하는지, 각 연산에서 올바른 구조를 어떻게 유지해야 하는지 신중히 이해해야 함
      처음 프로그램을 읽는 사람은 원시 연산이 아니라 비즈니스 도메인 의미를 이해하는 데 똑같이 어려움을 겪을 것임
      개선이 있다면 복잡성을 다른 곳에 둬서가 아니라, 코드와 실제 값이 동시에 보이기 때문이라고 봄
      복잡한 프로그래밍을 쉽게 만드는 것은 실행 시점 데이터와 코드 연산이 나란히 보이는 데 있고, 그래서 IDE 도구들이 디버거와 검사기를 계속 개선해 프로그램이 각 단계에서 무엇을 하는지 보여주려 함
      이 맥락에서는 연산 일부를 추상화하든 데이터 구조 일부를 추상화하든, 좋고 간결한 새 추상화를 만드는 것은 여전히 좋은 일임
    • “바로 접근 가능”하다는 표현은 과장으로 보임
      예시의 삽입 코드는 대부분 원하는 추가 작업이 아니라, 인터프리터가 입력하게 해주는 형태를 필요한 형태로 바꾸는 데이터 손질임
      ⍪←가 실제 추가이고, ↓⍉↑()()()는 APL과 인터프리터 입력 파서의 한계를 우회하기 위한 입력 파싱과 변환에 가까움
      삭제 코드도 'buggy'를 중첩 배열의 단일 요소로 찾기 위해 감싸는 등, 문제 영역과 무관한 Boolean 배열을 만들어야 함
      “벡터 값의 해시맵을 만든다”는 말도 실제 해싱이 없으니 오해를 부름
      중복 키 확인도 없고, 해시 선택이나 속도와 분포 조정도 불가능하며, 키가 순서대로 덧붙어 검색도 느려짐
      Dyalog APL에는 빠른 조회를 위해 배열을 내부 해싱 대상으로 표시하는 마법 인터프리터 명령인 I-Beam 1500도 있지만, 내부 추상화가 새어 나오는 점을 계속 기억해야 함
      “성공의 구덩이”, “방법은 하나만”, “처음 떠오른 방법이 맞는 방법이어야 함”, “다른 작업은 다르게 보여야 함” 같은 언어·도구 설계의 좋은 아이디어가 APL에는 빠져 있음
      Python이나 C#에서는 kv={'a':1, 'b':2} 같은 문법이 그냥 동작하고, 괄호나 콜론을 빼먹으면 명확히 틀려 보이며 편집기와 컴파일러가 도와줌
      APL 구현은 입출력에 ⎕NGET, ⎕CSV, ⎕JSON 같은 마법 인터프리터 함수에 의존하고, 오류 처리·로깅·디버깅도 약함
      표현식 전체가 하나로 실행되고, 훅과 포크 때문에 쉽게 쪼개기도 어려움
      결국 다양한 배열 모양, ⊂3이 왜 아무 일도 안 하는 것처럼 보이는지, ⊆와 ⊂의 차이, 스칼라 확장 등을 정확히 감각으로 알아야 실험과 학습도 가능해짐
      “키가 있으면 갱신하고 없으면 추가” 같은 즉시 접근 가능한 패턴도 APL에서는 분기 방식부터 다시 고민해야 함
      Python에서는 if/else와 key in map, C#에서는 if/else와 map.Contains(key)로 지나갈 일을 APL에서는 기본 기능을 재구현하는 고민으로 빠져듦
      Aaron Hsu가 한 주장과 비슷하지만, “소방차”라고 못 하고 “불을 멈추는 일을 하는 사람의 차”라고 말해야 하는 Up-Goer 5나 Toki Pona 같은 느낌임
      [1] https://docs.dyalog.com/latest/CheatSheet%20-%20I-Beams.pdf
      [3] https://aplwiki.com/wiki/Scalar_extension
      [4] https://xkcd.com/1133/
답변달기