"해커와 화가" 내용 요약
2018년 06월 21일

  • 공부벌레는 왜 인기가 없을까
    • 그들은 게임판 위의 말에는 관심이 없다.
  • 해커와 화가
    • '해커'와 '엔지니어', '과학자'등 보다는 오히려 화가 등 창조적인 직업과 공통점이 많다.
  • 우리가 말할 수 없는 것
    • 쉽게 생각할 수 없는 것(파격적) 을 생각할 수 있도록 자신을 훈련시켜라. 그러한 생각을 자유자재로 할 수 있다면 흔히 혁신이라고 불리는 수준의 미미한 파격을 시도하는 것은 문제도 아닐 것이다.
    • 현재의 '유행', '터부' 등 지나서 보면 보이지만 현재는 보기 힘든 것들이 있다. 이러한 흐름을 거리를 두고 객관적으로 보는 노력을 해봐라.
  • 모범적인 '불량 태도'
  • 또 하나의 길
    • 데스크탑 -> 웹의 장점
      • 사용자 입장에서 사용 시 신경써야 할 것들이 줄어든다.
      • 릴리즈, 버전 개념이 따로 존재하지 않는다. 버그를 일찍 잡을 수 있다.
      • 에러를 쉽게 재현할 수 있으므로 고객 지원도 쉽다.
      • 즉각적으로 릴리즈가 가능하므로 개선하고 싶은 부분은 바로 실천 가능
      • 데스크탑 애플리케이션 개발은 결국 윈도우에게 도움을 줌, 웹은 유닉스에서 동작하는 소프트웨어가 곧 사용자에게 전달
  • 부자가 되는 법 / 차이에 대한 연구
    • 스타트업은 개체 수로 승부하는 모기와 같다.
    • 돈이 아니라 부를 창출해라. 부는 일정한 분량이 있는 것이 아니기 때문에 한 쪽에서 부를 창출한다고 다른 쪽 부가 적어지지 않는다. 돈은 부와 교환할 수 있는 매개체일 뿐이다.
    • 물론 100배의 돈을 받는다고 100배의 가치가 있는 것은 아니다. 하지만 스티브 잡스를 아무렇게나 선택된 100명의 사람들로 교체되면 애플의 다음 제품은 어떻게 될까? 차이는 애초에 선형으로 벌어지는게 아니다. 자유 시장에서 가격은 구매자가 원하는 바에 따라서 결정된다.
  • 스팸을 위한 계획
    • 스팸을 필터링 하는 법...
  • 창조자의 심미적 취향
    • 좋은 디자인은 시간에 구애받지 않는다. 미래의 세대에게 통하는 어떤걸 만드려면 이전 세대에게도 통할 만한 것을 만들어야 한다.
    • 좋은 디자인은 제대로 된 문제를 해결한다.
    • 좋은 디자인은 무언가를 제안한다. 마치 레고처럼
    • 좋은 디자인은 조금 우습기도 하다. 유머감각이 있다는 것은 힘과 확신이 있다는 것
    • 좋은 디자인은 어렵다. 하지만 좋은 디자인은 간단해 보인다.
    • 좋은 디자인은 대칭을 이용한다.
    • 좋은 디자인은 자연을 닮았다. 자연을 흉내내는 것은 공학에서도 통하는 방법이다.
    • 좋은 디자인은 무언가를 다시 디자인하는 것이다. 작품을 내다 버리는 것은 확신을 요구하고, 불만족이 가진 뿌리를 깊이 파고드는 것이다.
    • 좋은 디자인은 복사가 가능하다.
    • 좋은 디자인은 이상할 때도 있다. 기묘한 경향이 엿보이기 시작했을 때 억누르지 않는다.
    • 좋은 디자인은 뛰어난 사람들의 모임에서 나온다. 15세기 피렌체처럼.
    • 좋은 디자인은 종종 대담하다.
  • 프로그래밍 언어에 대한 설명
    • 언어의 전쟁
      • 정적/동적 타이핑 -> 정답은 없다.
      • 객체지향 -> 도입 정도의 차이
    • 현대 시대는 프로그래밍 언어의 르네상스
  • 100년 후의 프로그래밍 언어
    • 100년 뒤는 컴퓨터가 어떻게 만들어지는 지금보다 훨씬 빠르게 작동할 것. 속도보다는 편리한 언어가 대세가 될 가능성이 높다.
  • 평균 뛰어넘기
    • 스타트업은 그저 그런 평균정도 하면 무조건 망한다.
    • 다른 회사에서 C로 이용해 개발할 때 대신 리스프를 도입한 사례 소개
  • 공부벌레의 역습
    • LISP가 좋다.
  • 꿈의 언어
    • 성공한 언어는 어떤 장점을 지녔나 보다는 해커들이 좋아하냐에 달렸다
    • 엉뚱한 짓을 막는 건 뻔뻔한 생각이다. 무능한 사람은 어떤 경우라도 제 발등에 도끼를 찍는다.
    • 깨끗하면서 더러워야 한다. 쉽게 이해되는 핵심과 그에 상응하는 연산자 등 깔끔하게 설계되어야 하지만, 그와 동시에 해커들이 마음껏 가지고 놀 수 있을 만큼 적당히 지저분하기도 해야한다.
    • 언어가 '일회용 프로그램'을 만들기 적합해야 한다. 역설적이지만 큰 프로그램에 적절한 언어를 만들고 싶으면 먼저 일회용 프로그램을 작성할때 알맞은 프로그램을 만들 필요가 있다.
    • 빠르게 작성 후 최적화하고 싶으면 관심을 어느 곳에 집중해야 하는지 알려주는 훌륭한 프로파일러가 존재한다. 원한다면 인라인 바이트코드도 작성 가능.
    • 정적/동적 타입, 객체적/기능적이 중요한게 아니라 훌륭한 라이브러리를 어떻게 작성할 수 있냐 에 달렸다.
    • 빠른 속도는 물론 중요하다. 하지만 속도라는 것은 일부 중요한 병목 지점에서만 문제가 될 뿐이다.
    • 엔드 유저가 느끼는 속도의 본질은 상황에 따라 변할 수 있다. 서버 기반 애플리케이션이 대세가 되어감에 따라 I/O가 중요해지는 등.
    • 설계시 초보의 확신과 베테랑이 품는 회의감을 동시에 가지고 있어야 한다.
    • 반드시 그래야 할 필요가 없는데 숨어 있는 내용은 없다. 추상화는 오로지 당신의 일을 절약해 주기 위한 목적으로만 제공한다.
  • 디자인과 연구
    • 디자인은 좀 더 사용자에게 관심을 기울인다. 사용자에게 부응한다는 것이 사용자가 말하는대로 따라한다는 건 아니다. 사용자는 대개 잘 알지 못하므로, 환자가 아픈 증상을 말하면 무엇이 잘못됬는지 알아내는 의사처럼 접근해야 한다.
    • 목표로 삼은 사용자 안에 자신이 포함되어 있으면 좋은 디자인이 나온다. 예를 들어 C, 리스프는 설계자들이 직접 사용하려고 만든 언어이다. 이에 비해 자바 등은 다른 사람 더러 사용하라고 만든 언어다. 당신이 바보를 위해서 무언가를 만들면 바보도 사용못하는 작품이 나온다.
    • 프로그래밍 언어도 결국 사람을 위한 것. 언어라는 것이 완성된 프로그램을 위한 형식이 아니라, 프로그램 자체가 그 언어를 이용해서 사고하고 개발된다.
    • 프로토타입을 빠르게 만든 후 수정하라는 원리는 사실 예술에서 따왔다. 제대로 된 큰 윤곽을 빠르게 대충 그린 다음 이 스케치를 천천히 다듬는다. "화가가 작품을 완성하는 경우는 없다. 단지 그는 작업을 멈출 뿐이다."