Kotlin언어 성공사례: Corda 블록체인(by R3)

Kotlin언어? 뭔 듣보잡? 성공사례가 있니?

찾아보니 있다.

corda_kotlin.png

CTO는 전 구글 시니어 엔지니어였다고 한다. CTO분이 얘기하신 Kotlin 선택 원인:

  1. 정적 타이핑 (그러고 보니 밀레니얼 세대 언어는 다 그런 것 같다)
  2. Java가 비즈니스 월드에서 중요해서. (하긴)
  3. 섹시해서 (구닥다리 Java랑 비교하니 그렇지)
  4. 배우기 쉬워서 그래서 구인이 쉬워서 (보통 Java구인을 하고 1~3일 트레이닝 시키면 코틀린 언어 코딩을 할 수 있다고 한다)
  5. IDE지원 잘되서
  6. 컴파일 속도가 빨라서 (Scala 저격하며)
  7. 문서화가 잘돼있어서
  8. 내가 할줄 알아서. 내가 좀 해봤는데 재밌어서

그러면서 하는 말이 Kotlin이 없었다면 Scala 썼을 것이라 한다.

마지막에 내린 결론이: 잘한 것 같다.


 

개인적으로 Kotlin이 정말 반갑다. JVM팬으로서 항상 언어가 아쉬웠는데, Java는 구닥다리고, Scala는 너무 복잡하고* Groovy는 언어가 아쉽고, (Scala 와 Groovy공통점이 모두 창립자가 포기했다는 점..) Clojure는 대중성을 전혀 염두에 두지 않은 것 같고. 그런 점에서 Kotlin은 JVM에게 복음과도 같았다.

특히 실행 가능한 환경이  JVM / Javascript VM / Native 로 다양해서 플랫폼에 발목 잡히는 일이 없도록 했다는 점도 칭찬하고 싶다. (마이크로소프트가 최근에야 터득한 점)

JVM, V8엔진, 네이티브 세가지 모두 점점 중요해지는 플랫폼인 것 같다. 아 WASM(Web Assembly)까지 지원하면 더욱 좋겠지만. 이게 미래가 될 수도 있으니. 걱정할 필요가 없는게 컴파일러 플랫폼이 LLVM이어서 WASM이 GC만 지원하면 WASM으로 컴파일 하는 것도 식은 죽 먹기일 거라는 점.

최근 홍민희님의 PyConKr 2017 발표 <파이썬과 다이아스포라>를 보고, 최근에 읽은 <사피엔스>와 결부해서 느낀 점이: 성공한 언어들은 모두 대중성을 키 피처로 치밀하게 기획된 것 같다는 점이다. 민족의 용광로처럼 말이다. (적어도 대량 전파됨을 성공의 척도로 본다면 그렇다)

심지어 Rust도 너무 결백증스러운 면이 있어서 대중성이 의심스럽다.

다행히 Kotlin은 대중성을 키 피처로 설계된 듯하다. 그것의 일환으로 Java월드 레거시에 대한 포용성도 잘 설계된 것 같다.

미래가 지켜볼만하지 않은가!

* 참고로 R3 Corda의 경쟁상대인 IBM hyperledger fabric 은 Go언어로 만들었다.

부록

* TIOBE 프로그래밍 언어 유행도 인덱스에 따르면 Scala는 D언어나 COBOL언어보다 인기가 적다: https://www.tiobe.com/tiobe-index/

 

Advertisements

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

그렇다. 함수식 프로그래밍과 그것을 포함하는 “선언식 프로그래밍” [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