Tcl/Tk 9.1

Tcl 특유의 기묘함과 동적인 문자열 중심 설계가 주는 장난스러움에 애착이 감. 업무에 쓰기는 조심스럽지만 재미로 갖고 놀기에는 정말 즐거운 언어임. upvar와 uplevel은 특히 대단함.
Python이 예비 배우자의 부모님을 처음 만날 때 점잖게 행동하는 느낌이라면, Tcl은 어릴 적 단짝과 둘만 아는 조금 위험한 놀이를 하는 느낌임.
Tcl/Tk는 라이브러리로서의 스크립트 언어를 개척했고, 스레딩도 제대로 설계함. 한 프로세스 주소 공간에서 독립적인 Tcl 인터프리터 여러 개를 실행하고 메시지를 주고받을 수 있음. 인터프리터 상태 전체가 전역 변수 없이 객체 안에 캡슐화되어 있어, 사용하는 쪽에서는 객체 포인터 하나만 다루면 됨.
GIL이나 직렬화·역직렬화가 필요 없고 프로세스 내부 메모리 복사만으로 충분하며, 불변 데이터라면 복사조차 필요 없음.

초기 Tcl의 가장 큰 매력은 Tk였음. 웹 프런트엔드가 없던 시절, 유닉스 계열과 X Window System에서 오픈 소스로 쓸 만한 GUI를 비교적 쉽게 만들 수 있었음. C로 쓰는 XView처럼 쉬운 편에 속하던 X 툴킷보다도 훨씬 간단했고, 다른 대안은 더 어려웠음.
Tcl 자체도 기존 유닉스의 Bourne 셸이나 C 셸과 달리, 진정한 문자열 기반 스크립트 언어라고 부를 만한 영리한 설계였음. 당시에는 C나 C++로 만든 큰 애플리케이션에 넣어 기능을 확장할 수 있는 몇 안 되는 내장형 확장 언어이기도 했음. 선택지는 작은 Lisp/Scheme, Tcl, Python, 아니면 독특하고 어설픈 자체 언어 정도였음.
닷컴 초기에는 Tcl을 백엔드에 쓰려는 관심이 상당했고, 브라우저에 넣었어도 나쁜 선택은 아니었을 것임. Python처럼 JavaScript보다 접근하기 쉽고 웹 개발의 문턱을 낮출 수 있었으며, 이미 탄탄한 설계와 구현도 존재했음.
Scheme은 Python이나 Tcl보다 조금 위압적이고 더 강력했는데, Tim Berners-Lee가 대중을 위한 웹 프로그래밍 언어로 Scheme보다 Python을 선호한 이유도 여기에 있다고 봄. 실제 JavaScript는 급조한 장난감 Scheme에 단순한 객체 모델과 시스템 프로그래밍에서 가져온 더 위압적인 문법을 붙인 것에 가까웠음.