![3db2d377abd531a04e81d2b628f1766e783d1b](https://dcimg8.dcinside.co.kr/viewimage.php?id=3dafdf21f7d335ab67b1d1&no=24b0d769e1d32ca73de884fa11d02831916c2f0b7815b9ba7a4fbb54989ad37051ad602963a6a870f786c34828c254db5d3c1b7fb5a1721b75f88a80764ad6e6da89)
컴퓨터 과학의 선구자이자 '최초의' 튜링상 수상자인 앨런 J 펄리스는
Epigrams on Programming 이라는 짧고 강렬한 격언 모음집을 통해서 프로그래밍에 대해 깊이있는 통찰을 보여준다.
펄리스는 프로그래밍 언어를 단순한 도구를 넘어 사고방식과 문제 해결 방식에 미친다는 주장을 한 사람으로 유명하다.
앨런 펄리스는 1982년 "Epigrams on Programming(프로그래밍에 대한 경구)" 라는 에세이를 쓰는데,
이 경구는 웃음을 주면서 프로그래머로써 많은 생각을 하게 해준다.
이번 글은 Alan Perlis의 말을 번역한 것이다.
*개인적으로 생각하건데 평균적으로 대머리일수록 프로그래밍의 대가가 될 확률이 높은 것 같다. 뇌 오버클럭을 통한 발열제어에 대머리가 유리해서일까?
진화론적인 진지한 고찰이 필요하다고 생각한다. 아쉽게도 필자는 대머리가 아니기때문에 프로그래밍 대가가 되긴 힘든것 같다.
![3dbe8168f5dc3f8650bbd58b3682746f2fe4c1](https://dcimg8.dcinside.co.kr/viewimage.php?id=3dafdf21f7d335ab67b1d1&no=24b0d769e1d32ca73de884fa11d02831916c2f0b7815b9ba7a4fbb54989ad37051ad602963a6a870f786c30d7d993fdccb5383f6dcd2342fc1f7609d6bebff1268ee295f38ca)
1.어떤 사람에게는 상수가, 다른 사람에게는 변수가 된다.
2.함수는 결합을 늦추고, 데이터 구조는 결합을 강제한다.
-교훈: 프로그래밍 과정 후반부에 데이터 구조를 설계하라.
3.문법적 설탕(Syntactic Sugar)은 세미콜론 중독(Semicolon Cancer)을 유발한다.
- (역주: **문법적 설탕(Syntactic Sugar)**이란 코드를 더 간결하고 읽기 쉽게 만드는 기능이지만, 남용하면 가독성을 해칠 수 있다.)
4.모든 프로그램은 더 큰 프로그램의 일부이며, 드물게만 단독으로 완벽하다.
5.프로그램이 많은 데이터를 처리해야 한다면, 반드시 적은 수의 방식으로 처리하라.
6.대칭성(Symmetry)은 복잡성을 줄이는 개념이다. (예: 코루틴은 서브루틴을 포함한다.)
-가능한 한 대칭성을 유지하라.
7.올바른 프로그램을 이해하는 것보다, 잘못된 프로그램을 작성하는 것이 더 쉽다.
8.프로그래밍 언어가 불필요한 것에 신경을 써야 할 때, 그것은 저수준 언어다.
9.10개의 데이터 구조에 적용되는 10개의 함수보다, 하나의 데이터 구조에 적용되는 100개의 함수가 더 낫다.
10.일찍 표준화하라: 같은 작업은 같은 방식으로 수행하라. 관용구를 축적하고, 표준을 만들어라.
- 셰익스피어와 당신의 차이는 어휘력이 아니라, 사용 가능한 관용구 목록의 크기이다.
11.10개의 매개변수를 가진 함수가 있다면, 아마도 몇 개를 빠뜨린 것이다.
12.재귀는 계산의 본질이며, 실행 시간을 설명력과 맞바꾸는 방식이다.
13.두 사람이 정확히 같은 프로그램을 작성한다면, 그것을 마이크로코드로 변환했을 때 완전히 동일하지 않을 가능성이 크다.
14.장기적으로 모든 프로그램은 로코코 양식(화려하고 복잡한 디자인)이 되었다가, 결국 폐허가 된다.
15.모든 것은 하향식(Top-down)으로 구축되어야 한다. 단, 처음 한 번은 예외다.
16.모든 프로그램은 최소한 두 가지 목적을 가진다: 원래 의도한 목적과, 의도하지 않았지만 사용되는 또 다른 목적.
17.당신이 프로그램을 설명할 때, 듣는 사람이 계속 고개를 끄덕인다면, 그를 깨워라.
18.반복문(Loop)과 구조화된 데이터 변수가 없는 프로그램은 작성할 가치가 없다.
19.프로그래밍에 대한 사고방식에 영향을 미치지 않는 언어는 배울 가치가 없다.
20.모듈성이 있는 곳에는 오해의 소지가 있다.
- 정보 은닉(Information Hiding)은 상호작용을 조정할 필요성을 의미한다.
21.최적화(Optimization)는 코드의 진화를 방해한다.
22.좋은 시스템은 약한 명령 언어(Command Language)를 가질 수 없다.
23.프로그램을 완전히 이해하려면, 당신은 기계이자 프로그램이 되어야 한다.
24.어쩌면 우리가 어릴 때부터 프로그래밍을 배웠다면, 어른이 되어서도 프로그램을 더 쉽게 읽을 수 있을 것이다.
25.복잡한 정보는 머릿속에서만 제대로 표현될 수 있다.
- 정적인 다이어그램보다 흐름과 시점의 변화가 더 중요하다.
26.모든 프로그래밍 언어에는 표현하기 어려운 개념이 항상 존재할 것이다.
27.프로그램을 작성하는 방법을 완전히 이해했다면, 다른 사람에게 작성하도록 시켜라.
![3db2d374abc53da47e9fe8b115ef046cf66e6f20ca](https://dcimg8.dcinside.co.kr/viewimage.php?id=3dafdf21f7d335ab67b1d1&no=24b0d769e1d32ca73de884fa11d02831916c2f0b7815b9ba7a4fbb54989ad37051ad602963a6a870f786c34828c254db5d3c1b7fb5a1734d77f98ad3724ad6f6e42a70)
(Sagrada Familia)
28.컴퓨터 세계에서는 진행 상황을 측정하는 올바른 시간 단위를 찾기가 어렵다.
- 어떤 성당은 건축하는 데 한 세기가 걸렸다. 프로그램도 그만큼 오래 걸릴 수 있을까?
(역주:Sagrada Familia를 말한다. 참고로 아직도 완공이 덜되고, 2026년 완공 예정이다.)
29.시스템에서 "성형 수술"의 개념은 단순한 추가가 아니라, 제어 그래프(Control Graph)에 새로운 순환 경로를 추가하는 것이다.
30.우리가 프로그래밍에서 하는 모든 것은 보다 일반적인 개념의 특수한 사례이며, 종종 우리는 그 사실을 너무 빨리 깨닫는다.
31.단순함(Simplicity)은 복잡함에 선행하는 것이 아니라, 복잡함을 해결한 후에 온다.
32.프로그래머는 창의성이나 논리가 아니라, 예외 케이스를 얼마나 철저히 분석했는가로 평가받아야 한다.
33.11번째 계명은 "너는 계산해야 한다" 또는 "너는 계산하지 않아야 한다"였다. 어느 것인지 기억나지 않는다.
34.문자열은 냉혹한 데이터 구조다.
- 어디든 전달되는 곳에서 중복을 초래하며, 정보를 감추기에 완벽한 매개체다.
35.누구나 조각하는 법을 배울 수 있다. 하지만 미켈란젤로는 조각을 멈추는 법을 배워야 했을 것이다.
- 위대한 프로그래머도 마찬가지다.
36.4색 정리를 프로그램을 이용해 증명한다고 해서 수학이 변하는 것은 아니다.
- 그저 한 세기 동안 난제로 여겨졌던 정리가, 사실 그렇게 중요하지 않을 수도 있다는 것만 보여줄 뿐이다.
(역주: 지도 위의 모든 나라를 색칠하는데, 인접한 나라까지 색이 겹치지 않게끔 칠하려면 4가지 색만으로도 충분한지를 따지는 문제)
(역주2: 볼프강 하켄 과 케네스 아펠이 컴퓨터로 브루트 포스를 사용해서 4색 정리를 증명한게 유명하다)
37.가장 중요한 컴퓨터는 우리의 두개골 속에서 움직이고 있다.
- 완전히 표준화된 컴퓨터는 재앙이 될 것이다. 그래서, 아마도 그런 일은 일어나지 않을 것이다.
38.구조적 프로그래밍은 "제외된 혼란의 법칙(The Law of Excluded Chaos)"을 따른다.
39.그래픽(Visualization)에 대해:
- 그림 한 장은 10K 단어의 가치를 지닌다.
- 하지만, 단어로 설명할 수 있는 부분에 한해서만 그렇다.
- 10K 단어 중에서 그림으로 완전히 설명할 수 있는 것은 극히 일부뿐이다.
40.오류 없는 프로그램을 작성하는 방법은 두 가지가 있다.
- 하지만, 세 번째 방법만이 실제로 작동한다.
41.일부 프로그래밍 언어는 변화를 흡수하지만, 발전을 저지한다.
42.프로그래머의 태도는 그가 포트란(Fortran)에 대해 어떻게 생각하는지를 보면 알 수 있다.
43.소프트웨어 시스템에서는, 버그를 가장 빨리 발견하는 사람이 가장 먼저 해결할 수 있다.
44.때때로 컴퓨팅 분야에서 유일하게 보편적인 개념은 "인출-실행 주기(Fetch-Execute Cycle)"라고 생각된다.
45.컴퓨터 과학의 목표는 우리의 분석적 능력을 모방하는 것이 아니라, 종합적 능력을 모방하는 것이다.
46. 말장난처럼, 프로그래밍도 단어 유희(wordplay)이다.
47.윌 로저스(Wil Rogers)의 말을 빌리자면,
"자유 변수(free variable)란 존재하지 않는다."
48.프로그래밍을 위한 최고의 책은 《이상한 나라의 앨리스(Alice in Wonderland)》이다.
- 왜냐하면 그것은 어떤 주제든 초보자를 위한 최고의 책이기 때문이다.
49.어셈블리 언어를 포기한 것은 에덴동산에서 사과를 따먹은 것과 같다.
- 기계 자원을 낭비하는 언어는 죄악이다.
- LISP 머신 덕분에 이제 LISP 프로그래머들은 브래지어나 무화과 잎(fig-leaf)을 벗어던질 수 있다.
50.지식 기반 시스템(Knowledge-based System)을 완전히 이해했을 때, 세상은 이전과 다를 바 없을 것이다.
-다만 우리의 손끝이 더 뜨겁게 달궈졌을 뿐이다.
(역주: 지식 기반 시스템은 인간 전문가의 지식을 컴퓨터 시스템에 담아, 전문가처럼 문제를 해결하거나 의사결정을 지원하는 인공지능 시스템임)
51.컴퓨터를 가정으로 가져온다고 해서 가정도, 컴퓨터도 변하지 않는다.
-하지만, 동네 술집은 활기를 띠게 될지도 모른다.
52.모든 시스템은 하위 시스템을 가지며, 하위 시스템은 또 다른 하위 시스템을 가진다.
- 이 끝없는 구조 덕분에 우리는 항상 처음부터 다시 시작해야 한다.
53.수많은 좋은 아이디어가 의미의 심연(semantic gulf)에 빠진 뒤 다시는 모습을 드러내지 않는다.
54.튜링 늪(Turing tar-pit)을 조심하라.
- 모든 것이 가능하지만, 흥미로운 것은 단 하나도 쉽지 않다.
(역주: Tar Pit는 즉 타르 웅덩이는 겉보기에는 평온하고 안정적이나, 깊이 들어갈수록 감당하기 어려워진다는 의미, 즉 프로그래밍이 깊이 들어갈수록 복잡해져서 헤어나오기 힘들어진다는 말)
55.LISP 프로그래머는 모든 것의 가치를 알지만, 그 비용은 모른다.
56.소프트웨어는 항상 긴장 상태에 있다.
- 상징적(symbolic)이기 때문에 무한히 완벽해질 수 있지만, 동시에 무한히 변할 수도 있다.
57.프로그램을 사양(specification)에 맞추는 것보다, 사양을 프로그램에 맞추는 것이 더 쉽다.
58.바보는 복잡성을 무시한다.
- 실용주의자는 복잡성을 견딘다.
- 어떤 사람들은 복잡성을 피할 수 있다.
- 천재는 복잡성을 제거한다.
59.영어에서는 모든 단어가 동사가 될 수 있다.
- 우리의 프로그래밍 언어도 그렇게 될 수 있다면 얼마나 좋을까?
60.데이나 스콧(Dana Scott)은 '격자형 성도회(Church of the Lattice-Way Saints)'의 교주다.
- (역주: Dana Scott은 형식적 의미론의 거장이고, Church는 lambda calculus를 창시한 Alonzo Church를 가리킨다.)
61.프로그래밍에서, 실수를 한다는 것은 곧 다시 태어난다는 것이다.
62.컴퓨팅에서 불변성(Invariant)은 찰나에 지나지 않는다.
63.우리가 "학습하는 프로그램"을 만든다고 하지만, 결국 배우는 것은 우리이고, 그들은 배우지 않는다.
64.때로는 수단이 목적을 정당화한다.
- 목표가 기술을 발전시키고, 목표가 무너진 뒤에도 기술은 살아남는다.
65.컴퓨터는 본질적으로 숫자를 처리한다.
- 우리는 특정한 활동을 숫자로 변환할 수 있는 범위만큼만 그 활동을 이해하고 제어할 수 있다.
66.무언가를 변수로 만드는 것은 쉽다.
- 변수를 일정 기간 동안 일정하게 유지하는 것이 진짜 어려운 일이다.
67."알고리즘"과 "프로그램"의 차이를 찾으려 수많은 정신적 에너지가 낭비되었다.
68.데이터 구조를 믿는다면, 병렬(동시) 처리를 믿어야 한다.
- 왜냐하면 데이터를 구조화하는 이유는 함께 저장하고 동시에 처리하기 위함이기 때문이다.
- 그렇다면, 우리는 왜 단일 처리 방식만 제공하는 언어를 용인하는가?
69.5년마다 한 번씩 탁월한 프로그래밍 언어가 등장한다.
- 다만, 우리가 그 주기를 조절할 수 없을 뿐이다.
70.수세기 동안 인디언(원주민)들은 손짓(sign language)으로 자신들의 관심사를 전달해 왔다.
- 프로그래머들도 부족(FORTRAN, LISP, ALGOL, SNOBOL 등)에 따라 손짓 언어를 만들어야 할까?
71.문서는 생명보험과 같다.
- 구독자들은 만족하지만, 실제로 그 혜택에 의존하는 사람은 거의 없다.
72.완벽한 부트스트랩(bootstrap)이란 존재하지 않는다.
73.언어의 약점이 아니라, 강점이 그 언어의 변화 속도를 결정한다.
- 아쉽게도, 언어는 결코 태아의 주머니(embryonic sac)를 벗어나지 못한다.
74.소프트웨어는 다른 어떤 것과도 다를 수 있다.
- 아마도 소프트웨어는 폐기되기 위해 존재하는 것일지도 모른다.
- 비누방울처럼 영원히 새로운 형태로 재탄생하는 것이 본질일 수도 있다.
75.컴퓨터 분야는 언제나 새로운 클리셰(cliché)를 갈망한다.
- 진부함이 우리의 신경을 안정시켜 주기 때문이다.
76.절차의 매개변수를 설정하는 것은 프로그래머가 아니라, 사용자여야 한다.
77.인간, 컴퓨터, 알고리즘 간의 상호작용은 마치 의자 뺏기 게임 같다.
- 균형을 찾기 위한 필사적인 몸부림 끝에 결국 하나는 불안정한 상태로 남게 된다.
78.만약 당신의 컴퓨터가 영어를 사용한다면, 아마 그것은 일본에서 만들어졌을 것이다.
79.인공지능(AI)에 1년을 투자한 사람이라면, 신을 믿게 될지도 모른다.
80.컴퓨터와 오랜 시간 함께하면, 수학자는 서류 작업을 하는 관리인이 되고, 관리인은 수학자가 된다.
81.컴퓨팅에서 "명확한 것(obvious)"을 "유용한 것(useful)"으로 바꾸는 과정은 곧 "좌절(frustration)"의 정의이다.
82.우리는 위대한 발견의 문턱에 있다. 오늘, 우리 프로그램이 페르마의 '다음으로 어려운 정리'를 증명했다!
8.튜링 머신과 현대 컴퓨터의 차이점은 무엇인가?
- 그것은 마치 힐러리(Hillary)가 에베레스트를 등반한 것과, 정상에 힐튼 호텔을 세운 것의 차이와 같다.
84.연구소의 모토:
- "우리가 오늘 연구하는 것은, 다른 사람들이 내일 처음으로 생각해낼 것이다."
85중국인들은 APL을 사랑할 수도 있었겠지만, 결국 돈을 번 것은 FORTRAN이었다.
(역주: 이때 중국인은 수학을 잘하는 동양인들을 지칭함. APL이 기술적으로 더 뛰어났지만 결국 산업이 선택한 것은 포트란이었다는 것)
86.우리는 '활성 데이터베이스 시스템(active database system)'에서 프로시저(절차)와 데이터의 비율을 마음대로 줄이거나 작게 유지할 수 있다고 착각한다.
87.우리는 미니(mini) 컴퓨터와 마이크로(micro) 컴퓨터를 만들었다.
- 그렇다면 피코(pico) 컴퓨터는 어떤 의미론적 틈새(niche)에 속할까?
88.맥스웰 방정식(Maxwell's equations)만으로는 전기 모터를 설계할 수 없다.
- 그것은 컴퓨터의 잘못이 아니다.
89.손 계산기를 사용한다고 컴퓨터를 배우는 것은 아니다.
- 하지만, 산수를 잊어버릴 수는 있다.
90.계산이 나무를 꽃피게 했다.
(역주: 여기서 말하는 계산은 컴퓨터 과학 전반을 말하고, 컴퓨터 과학이 새로운 가능성과 창의성을 열었다는 은유)
91.컴퓨터는 론 체니(Lon Chaney, 할리우드 배우)를 닮았다.
- 수천 개의 얼굴을 가진 기계이다.
92.컴퓨터는 궁극적인 오염원이다.
- 그것이 배설하는 것과 생산하는 것을 구별할 수 없다.
93어떤 사람이 "나는 단순히 원하는 것을 말하기만 하면 되는 프로그래밍 언어를 원한다"고 말한다면,
- 그에게 막대사탕을 줘라.
(역주: 그런 비현실적인 꿈은 어린아이나 꾸는 꿈이니까 사탕을 주라는 말이지만, 개인적으로 필자가 지지하는 뜻은 헛소리 듣고 싶지 않으니 사탕으로 입다물게 해라다)
94.인터페이스는 정돈을 유지하지만, 성장 속도를 높이지 않는다.
- 성장을 가속하는 것은 함수(function)다.
95.좋은 아이디어를 가졌다면, 그것에 대한 책임을 질 준비도 해야 한다.
96.컴퓨터는 질서를 가져오기보다는, 기회를 노출시킨다.
97.어떤 교수가 "컴퓨터 과학이 X는 맞지만, Y는 아니다"라고 단언한다면,
- 그의 대학원생들에게 연민을 가져라.
98.컴퓨팅에서 고장까지의 평균 시간(mean time to failure, MTTF)은 점점 짧아지고 있다.
99.인간-기계 공생(man-machine symbiosis)에서, 조정(adjustment)해야 하는 것은 인간이다.
- 기계는 스스로 조정할 수 없다.
100.단 하나의 프로그램이 존재하는 한, 우리는 프로그래밍할 것이 끝나지 않을 것이다.
101.실패를 다루는 것은 쉽다.
- 열심히 개선하면 된다.
- 성공을 다루는 것도 쉽다.
- 너는 잘못된 문제를 해결한 것이다.
- 열심히 개선하면 된다.
102.비공식적인 것에서 공식적인 것으로 나아가는 것은,
- 공식적인 방법으로는 불가능하다.
103.순수하게 응용적인(purely applicative) 언어는,응용하기에 적합하지 않다.
104.어떤 시스템이 가치가 있다는 증거는,그 시스템이 존재한다는 사실이다.
105.복잡성을 전달할 수는 없다.우리는 그 존재를 인식하는 것밖에 할 수 없다.
106.문자열(string)에서 의미를 추출하는 것은 어렵다.
-하지만, 그것은 우리가 신뢰할 수 있는 유일한 커뮤니케이션 수단이다.
107.논쟁은 계속된다:
-PL/I는 쌍봉낙타(Bactrian Camel)인가, 단봉낙타(Dromedary Camel)인가?
(역주: 프로그래밍 언어인 PL/I에 대한 논쟁을 낙타로 비유한 것으로, PL/I는 단순한 언어인가, 복잡한 언어인가로 논쟁이 일어난 것을 낙타에 비유하며 말한 것이다)
108.두 명의 프로그래머가 만나 서로의 프로그램을 비판하기 시작하면,
- 둘 다 조용해진다.
109.생각해 보라!
- VLSI(Very Large Scale Integration) 기술을 통해,
- 우리는 1제곱센티미터 안에 100개의 ENIAC을 집어넣을 수 있다!
110.편집(editing)이란 결국 다시 쓰는(rewording) 행위다.
111.로마 제국은 왜 멸망했을까?
- '사무 자동화(office automation)'의 라틴어 표현이 뭐였더라?
112.컴퓨터 과학은 '컴퓨터'라는 존재 때문에 당황스러워한다.
113.신경과학과 심리학을 연결하는 유일한 건설적인 이론은 소프트웨어 연구에서 나올 것이다.
114.컴퓨터 안에서 '자연어(natural language)'란, 결코 자연스럽지 않다.
115.대부분의 사람들은 프로그래밍의 개념을 직관적으로 이해하지만, 실제로 프로그래밍을 하는 것은 불가능하다고 여긴다.
116.배울 때 안다고 생각하고,
- 쓸 수 있을 때 더 확신하고,
- 가르칠 수 있을 때 더욱 확신하지만,
- 프로그래밍할 수 있을 때만이 확실하다.
117.현대 교육은 아이들에게 프로그래밍을 가르치는 것에 반한다.
- 왜냐하면, 계획을 세우고, 사고를 조직하며, 세부 사항을 신경 쓰고, 자기 비판적인 태도를 배우는 것이 무슨 재미가 있겠는가?
118.컴퓨터-로봇이 유일한 하인이 되는 사회를 상상할 수 있다면, 그대는 무엇이든 상상할 수 있을 것이다.
119.프로그래밍은 본질적으로 부자연스러운 행위다.
120.기존 프로그램을 새로운 기계에 맞추려는 대부분의 노력은, 결국 새로운 기계를 옛날 기계처럼 작동하도록 만드는 것이다.
121.도달할 수 없는 것을 추구할 때, 단순성은 장애물이 된다.
- 격언(epigram)이 있다면, 반드시 메타-격언(meta-epigram)도 있을 것이다.
122.격언(Epigrams)은 통찰과 이해가 흐르는 인터페이스다.
123.격언은 '아우라(aura)'를 매개변수화한다.
124.격언은 '매크로(macro)'다.
- 왜냐하면, 그것은 읽는 순간 실행되기 때문이다.
125.격언은 모순을 결정화(crystallize)한다.
126.격언은, 절차로만 이루어진 데이터베이스에서 깊은 의미를 끄집어낸다.
127.격언은 디테일을 무시하고, 핵심을 찌른다.
- 그것은 훌륭한 고수준(high-level) 문서다.
128.격언은 단백질보다는 비타민에 가깝다.
129.격언은 극도로 낮은 엔트로피(entropy)를 가진다.
130.마지막 격언?
- "격언은 먹지도, 마시지도 말고, 코로 들이마시지도 말라."
이제 독자들도 프로그래밍을 재밌고 말하는 방법을 배웠다
앞으로 글을 쓸때 이런 격언을 사용하여 글에 향신료를 더하는 것은 어떨까?
댓글 영역
획득법
① NFT 발행
작성한 게시물을 NFT로 발행하면 일주일 동안 사용할 수 있습니다. (최초 1회)
② NFT 구매
다른 이용자의 NFT를 구매하면 한 달 동안 사용할 수 있습니다. (구매 시마다 갱신)
사용법
디시콘에서지갑연결시 바로 사용 가능합니다.