왜 그동안의 함수식 언어 홍보는 잘못됐는가?

그렇다. 함수식 프로그래밍과 그것을 포함하는 “선언식 프로그래밍” [1] 은 그동안 이른바 산업 프로그래밍과 산업 프로그래밍 언어의 혁신요소들의 주요 원천 중 하나였다[2]. 하지만 그동안의 함수식 언어 홍보에서는 중요한 오류들을 범했다.

예를 들어 함수식 에반젤리스트들은 아래와 같은 광고어들을 내세웠었다.

“함수식 언어에서 변수는 값이 바뀔 수 없어요. 그리고 이게 좋아요. 버그를 막아주니까.”

이걸 듣는 사람들의 반응은 아마도 당장 발이 묶인 느낌일 것이다. 그래서 “그러면 코딩을 어떻게 해요?” 라고 묻는다면, 이런 대답이 올 것이다. “변수 변경이 정말 필요할 때는 변경할 수도 있어요. 그리고 함수식 프로그래밍에서는 꼬리 재귀를 사용하지요.” 그러면서 아마도 계승(factorial)이나 피보나치 예제를 주머니에서 꺼낼 것이다.

이렇게 되면 프로그래머는 아마도 고개를 갸우뚱 하며 (말은 하지 않고) 생각할 것이다.

“그렇게 되면 어차피 명령식에서랑 똑같이 변하는 변수를 사용하지 않을까? 과연 참고 변수를 변하지 않게 사용할 수 있을까?”

“그리고 나는 일할 때 매일 계승을 짜진 않는단 말야..흠..”

Continue reading

프로그래밍 바벨탑 해결

Python 을 Go 로 번역해주는 트랜스컴파일러:

https://github.com/google/grumpy

Python 을 Go 로 트랜스컴파일한다는 것은 무엇을 의미하는가, Python이 최정적으로 네이티브 컴파일 됨을 의미합니다..

저는 어제 이 리포의 별수가 실시간으로 오르는 걸 보았습니다. 오늘은 어제 대비 별표가 많이 늘어났더라구요.

이런 갓 프로젝트를 누가 만들었나 했더니 갓 Google 님이 만들었더라구요.

이게 좀더 성숙해지면 구글은 python 으로 짜여진 유튜브를 네이티브 프로그램으로 서비스 하겠네요.

자 그러면 앞으로 이런 식으로 프로그래밍 바벨탑들이 다 해결 될 것인가?

 


하스스톤 역기획 해 python 코딩하는 알파고:

http://kotaku.com/google-deepmind-is-now-analysing-magic-and-hearthstone-1767628685

프로그래머들을 아예 다 해치울지도..? ㅋㅋㅋ

2016회고: 같은 성형외과 나온 프로그래밍 언어들

내 언어의 경계는 내 세계의 극한이다 — 루트비히 비트겐슈타인 <논리철학 논고> [1] (5.6)

프로그래밍 언어는 빠르게 발전한다 — 적어도 빠르게 변화한다. 한때 유행했던 Delphi 나 한때는 쿨하다고 여겨졌는 Perl 이 오늘날 이토록 사람들로부터 외면 받을 줄은 그때 당시는 상상하기도 어려웠던 것처럼[2]. 2016 년에도 프로그래밍 언어는 1년어치 뉴스를 듬뿍 채울 만큼 착실하게 발전했다. 뜻인즉 프로그래머들의 식후 티타임 화제를 옹근 2016년 한해만큼 제공하기에 충분한 분량을 채울 만큼 확실하고 견고하게 발자국을 내디뎠다는 말이다. 원한다면 프로그래밍 언어 2류 관찰가의 시선을 따라 2016년의 프로그래밍 언어를 회고해보자. (일부 특성들은 사실 2016년에 추가된게 아니다, 엄밀히 따지자면. 하지만 그게 2016년에야 각광받았다면 2016년의 뉴스로 치부할 수도 있을 것이다)

2016 년 “올해의 프로그래밍 언어”

프로그래밍 언어 유행지수를 발표하는 것으로 프로그래밍 커뮤니티에서 유명한 TIOBE 가 곧 2016년 “올해의 프로그래밍 언어” (Programming language of the year 2016) 를 발표할 예정이다. 이 영광을 차지할 언어는 Go 언어가 거의 확정이다 [3]. 원인은 1개 퍼센트 포인트 이상의 유행도 상승을 보여준 프로그래밍 언어가 Go 와 Groovy 밖에 없는데, Groovy는 이미 과거형으로 되었기 때문이다.

Google이라는 명문 출신, C언어의 아버지와 UNIX의 아버지가 만든, 대규모 동시성 프로그래밍을 위해 태어났다는 슬로건, 등등 태그들을 달고, 프로그래밍 언어들이 혈전고투로 어려워하는 와중에 Go 언어는 자기만의 길을 개척해 유행도를 얻고 있다. 또한 컨테이너 프로그램 Docker 가 점점 일반 가정에 까지 들어설 만큼 유행해진 것이 그것의 개발 언어 Go가 나날이 주목받는데 일조를 하는 것 같다.

JetBrains 도 이런 배경에서였는지, Go언어 IDE 프리뷰 버전(현재 이름: Gogland)을 내놓았다. 성숙한 IDE는 Go 생태계의 빠른 성장에도 큰 도움이 될 것 같다.

Async/Await 유행년

2016 년을 감히 Async/Await 의 해라고 부르겠다. 2016 년에 뭐가 가장 핫했냐고 물어본다면 당근 Async/Await 이겠으니. Continue reading

Linux 버전의 PowerShell?

마이크로소프트에서 최근에 PowerShell 로 CMD 를 대체하려 한다는 뉴스와 함께, 마소가 PowerShell 을 Linux 로도 포팅했다는 소식이 소개되면서 PowerShell 과 유닉스 파이프에 대한 토론이 있었습니다.

그것에 대해 적었던 내용들을 포스팅 합니다.

유닉스 철학의 포인트들중 일부: 바이너리 헤이터, 텍스트 성애자. 그것도 플랫하고 멍청한(KISS) 텍스트를.

McIlroy, the head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe, summarized the Unix philosophy as follows[1]:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

약간 유사한 예가 아닐까 하는게, 우리가 매일 짜는 프로그램들을 예로, 프로그램은 신택스적으로 괴앵장히 구조화된 예술품이지만, 우리는 오직 플랫한 텍스트 파일로만 컴파일러와 대화를 하죠.

Continue reading

프로그래밍의 특급 비밀

coolspeed

This book has a lot of knowledge in it, but it is mainly about expertise. It is going to try to teach you the things about Unix development that Unix experts know, but aren’t aware that they know.
– Eric S. Raymond, “The Art Of UNIX Programming”

벤처캐피탈 업계에는 이런 역학이 존재합니다: 최고로 잘한 투자는 수익이 나머지 모든 투자 수익의 합보다 많다. 나머지중 최고로 잘한 투자는 나머지 모든 투자 수익의 합보다 많다.

프로그래밍에도 비슷한 역학이 존재합니다.
프로그램은 90%의 실행시간을 10%의 코드 실행에 소모합니다.[1]

이것을 통해 우리는 놀라운 추론을 해낼 수 있습니다.
시스템을 성능이 낮지만 생산성이 좋은 언어로 짜고, 그중 10% 의 핫스팟만 찾아내 C++ 로 짜면 끝.

실제로 (일부) 천재 프로그래머들은 시스템을 어떻게 설계했을까요?

1. YouTube

검색창은 Go 프로그램. 웹 애플리케이션 서버는 느린 Python 으로 짰습니다.

2. GitHub

“GitHub” 의 “Hub” 은 느린 Ruby on Rails 이고, “Git” 은 C.

3. Instagram

사진 저장은 Amazon S3 (네이티브 코드 예상). 웹 프런트는 C코드 (NginX). 데이터베이스는 C (PostgreSQL).
웹 애플리케이션 서버는 Django (Python).

4. Uber

DB: C++(MySQL)
Index: C (Redis)
애플리케이션: Javascript

Continue reading

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