폴 그레이엄 어록 #3



얼른얼른 정리하고 다른 책 얘기로 넘어가려고 한참 전에 읽고는 쌓아둔 메모를 정리한다.

낭비 예찬 #1:
테크놀로지가 향상됨에 따라 어느 세대는 이전 세대가 낭비라고 여길 만한 일을 할 수 있다. (원문을 한국식으로 수정)수도권안에서 배달되는 택배가 대전을 거쳐가는 경우가 적지 않다는 사실에 100년전의 사람들은 얼마나 놀랄 것인가. 마찬가지로 100년후의 하드웨어가 우리에게 제공해줄 추가적인 사이클을 가지고 우리가 무엇을 하게 될지는 분명하다. 추가 사이클의 대부분이 그냥 낭비될 것이다.
세상에는 좋은 낭비와 나쁜 낭비가 있다. 나는 더 많이 소모함으로써 더 단순한 디자인을 얻을 수 있는 좋은 낭비에 관심이 있다. 새로운 언어를 디자인할때 우리는 사소한 편의를 향상시키기 위해 과감히 효율성을 포기할 수 있는 상황을 의식적으로 찾아야 한다.

낭비 예찬 #2:
대부분의 데이터 구조는 속도 때문에 존재한다. 오늘날의 많은 언어는 문자열과 리스트를 별도로 가지고 있다. 의미론적으로는 문자열이란 내부 항목이 문자인 리스트에 불과하다. 사실 두 개의 데이터 구조의 구분이 필요하지 않다. 문자열이란 다만 효율성을 위해 존재할 뿐이다. 배열도 마찬가지다. 배열이란 결국 키가 정수의 벡터에 불과한 해시테이블이다. 더 나아가보자. 논리적으로 보면 언어에 숫자를 나타내기 위한 별도의 표기법마저 필요하지 않다. 그들 역시 리스트로 표현될 수 있다. n이라는 정수는 n개의 요소를 갖는 리스트로 나타낼 수 있다.
프로그램을 더 빠르게 동작시키기 위해 언으의 의미론적 특성을 교란시키는 것은 타당하지 않다.

낭비 예찬 #3:
100년 뒤의 프로그래머들이 사용하게 될 언어는 무엇보다도 최소한의 노력으로 믿을 수 없을 정도로 비효율적인 버전 1.0 프로그램을 작성할 수 있는 언어일 것이다. 비효율적인 소프트웨어가 그 자체로 엉터리인 것은 아니다. 진짜 엉터리는 프로그래머에게 불필요한 일을 강제하는 언어이다. 기계의 시간이 아니라, 프로그래머의 시간을 낭비하는 것이 진짜 비효율성이다.

꿈의 언어 #1:
좋은 언어는 깨끗함과 동시에 더러워야 한다. 언어는 쉽게 이해되는 핵심과 그에 상응하는 연산자 등으로 깔끔하게 설계되어야 하지만 그와 동시에 해커들이 마음껏 가지고 놀 수 있을 만큼 적당히 지저분하기도 해야 한다. C가 이런 식이었다. 초창기 리스프도 그랬다. 진짜 해커들을 위한 언어는 항상 약간의 바람기를 담고 있어야 한다.

꿈의 언어 #2:
꿈의 언어는 우선 깨끗하고 간결하다. 빠르게 시작하는 인터랙티브한 core를 가지고 있다. 작성된 코드는 거의 모두 특정한 어플리케이션이 필요로하는 내용일 뿐, 나머지는 이미 언어의 내부에 존재하고 있다. 언어의 문법은 실수를 저지르기 어려울 만큼 간단하다. 불필요한 타이핑은 거의 없으며 심지어 쉬프트 키를 사용할 경우도 거의 없다.
언어를 배울 수 있는 예제가 풍성하고 몇분만 들여다보면 사용법을 금방 알 수 있을 정도로 직관에 충실하다. 매뉴얼은 자주 들여다볼 필요도 없고, 게다가 얇으며 경고나 조건은 거의 붙어있지 않다.
작은 코어 만큼이나 신중하게 설계된 강력하고 날카로운 라이브러리를 가지고 있다. 호환성을 담보하기 위해 제거되었거나 억지로 유지되는 것은 거의 없다. 모든 라이브러리의 소스코드는 쉽게 구해서 볼 수 있다.
그 언어는 당신이 그 언어의 설계에, 심지어 문법까지 포함해서, 동등한 자격으로 참여하라고 권장한다. 당신이 그 언어로 작성한 것은 이미 정의되어잇는 것들과 최대한 동등한 자격을 부여받는다. 꿈의 언어는 단지 오픈소스에 그치는 것이 아니라, 오픈 디자인까지 포함한다.

디자인과 사용자 #1:
무언가를 디자인을 할때는 목표로 삼는 사용자 그룹이 있어야 한다. 목표로 삼은 사용자 그룹안에 설계자 자신이 포함되어 있으면 좋은 디자인을 산출할 가능성이 한층 높아진다. 자기가 속해있지 않은 그룹을 위해 무언가를 설계할 때는 그 그룹 안의 사람들이 아무래도 자기보다 덜 똑똑하다고 생각하게 된다. 사용자를 위에서 내려다보기 시작하면 설계자의 작업을 망치기 쉽다.
내가 보기에 미국에는 건축가 자신이 살기 위해 지은 집이 별로 없다. 프로그래밍 언어도 마찬가지다. C, 리스프, 스몰토크는 설계자들이 직접 사용하려고 만든 언어다. 그에 비해서 코볼, 에이다, 자바는 다른 사람더러 사용하라고 만든 언어이다.
당신이 바보 천치들을 위해서 무언가를 만들고 잇다고 생각하게 되면, 심지어 바보 천치에게조차 별 볼일 없는 작품을 만들 확률이 더 높다.

디자인과 사용자 #2:
설령 똑똑한 사용자들을 위한 디자인을 한다고 해도 당신은 여전히 어떤 사람을 위한 디자인을 하고 있는 것이다. 그것은 연구와 다르다. 수학에서 추상적인 표현을 쓰는 이유는 그것이 사람에게 더 쉽게 이해되기 때문이 아니다. 과학에서 사용되는 아이디어는 인간공학적인 이유에서 선택된 것이 아니다.
하지만 예술은 다르다. 디자인은 항상 사람을 위해서 선택된다. 모든 예술은 사람의 관심사와 한계에 대해서 심사숙고 해야 한다. 르네상스 시절의 위대한 작품들이 사람의 모습으로 꽉 차 있는 것은 우연이 아니다. 그들이 사람을 그리지 않았더라면 오늘날과 같은 위신을 갖지 못했을 것이다.
원하건 원하지 않건 프로그래밍 언어 역시 사람을 위한 것이다. 언어라는 것은 완성된 프로그램을 위한 형식이 아니라, 프로그램 자체가 그 언어를 이용해서 사고되고 개발된다는 점을 기억할 필요가 있다. 예술을 아는 사람이라면 누구라도 서로 다른 두개의 상황에서는 각자 다른 매체를 이용하고 싶어할 것이다. 예를 들어 대리석은 완성된 아이디어를 표현하기 위한 훌륭한 재료이지만 새로운 아이디어 개발 면에서는 끔찍할 정도로 유연성이 부족한 매체가 된다.



주: 원문에 임의로 요약이나 생략이 들어갔음.
Creative Commons License

Posted by saber

2006/03/31 02:57 2006/03/31 02:57
, , , ,
Response
No Trackback , No Comment
RSS :
http://saberang.net/tc/rss/response/366

Trackback URL : http://saberang.net/tc/trackback/366

Leave a comment
[로그인][오픈아이디란?]
« Previous : 1 : ... 74 : 75 : 76 : 77 : 78 : 79 : 80 : 81 : 82 : ... 351 : Next »

블로그 이미지

- saber

Candle

Calendar

«   2009/01   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31