이미 있었다
연속한 두 probe가 「빠진 기능을 강제한다」는 작정으로 출발해, 기능이 이미 세워져 있음을 발견했다. generic한 테스트 어서션에는 show가 타입 변수를 지나는 것이 필요하다 —— 지나고 있었다. 조용히, 순서 회와 같은 기구에 실려. fallible 파이프라인용의 평평한 조기 return 구문은 발명이 필요하다 —— 십수 Phase 전에 출하되어, 문서화되고, example에 다섯 곳의 실사용이 있었다. probe가 실제로 번 것은, 존재한 기능의 그림자에 숨어 있던 세 개의 실결함이었다: import로 데모를 실행하는 라이브러리들, interpreter가 떨어뜨리는 플래그, 당의 자신의 한 형태만의 비일관성.
이 Part의 probe 중 둘은 같은 반전을 공유하고, 그것은 방법 자신의 부끄러움을 포함한다. 둘 다 「기능을 존재로 강제한다」는 작정으로 출발했고, 둘 다 기능이 이미 거기 있음을 발견했다. 동작하는 형태로, 문서화까지 되어서. 「재고 나서 세운다」를 방법의 전부로 하는 1인 프로젝트에서, 재기 전에 누군가 —— 몇 달 전의 같은 인물 —— 가 이미 그것을 세워 두었음을 한 주에 두 번 발견하는 것은, 우습고, 겸허하게 하고, 그리고 한 화의 가치가 있다. 어느 probe든 본전은 뽑았기 때문이다: 각각이 존재한 기능의 그림자에 숨은 실물 결함을 찾았다.
이미 generic이었던 테스트 프레임워크
첫 probe가 원한 것은, assert_eq가 실패값을 generic하게 인쇄하는 테스트 프레임워크 —— 타입 변수
너머의 show의 자연스러운 forcing program이자, 순서 회의 명백한 속편이다. 첫 10분의 확인: show는
오늘, 타입 변수를 지나는가? 지난다 —— 4 backend 전부에서, 순서 회가 기술한 바로 그 기구에 실려,
같은 단상화 수정들로 신뢰할 만해져서. 그럼 프레임워크는? 그것도 이미 있었다: 표준 라이브러리의
contrib 영역에 Test 모듈, show 위에 세워진 generic한 assert_eq 딸림, 십수 Phase 전의 작품.
probe는 「세우기」에서 「검증하기」로 선회했다 —— 타입 변수 helper 너머의 어서션, 구조적으로
인쇄되는 실패값, suite에의 고정. 대신 찾은 것은 위생 결함이었다: 라이브러리 파일은 끝에 데모를
안고 있어, import한 모든 프로그램이 데모를 실행하고 있었다 —— 소음, 의도적 실패, 남의 exit code.
데모는 밖으로 옮겨지고, 규칙 —— 라이브러리 파일은 main-free —— 은 contrib 전체에 적용되어, 같은
결함을 가진 라이브러리가 다섯 개 더 발견되었다. 같은 세션이, 컴파일러는 존중하는데 interpreter가
말없이 떨어뜨리는 import 검색 경로 플래그도 붙잡았다 —— 이 프로젝트가 CLI의 솔기에서 계속 찾아내는,
interpreter/컴파일러 비대칭의 또 한 마리다.
이미 평평했던 구문
둘째 probe는 8단의 fallible 설정 로더를 세 가지로 써서 에러 핸들링의 쓰기 맛을 쟀다. 중첩 match의
피라미드는 예상대로 심했다 —— 7단 깊이, 같은 에러 전송 arm을 7번 복사, 그리고 글쓴이는 닫는 괄호를
두 번 잘못 셌다. 이것도 측정값이다. combinator 연쇄는 낫지만 inside-out으로 읽힌다. probe의 설계
노트는 수정안을 스케치했다: result를 unwrap하거나 에러를 조기 return하는 바인딩 형태. 그리고,
처음에 왔어야 할 docs의 grep: 그 형태는 있다. let x = e?! in body —— option 판 ?도 —— 는
십수 Phase 전에 출하되어, patterns 가이드에 전용 절을 갖고, 계산기 example에서 다섯 번 쓰이고 있다.
그것으로 다시 쓰니, 파이프라인은 바인딩의 평평한 열, 13줄, 피라미드 없음. probe의 유일한 실발견:
?/?!의 let은, 언어에서 유일하게 ;를 in의 대용으로 거부하는 let 형태였다 —— 다른 모든 let은
두 구분자를 받는다. 파서 두 줄로 비일관성은 닫혔다.
교훈의 정식화
「이미 있었다」가 한 번이면 일화지만, 한 주에 두 번이면 방법에 대한 데이터다. probe들은 runtime을 심문하도록 설계되어 있었다 —— builtin을 grep하고, 식에 타입을 붙이고, 프로그램을 돌린다 —— 능력의 gap은 거기에 살기 때문이다. 하지만 기능은 한 단 위, 구문과 라이브러리에 산다. probe의 정직한 첫걸음은 이제 프로젝트의 노트에 적혀 있다: probe를 쓰기 전에 docs를 grep하라 —— 언어 레퍼런스의 당의 일람, patterns 가이드, contrib의 README 표. 부드러운 독법도 있다. 작자가 「더하려던 것을 이미 한다」고 반복해 발견하는 언어는, 작은 문턱을 넘은 것이다: 작자의 작업 기억보다 커졌다는 문턱을. 문서는 그것을 위해 있고, 두 probe는 모두, 문서와 —— 기능 둘레의 솔기를 —— 발견했을 때보다 좋게 만들고 떠났다. 남은 두 화는 정말로 존재하지 않았던 것으로 돌아간다: 언어에 일본어를 쳐 넣으면 무엇이 일어나는가, 그리고 백만 요소에서 무엇이 일어나는가.