사놓고 쓸 일도 없고 방치해두고 있었는데 evernote가 되려나 하는 생각이 들어서 찾아보니 os 3.0이어야한다고. 그래서 해킹해봤다.

탈옥(해킹) 방법 자체는 readwriteweb에도 잘 정리돼있고, 검색하면 한글로 된 정보도 꽤 있는 듯.

핵심은 3가지. 3.0펌웨어, Redsn0w, DFU모드. 이 세 가지면 잘 하면 된다.

3.0펌웨어는 사던지, iPod2,1_3.0_7A341_Restore.ipsw(아이팟 터치 2세대용)라는 파일을 구하면 된다. 가능하면 사는 게 좋다. 돈도 돈이지만 원칙적으로는 안전 문제.

Redsn0w는 여기에서. 가능하면 비트토런트 공식 릴리즈로. 미러사이트 이용하지 않는 것도 원칙적으로는 안전 문제. 여담이지만 SHA1 SUMS 이런 거는 파일이 실제 공개된 파일과 같은 지 확인하는데 쓰인다. 실제로 성격 더러운(???) 분들은 미러 사이트는 죽어도 안 쓰고, 이런 식으로 확인 안 되는 프로그램은 깔지도 않는다고 한다. 어떤 프로그램이든.

DFU모드는 Redsn0w 설치중에도 설명해주는데, 간단히 설명해보면, 아이팟을 꺼놓은 상태에서, 전원버튼을 누르고 있으면 아이팟이 켜진다. 잠깐 더 누르고 있다가, 전원버튼은 그대로 누른 채로 홈버튼을 누르고 있는다. 이렇게 5~6초 정도 있으면 아이팟이 꺼진다(혹은 그렇게 보인다). 그 상태에서 잠시 더 그렇게 누르고 있다가 홈버튼은 그대로 누르고 있고 전원버튼은 손을 땐다. 그렇게 10초 정도 누르고 있으면 윈도우에서 usb가 다시 연결되는 효과음이 나는데, 그럼 DFU모드 준비 완료. 해보면 쉽다.

그 외에 libusb 깔아야한다는 글도 봤는데 잘 모르겠다. 없어도 과정 자체는 잘 되고, 대부분의 글에서는 그 부분에 대한 설명도 없다. 아마도 DFU모드를 확인하기 위한 용도가 아닐까 싶다. 근데 libusb 자체가 좀 위험한 면이 있는 게, 어쩌다가(?) 절전모드 할 때 블루스크린 뜨는 현상이 생긴다. 예전에도 이것 때문에 꽤나 고생했던 기억이 있는데, 왜 고생이냐면, 뭐가 문제를 일으킨 건지 알 수가 없다. 며칠간 고민하다가 libusb라는 걸 확인. 해결방법은 의외로 간단했는데, 지우면 된다.

어쨌거나 그런데 한 번에 안 됐다.

2.2.1 상태에서 시도했는데 계속 먹통. 근데 이거 자체는 별 문제 안 되는 게, 다시 DFU모드나 리커버리 모드로 들어간 다음에 아이튠즈 실행해서 복구하면 그만. 보장한다는 게 아니라 나는 그랬다는 얘기. 실제로 탈옥 과정에서 Redsn0w 프로그램이 다운 되는 경우도 몇 번인가 있었는데(도대체 몇 번을 한 건지 ㅜㅡ), 아이팟 자체가 아예 먹통이 되는 경우는 없었다.

내 경우는 downloading jailbreak data라고 몇 분인가 떠있다가 그 상태에서 재부팅 되고, 리커버리 모드로 켜졌다. 여기서 잠김 상태로 켜져야 제대로 탈옥이 된 건데, 그냥 먹통 상태.

포기할까 하다가, 아예 아이튠즈의 복구 기능을 이용해서 3.0으로 미리 업그레이드하고 했더니 잘 됐다. 아이팟 같은 경우는 07월 17일 현재 최신 버전으로 그냥 복구하면 2.2.1이 설치되는데, 3.0으로 복구하려면 복구하라는 화면에서 복구 버튼을 shift 버튼을 누른 채로 클릭하고, 3.0펌웨어를 찾아서 선택해주면 된다. 그럼 알아서 3.0으로 업그레이드 된다. 그 다음에 Redsn0w으로 해킹했더니, downloading jailbreak data라는 거 다음에 파먹힌 파인애플 화면 나오고 이런저런 과정 진행되더니 잘 넘어갔다.

파먹힌 파인애플.... 파먹힌 사과.... 한 친구가 애플빠라는 얘기를 듣고 사과를 한 입 배어물고 선물해야 되나 진지하게 고민했다. 애플 모욕죄로 얻어맞을 지도.

     •
     •


†

그 외에 여담.

cydia로 dvorak 5 row 키보드 설치. 돌겠다... 안 돌아간다. ikeyex가 아직 지원 안 되는 듯. 애플, 왜 드보락 기본 지원 안 해주냐고요 ㅜㅡ.

     •

아이튠즈로 evernote 동기화. 무료어플이다. 테스트. 아이팟에서 쓰고 컴퓨터에서 확인. 오타까지 동기화해주는 센스. 오타는 빼고 동기화해주는 기능이 있으면 좋겠다... 다 좋은데 에버노트 3.0이 느리다. 한글 치면 버버버벅. 우씨 이거 치명적 ㅜㅡ

     •
     •


아무래도 좋은 얘기지만 cydia에서 루비하고 터미널 깔고 놀 수도 있다. 왜 그런 짓을 해야되는 거지? 그냥, 심심하니까!

     •

ftp로 접속하려면 openssh 설치해야됨.

†

그 외에 내가 알고있는 아이팟 조작.

꺼진 상태에서 전원버튼 길게 누르면 켜진다.
켜진 상태에서 전원버튼 누르면 잠금, 길게 누르면 종료 확인창이 뜬다.
전원버튼 + 홈버튼 함께 누르면 화면 캡쳐.
전원버튼 + 홈버튼 길게 누르고 있으면 재부팅
홈버튼 누르면 메인 화면(스프링 보드).
홈버튼 두 번 누르면, 작은 음악창.
아이콘 오래 누르고 있으면 흔들린다. 예쁘다. 단지 그런 이유.
그 외에 스프링보드 2페이지에서 아이콘 누른 상태에서 홈버튼 눌렀다 때면 안전모드 + 스프링보드 리로드 됐던 걸로 기억하는데 3.0에선 안 되는 듯.

DFU모드랑 리커버리 모드는 엄밀히는 다른 걸로 아는데 리커버리 어떻게 들어가는지 모르겠다.

†

거의(?) 다 잘 되고 나니 기쁜 마음도 들었는데,

이제 뭐하지..... 다 귀찮아. 죽어버릴 테야 ㅜㅡ.

프로그래밍에서는 추상화라는 말이 많이 쓰인다. 특히나 객체지향과 맞물려서 이 말은 정말 많이 쓰이는 것 같은데, 프로그래밍에 있어 추상화라는 단어가 객체지향과 특별히 큰 관계를 맺고 있느냐를 따지면, 그럴 수도 있고 그렇지 않을 수도 있다. 중요한 건 추상화라는 개념과 그 개념이 프로그래밍이라는 행위에 대해서 제시하는 문제다. 프로그래밍에 있어서 추상화란 어디에나 존재한다. 오히려 추상화를 얘기하기 위해서 객체지향을 얘기해서는 안 되는 걸지도 모르겠다. 객체지향은 그저 프로그래밍이라는 주제에 있어서 추상화라는 문제의식을 고스란히 반영한 형식적인 지원에 불과하기 때문이다.

추상화란 간단히 말하면 공통점을 뽑아내는 일이라고 할 수 있다. 이를 테면 수학은 추상화의 한 극을 보여준다. 산수와 수학의 차이, 즉 단순한 숫자 계산과 그러한 계산 자체를 추상화한 수학의 차이는 바로 여기에서 드러난다. 수학이 왜 기호를 사용하는 지를 생각해보자. 예를 들어서 유명한 곱셈공식인 (x + y)(x - y) = x^2 - y^2이 된다는 공식이 있을 때 x와 y에 어떤 숫자를 집어넣어도 넣어도 이 식은 항상 성립한다. 그렇게 숫자를 집어넣었을 때, 이 공식은 아주 구상적으로 풀어지며 하나의 숫자를 내놓게 된다. 뒤집어서 말하면 그러한 구상적인 예들을 모으고 모아서 특징을 뽑아내 위와 같은 추상적인 공식을 만들었다고 할 수 있다. 단, 여기서는 단순히 특징을 뽑아냈다는 표현을 쓰지만, 수학에서는 수학의 방식에 따른 엄밀한 증명을 통해서 그것이 타당함을 밝힌다. 따라서 추상화된 공식은 모든 구상적인 사례들을 포함하고 있다고 할 수 있다.

특징을 추출해낸다는 건 바로 그런 일이다. 또 다른 예를 들면 블로그도 일종의 추상화툴이라고 할 수 있다. 인터넷은 웹페이지라는 HTML 문서로 이루어진다. 실제로 이 HTML 소스는 웹브라우저의 소스 보기라는 기능을 통해서 확인할 수가 있다. 만약에 우리가 100개의 웹페이지를 만든다고 한다면 100개의 온전한 HTML문서를 만들어야만 한다. 여기서 '온전한'이라는 단어에 주목해보자. 웹페이지는 결코 단순히 글만으로 이루어지지 않는다. 제목, 소주제, 네비게이션, 메뉴, 저작권 표시 간단하게만 따져봐도 이런 것들은 일반적으로 항상 포함되며, 이런 것들이 아니더라도 화면상에는 보이지 않지만 웹페이지 자체의 정보를 메타 데이터도 포함되게 된다. 하지만 생각해보면 알겠지만 이런 부분들은 일반적으로 항상 같다. 즉 100개의 웹페이지를 만들더라도 항상 반복적으로 사용되는 부분과 반복적으로 사용되지 않는 부분이 있다는 거다. 반복되지 않는 부분의 대표적인 경우는 '글'혹은 블로그스러운 표현을 쓰자면 포스트 자체에 해당한다.

블로그라는 툴은 글이 아닌 나머지 모든 부분을 추상화해서 하나의 폼으로 간직하고 있다. 이것은 블로그를 설정할 때 입력한 정보들이기도 하고 설정해둔 스킨이나 테마 자체이기도 하다. 그리고 그것은 불완전한 형태의 아직 구상화되지 않은 웹페이지가 된다. 그리고 여기에는 어떤 글이든지 담길 수 있으며, 그렇게 사용자가 입력하는 글과 합쳐져서 최종적인 즉 하나의 구상적인 웹페이지를 만들게 된다. 블로그라는 툴 덕분에 이제 100개의 온전한 HTML 문서를 만들 필요 없이 글만 써서 붙여넣으면 100개의 웹페이지가 만들어지는 것이다.

물론 여기에도 단점은 있다. 사실 그게 이 글에서 얘기하고 싶은 핵심이기도 한데, 추상화하는 대상이 항상 그래야만 하는 보장을 하기는 어렵다는 점이다. 예를 들어서 블로그를 하는데, 정말 어떤 한 포스트만(즉 하나의 웹페이지만) 다른 스킨과 결합시켜 꾸미고 싶다고 해보자. 그런 게 가능할까? 블로그 툴에 따라서는 가능할지도 모르겠지만, 일반적으로 그런 변화를 주기는 매우 까다롭다. 만약에 아예 HTML로 홈페이지를 만들었다고 한다면 이런 변화를 주기는 오히려 더 쉬운 일이었을 지도 모른다. 왜 이런 문제가 일어나는 걸까? 그건 '잘못된 추상화' 때문에 그렇다. 추상화해서는 안 되는 걸 추상화해버린 셈이다. 추상화란 앞서 말했듯이 특징을 추출하는 일이다. 그런데 애시당초에 사용하고 있는 스킨X가 있다고 할 때, 해당하는 블로그는 스킨 X에 맞춰서 추상화되어있다. 이는 바꿔말해 해당하는 블로그에 있는 모든 포스트(웹문서)는 그러한 특징을 가지고 있다고 가정하고 있다는 말이다. 즉 어떤 포스트에만 다른 스킨을 적용하려고 한다는 건 바로 그 전제를 깨뜨리는 셈이다. 이렇게 보면 블로그라는 툴이 얼마나 대담한 가정을 통해서 추상화라는 무기를 사용하고 있는지를 알 수 있다.

†

추상화라는 말은 사실 여러가지 측면에서 사용되지만 본질은 항상 같다. 공통점 뽑아내기. 추상화라는 단어와 자주 얘기되지는 않지만, 프로그래밍을 배우는데 가장 배우는 요소 중 하나인 변수 역시 이러한 추상화라는 주제에서 결코 벗어나지 않는다. 위에서 수학의 예를 들었는데, 수학의 예만 생각해보더라도 변수라는 게 추상화에 있어서 얼마나 중요한 요소인지는 새삼 말할 필요도 없을 것이다. 그리고 그렇기 때문에 변수가 단순히 어떤 요소를 담고 있는 상자라고 말하는 것은 반은 맞고 반은 틀리다.

물론 변수가 그런 상자가 맞기는 하다. 하지만 변수는 구상적인 요소를 추상적인 변수로 대치시켜버린다.



예를 들어 다음과 같은 대입문이 있다고 할 때, height라는 변수에 183라는 숫자가 들어가게 된다. 이제부터 height는 183와 같다. 그렇기 때문에 height와 183을 비교하면 참이라는 결과를 얻을 수 있을 것이다. height와 183는 그 값에 차이는, 하지만 진짜 문제는 이 둘의 추상화된 정도에 있다. 이렇게 써놓고 보면 이 주제가 별로 와닿지 않을지도 모르겠다. 다른 예를 들어보자.



여기에서는 두 가지 함수를 사용하고 있다. 먼저 date 함수는 차례대로 (년, 월, 일)을 인자로 받아서 "1999년 12월 25일"이라는 값을 돌려주는 함수라고 하자. 그리고 두 번째 box 함수는 (x 위치, y 위치, 너비, 높이)를 인자로 받아서 네모를 그려주는 함수라고 해보자.

여기서 우리는 아주 재미있는 걸 하나 발견할 수 있다. 정말로 아주 우연히도 일을 나타내는 인수 25와 너비를 나타내는 인수 25, 높이를 나타내는 인수 25가 같은 것이다!

앞서서 추상화란 공통점을 뽑아내는 것이라고 말했듯이 우리는 이제 이 숫자들을 하나로 변수를 통해 추상화해버릴 수 있다.



이 간단한 예에서도 확실하게 알 수 있지만 변수의 역할이란 틀림없이 추상화에 있다. 의미적으로는 각각 일, 너비, 높이를 나타내는 요소가 우연히도 수치적으로는 25라는 데 착안해서 25를 a로 추상화한 것이다. 위의 예와 아래의 예는 완전히 같은 결과를 출력해줄 것이다.

25는 완전히 구상적인 수치였다. 이 수치 자체는 완전히 구상적이다. 그리고 이 말은 다른 데 전혀 영향을 주지 않는다는 걸 의미한다. 이것은 위에서 얘기한 블로그와 홈페이지의 차이를 생각해보면 된다. 홈페이지는 완전히 구상적인 HTML 문서를 직접 일일히 만들게 된다. 그리고 각각의 HTML 문서들은 완전히 구상적인 결과물이라서 서로가 서로에게 어떠한 영향도 끼치지 않는다. 하지만 블로그의 경우는 어떤가? 스킨 하나를 가서 바꾸면, 블로그 제목이라도 바꾸면, 블로그를 통해 생성되는 모든 웹페이지에 영향을 주게 된다. 스킨이나 블로그 제목에 해당하는 부분은 블로그라는 툴을 통해서 추상화되어있기 때문이다.

여기서도 마찬가지다. 25라는 수치들은 우연히도 같기는 하지만 기본적으로는 독립적인 수치들이있다. 따라서 이렇게 말해져야 한다. 일에 25, 너비에 25, 높이에 25. 하지만 아래처럼 a라는 변수를 통해 25라는 수치가 추상화된 데서는 이렇게 말해져야한다. 일, 너비, 높이에 a라는 변수가 사용되었다. 가장 큰 차이는 앞의 경우는 각각의 25가 다른 25들에 아무런 영향없이 다른 값을 가질 수 있다는 점이다. 뒤의 경우는 그렇지 않다. a를 바꾸면 이 일과 너비와 높이는 전부 영향을 받게 된다.

예를 들어서 좀 더 큰 네모를 그리고 싶다고 해보자.



이렇게 프로그램을 수정하는 것은 매우 이상한 결과를 낳거나, 혹은 에러가 나게 될 것이다. 왜냐면 일의 범위는 일반적으로 1~31 사이에서 결정되기 때문이다. 우연히도 25로 같았던 요소들이 이제는 더 이상 같을 수 없게 돼버린 것이다. 이건 블로그의 예에서 얘기했던 잘못된 추상화와 근본적으로 같은 문제에 해당한다. 잘못된 이유는 간단하다. 추상화해서는 안 되는 것을 추상화해버렸기 때문이다. 높이와 너비를 추상화하는 데는 타당한 이유가 있을 수 있다. 높이와 너비가 같으면 그건 정사각형이 되기 때문이다. 하지만 높이와 너비와 일의 경우는 어떤가? 수치를 따졌을 때, 한 때 이 인자들은 같은 수치를 가졌다. 그런데 의미를 따지고 봤을 때 이러한 인자들은 추상화될 어떠한 필연성도 가지고 있지 않다.

변수명에 a를 써본 이유는 실제로 마땅한 이름이 없기 때문이다. 프로그래밍을 하는데 변수명을 잘 짓는 건 매우 중요한 습관을 꼽힌다. 실제로 좋은 변수명을 지을 수 없거나, 임시 변수명을 남발하게 되는 건 자신이 이 변수를 왜 쓰고 있는지 스스로에게 설명할 수 없다는 말이나 마찬가지인 셈이다. 특히나 제대로 추상화될 수 없는 것들을 추상화하려고 한다면 제대로된 이름을 지을 수 없는 것은 당연하다. 정사각형을 그리려는 목적에서라면 위의 a라는 변수명은 length로 대체될 수 있을 것이다. 하지만 3가지를 다 추상화하려는 경우라면 그것은 불가능하다.

본질적으로 잘못된 추상화가 추상화가 아닌 것은 아니다. 왜냐면 그 때는 25라는 수치 자체가 같은 것을 공통점으로 보고 추상화를 시도했기 때문이다. 분명히 공통된 특징을 뽑아내고 있다. 이걸 잘못됐다고 말하는 이유를 이해할 필요가 있다. 추상화를 하게되면 해당하는 요소들이 얽혀버린다는 거다. 그것들이 얽히는 데는 항상 타당한 이유가 필요하다. 리팩토링을 하는 데서는 반복이 많으면 그것을 치유되어야할 나쁜 냄새라고 말한다. 반복된 부분은 변수나 함수나 객체로서 추상화될 수 있다. 하지만 반복 자체가 잘못된 것은 전혀 아니다. 나쁜 냄새를 맡는 것은 중요하지만 그게 정말로 고쳐져야할 문제인지 아닌지를 판단하는 것 또한 중요하다. 거기에는 타당한 근거가 필요하다는 말이다. 이를 테면 앞서 말했듯이 너비와 높이를 추상화해서 하나의 수치를 적용하는 것은 정사각형을 만들기 위해서가 될 수 있다. 물론 이 경우도 정사각형을 만드려는 목적이 아니라면 잘못된 추상화라고 할 수 있다. 추상화란 결국에 어디까지나 정도의 문제 그리고 상황의 문제일 수밖에 없다.

†

변수가 구체적인 데이터를 추상화하는 거라면, 함수는 구체적인 처리과정을 추상화하는 걸 말한다.

†

25라는 걸 좀 더 생각해보자. 이것은 수치이다. 프로그래밍에서라면 일반적으로 int, 즉 정수에 해당하는 데이터타입을 가진 자료이다. 우리는 날도 숫자로 나타내고, 길이도 숫자로 나타낸다. 따라서 여기에서 숫자 타입을 쓰는 것은 타당해보인다. 하지만 표기에서는 닮아있지만 날을 나타내는 숫자는 우리가 일반적으로 알고 있는 정수의 특징과는 다른 특징들을 가지고 있다. 예를 들자면 달의 경우에는 1~12 사이의 정수만이 사용될 수 있고, 일의 경우에는 1~31 사이의 정수만이 사용될 수 있다. 여기서 필요한 게 추상 데이터 타입이다. 날을 나타내는 숫자에 대해 우리가 알고 있는 특징들을 종합해서 새로운 데이터 타입을 만들어버리는 거다. 일에 해당하는 Day라는 데이터 타입을 만들었다고 하자. 객체지향의 일반적인 방식대로 Day는 다음과 같이 생성한다고 하자.



이는 우리가 기본 데이터 타입인 정수 25를 사용한 경우와는 분명히 다르다. 주목해야할 점은 이 때 Day.new(25)와 25는 분명히 다른 요소이며, 따라서 하나의 변수로 추상화할 수 없다는 데 있다. 말하자면 이렇듯 추상 데이터 타입을 만들어 프로그래밍을 하는 방식이 객체지향 프로그래밍이고, 그런 기능들을 가지고 있는 언어를 객체지향 언어라고 한다. 물론 이렇게는 할 수 있을 것이다.



하지만 이는 Day라는 객체를 생성하는 과정에서 확실하게 에러가 날 것이다. 한참 위의 예 ㅡ date(1999, 12, a) ㅡ 에서 에러가 날 수 있다고 얘기한 것과는 조금 다른 얘기다. 왜냐면 date(1999, 12, a)의 경우에는 함수의 처리과정에서 에러가 나지만, date(1999, 12, Day.new(a)) 경우에는 Day라는 객체를 생성하는 과정에서 에러가 나기 때문이다. 전자의 경우 date 함수에 날자를 검증하는 알고리즘이 없다면 에러조차 나지 않을 것이다.

절차지향 언어(혹은 함수형 언어)에서는 변수와 함수만을 가지고 추상화를 하게 된다. 이는 매우 투박한 작업으로 좀 더 견고하고 셈세한 추상화를 하기 어려운데, 객체지향이란 객체라는 추상 데이터 타입을 통해서, 즉 데이터에 훨씬 더 견고한 정체성을 부여할 수 있게 함으로서 더욱더 견고한 추상화를 가능하게 해준다. 변수와 함수가 강력한 추상화의 무기라는 건 분명하지만, 그런 결과물들을 분류할 마땅한 방법을 제시해주지 않는다. 그 해결책이 바로 객체지향이라고 할 수 있다.

그게 아무리 복잡해보여도 하지만 본질은 변수를 통한 추상화와 하등 다를 게 없다. 추상화가 필요한 이유 역시 마찬가지고, 그리고 그러한 추상화가 타당한지를 검증하는 것도 마찬가지다. 객체지향이 중요한 게 아니라, 추상화라는 게 뭔지를 이해하는 게 중요한 거다. 그리고 분명 그건 프로그래밍을 구성하는 가장 기본적인 요소인 변수만 가지고도 이야기할 수 있지 않을까? 뭐, 변수가 데이터를 가리키는 메모리 주소의 추상화라거나 그런 얘기 말고...



John Maeda, 이런 분께 프로그래밍을 배웠어야 하는 건데!

음 근데 왜 루비는 lisp 계열로 분류되곤 하는 걸까.

잘은 모르겠지만, 함수형 언어가 함수형 언어라고 불리는 무엇보다 중요한 이유는 이유는 어떤 식을 평가하고 리턴 값만을 받아서 사용하기 때문이라고 한다, 아마도. 이런 방법의 좋은 점은 변수를 직접 조작하지 않아도 되고, 따라서 부작용이 없다고한다. 그래서 실제 변수의 값을 바꾸는 함수는 !를 붙여서 표시한다고 하는데, 이런 관습은 루비에서도 그대로 적용되고 있다. 에엑? 잠깐, 그말은??????



=>는 리턴값. Ruby에선 대입식이나 클래스 선언을 출력하는 이런 짓(??)이 된다.

참고로 gauche(lisp계열 언어인 scheme 인터프리터의 하나)에서 비슷한 걸 해보면,



루비랑 비슷하게 됨. 뭐, 거꾸로 말해야되겠지만. 이렇게 보면 리턴값하고 출력값이 구분이 안 되는데, 첫 문장에서 대입식의 a는 리턴값이다. 루비에서는 대입하는 내용이 돌려지는데, 여기서는 대입받는 변수가 돌려진다. 그리고 그 다음 문장에서 15는 (display a)의 출력값이고 x는 define 에서 돌려지는 리턴값이다. 그리고 x에 실제 대입된 값을 출력해보면 #<undef>가 뜨는데 아마도 nil 같은 게 아닐까 싶다. 어쨌거나 요는 리턴값이 있다는 얘기.



생각나서 파이썬에서도 비슷한 짓을 몇 가지를 해봤는데 다 에러가 난다. 이를 테면 대입문이 아무것도 돌려주지 않는다. 위에서 에러가 난 이유. 살짝 충격이다. 그리고 이전 글에서도 언급했지만, 그래서 파이썬에선 이 대입문을 조건문에 사용할 수 없다. 문법에서는 무지막지 닮아있기는 한데, 이렇게 또 보면 무지하게 다르지 않나 싶다. 추구하는 바가 다르달까. 루비에서는 대입연산자가 메서드여야만 했던 이유라거나 for 반복문을 빼버린 이유가 여기 있는 걸지도 모르겠다.

이걸 expression(식, 반환치를 가짐)과 statement(문장, 반환치를 가지지 않음)의 차이라고도 하는 듯. class 식에다가 puts 해놓는 예제를 보면 맨날 이런 거 어따가 쓰지 하는 생각을 했었는데.. 하하.

식은 바로 평가 가능하고, 문장은 반드시 덩어리로만 사용해야 한다. 루비에서 대입식은 정물 식이고, 파이썬에서는 대입문은 문인 셈. lisp에서는 모든 게 식이고, 루비에서는 (완벽하지는 않다는 것 같지만) 그런 특징을 이어받은... 건가? 대입 연산자도 식이고, 클래스 선언도 식이고, 제어구문도 식이고... 어째선지 루비에서는 문장으로 분류된 것들도 값을 가지는 듯...;

†

이런 걸 expression-oriented라고도 하는 듯. algol 68이나 lisp그리고 ruby가 그런 경우라고 한다. 함수 지향하고도 관련이 있는 특징 같은데 정말 그런 건지는 잘 모르겠다.

†

여담이지만, 그렇다고 ruby가 더 lisp스럽다는 건 아니고, Python for Lisp Programmers 이런 걸 보면 정말 크게 영향 받았다는 걸 알 수 있다. 말도 안 돼! 그 괄호 투성이 언어랑 이렇게 닮았다니!, 싶은. 신기하다.

심지어 스크립트 언어에 대해 이런 평가까지 있다고 한다. 이건 좀 ㅎㄷㄷ한 얘기 -_-;;;



같은 얘기를 전혀 다른 시점에서, 루비가 lisp에서 계승한 것이라는 마츠모토 씨 인터뷰에선 루비의 독특한 매력이 무려 8~9할은 lisp에서 왔다고 이야기하고 있다. 친절하게 영어 자막도 달려있다.