MIT에서 Scheme대신 Python으로 이전한 이유

전산쪽에서 근무하는 사람이라면 한번쯤 맞닥뜨리게될 책이 SICP이다.
이 책은 EE/CS(Eletrical Enginerring / Computer Science) 부문에서 1학년을 대상으로하는 교재였다. 이 기본 교재가 사용된 커리큘럼이 6.001 이었는데 이제는 6.01로 변경되면서 Python을 이용하고 있다.

이에 대해서 많은 이야기들이 있었지만, 최근 한 블로그에서 그에 관한 글이 실렸다.

거기서 한 부분을 살짝 발췌해보았다.

However, nowadays, a real engineer is given a big software library,with a 300-page manual that’s full of errors.  He’s also given a robot,whose exact behavior is extremely hard to characterize (what happenswhen a wheel slips?). The engineer must learn to perform scientificexperiments to find out how the software and hardware actually work, atleast enough to accomplish the job at hand.  Gerry pointed out that wemay not like it this way (”because we’re old fogies”), but that’s theway it is, and M.I.T. has to take that into account.

오늘 날, 실제 공학자는 300페이지에 달하는 에러투성이 메뉴얼이 포함된 방대한 소프트웨어 라이브러리를 제공받는다.또한,행동양식을 정확히 규정하기 어려운 로봇을  추가로 제공받는다. 공학자는 최소한 작업을 자유자재로 수행하기위해서는, 소프트웨어와 하드웨어가 실제로 어떻게 동작하는지 알아내기위한 과학적인 실험을 수행하는 법을 익혀야한다. Gerry는 우리가 이런 방식을 좋아하지 않겠지만, 현실이 그렇다는 것을 지적했고, MIT는 이를 고려한 것이다.

모든 것이 간단하고 분명했던 예전에 비해서, 현재 기술자들이 마주하는 현실은 확실히 복잡하고, 예측불가능하며, 하나의 완벽한 원칙을 통한 방식보다는 시행착오를 거쳐서 얻는 편이 더 간단한 시대가 되었다.
Scheme 이 만들어질 당시에는 정확힌 원칙을 토대로 만들어진 조각들을 하나하나 붙여서 만들면, 그것이 바로 솔루션이 되는 시대였다. 하지만, 시스템이 고도화되었고, 수많은 데이터들과, 복잡성이 자리를 잡은 시대에는, 한 사람의 프로그래머가 모든 시스템을 구성할 수 있는 시대와는 작별을 고해야했다.

다양한 방식의 라이브러리와 환경을 통합해나가야하는 상황에서 Scheme이 보여주었던 방식으로는 한계에 다달은 모양이다. 그 와중에 선택된 것이 Python 이다. 이유는 모르겠지만.. 아마도 커리큘럼 구성진이 실용적이면서도, 우아한 문법, 잘 정리된 라이브러리등에 점수를 주었는지도 모른다.

어쨌거나 6.001 이 더이상 유효한 커리큘럼이 아니라니 무척이나 아쉽다. 마이너한 언어를 다루는 사람에게는 더더욱 그렇다.. 음냠..

PS> 하지만 나처럼 혼자서 개발하는 사람에게는 그냥 그런가보다하는 생각뿐.... Python도 어느 정도 다루긴 하는데... 그놈의 탭인덴테이션은 내 취향이 아니라는 문제가... 그래서 Perl 을 계속하나부다...