AST diff? – 홍민희의 트윗글로부터

홍민희트윗글에서 본 내용인데:

텍스트 파일로 쓰인 소스 코드는 AST의 직렬화일 뿐인데 그걸 왜 사람이 편집하냐, 편집기가 AST 자체를 다루면 되지 않냐는 얘기는 전부터 많았다.

그런데 Rust 쪽의 “언어 생소함 예산” 관점에 따르면 새로운 언어는 혁신하려는 아주 적은 양의 생소함만을 지니고 있지 않으면 진입 장벽 때문에 사람들이 외면해서 망해버린다.
http://words.steveklabnik.com/the-language-strangeness-budget

따라서 AST 수준에서 편집하는 편집기와 언어라는 개념을 실현시키려면, 딱 그 아이디어 말고 다른 부분에서는 혁신을 포기해서 원포인트 혁신을 한 뒤에, 다른 종류의 혁신은 이후의 다른 언어에게 양보해야 한다.

그런데 애초에 그런 아이디어에 매료된 사람들은 야심이 있는 사람들이기 때문에 보통은 이것저것 평소에 프로그래밍 세상에 있던 불만들에 대한 아이디어를 다함께 버무려서 일거에 많은 것을 혁신하고 싶어하기도 한다. 그러면 망하는 지름길…

그런 반면 “코딩 스타일 차이로 인한 어려움”은 혁신의 어려움에 비해서 불편함은 다른 언어적 불편에 비하면 사소한 수준이라 그럭저럭 참고 쓸 수 있고. 그래서 나는 똑똑한 사람들의 “야심의 방향”으로 삼기에 작은 목표라서 혁신이 잘 안된다고 생각.

나는 AST 편집기라는 아이디어보다는 차라리 AST diff 아이디어가 더 불편한 것을 직접적으로 고치는 방식이고 퍼뜨리기도 비교적 쉽기 때문에 훨씬 먼저 달성되지 않을까 기대한다.

그러고 나면 각자 개발 환경에서 각자 취향대로 소스 코드를 포매팅하고 살아도 서식 문제로 버전 관리 시스템에서 충돌이 나지 않게 되기 때문에 점차 코딩 스타일의 차이 자체가 큰 문제가 되지 않는 방향으로 문화가 흐르지 않을지.

처음엔 격하게 공감했는데, 다시 생각해보니 문제점이 있었다.

텍스트 diff 가 쉬운 원인은 텍스트가 어의(Syntax)상으로는  구조가 있을지 몰라도 형식상으로는 리니얼하기 때문이다(다시말해 직렬화 되어있기 때문이다). AST 로 되어버리면 비교가 어려운 일이 된다.

비교가 됐다고 한들 diff 내용을 보여주기 위해서는 또 직렬화가 필요하다. 물론 직접 벡터 그림으로 보여주는 방법도 있지만, 요즘은 벡터 그림도 다 텍스트로 표현하지 않는가 – SVG, Graphviz, PostScript, Processing, etc. (PDF 는 잘 모름.) 게다가 모든 것을 CLI / TLI 에서 하는 Emacs 파(Linus Torvalds)도 고려되어야 한다. Visual Studio 식의 툴인들, 내부적으로는 텍스트로 표현할게 아닌가(Visual Studio 의 프로젝트 파일이 XML 이듯이). 어쨌거나 이 다시 직렬화 해야 하는 문제는 그냥 하면 된다. 큰 문제가 아니긴 하다.

내가 생각해낸 아이디어

Continue reading

Python 을 사용하는 대기업들 지금은 어떻게 됐을까?

Google

Google 얘기는 빼놓을 수 없다. Python 언어의 발명자 Guido van Rossum 도 구글에 계시기 때문이다.

Google 은 Python 을 좋아하다가, Go 언어를 만들었다.

특히 Python 언어의 플래그쉽같은 존재였던 YouTube, 아직도 Python 인걸로 알고 있다. 하지만 YouTube 의 검색창의 모든 검색은 Go 언어로 구현된 프로그램을 통해 일어난다고 한다. (프록시만 하는지, 구현까지 하는지는 잘 모르겠지만, 구현이야 당연히 구글의 기존 C++ 프로그램이겠지 싶다) [1]

dl.google.com 이 Go 언어로 만들어졌다고 한다. Chrome 의 압축 프록시가 Go 언어로 구현되었다고 한다. [1]

Dropbox

Dropbox 는 빠른 Python 구현인 Pyston 을 개발하다가, 이미 구현된 빠른 Python 인 PyPy 를 만지작거리다가.. 결국 Go 언어로 갈아탔다. [7]

Uber

오래되진 않았지만, 요즘은 Uber 이야말로 핫하다고 할 수 있지 않은가. 성능 크리티클한 부분을 Go 로 만들었다. (Node.js 를 고려하다가 Go 를 선택했다고 함.) [2]

Pinterest

Gevent 로 Python 을 빠르게 하다가 [3], Elixir 로 갈아탔다. [4]

참고로 Pinterest 는 MAU (Monthly Active Users) 가 1 억에 달한다고 한다. [5]

Alexa 에 의하면 Pinterest 는 Netflix.com 보다 트래픽이 많다고 한다. [6]

여담

여담으로 Ruby on Rails 로 시작한걸로 유명한 Twitter 는 Scala 로 갈아탔고, GitHub 은 음 잘 모르겠는데 아직도 Ruby on Rails 인가..?

여담중의 여담으로 Elixir 은 Ruby on Rails 핵심 커미터였던 개발자가 Ruby 로 컨커런시 처리하는 것에 지쳐서 Erlang 으로 돌아선 것이라고 한다.

결론

결론은 반전이다. YouTube 도 Python 으로 만드는데, Python 이 너무 느리게 느껴질 정도로 성공하는 서비스부터 만들고 보자. 그때까지 언어 성능은 별로 중요하지 않다.

Continue reading