[구인] Clojure 또는 Clojurescript 개발자를 찿습니다.

[Chris]

안녕하세요. 매번 눈팅만 하다가 이번기회에 Clojure를 가지고 온라인 게임 운영툴을 개발해보면 어떨가 생각하고 있습니다..
혹시 관심 있으신분은 chr...@blackspotent.com 로 연락 부탁 드립니다. 저희가 개발하고 있는게임의 소개는 저희 홈피를 대신 하도록 하겠습니다.

감사합니다.
www.blackspotent.com

[Manmyung Kim]

제 기억으로는 국내에서 Clojure로는 두 번째 구인모집이네요.

구인과 프로젝트가 잘 진행되어서 이런 기회가 점점 늘어나길 바래봅니다^^

[넷평]

웁스... 제가 놀고 있을때 이 공지를 봤어야하는건데.. ㅜㅜ

2015년 1월 24일 토요일 오전 11시 27분 8초 UTC+9, Chris 님의 말:

[Chris]

지금 당장이 아니고 나중에라도 혹시 관심있으신 분은 언제 던지 연락 주세요~

감사합니다.



2015년 1월 26일 월요일 오후 4시 23분 37초 UTC+9, 넷평 님의 말:

[KI-YOUNG BANG]

왜 운영툴로 clojure를 생각하시는지 여쭤봐도 될까요?
요즘 java 대안으로 scala나 groovy는 핫한데... clojure는 그리 환영을 못 받고 있거든요.

[Chris]

아.. 그런가요? 요즘 Clojure 에대한 관심이 떨어지는 추세인가보죠?
Clojure 로 개발 하려고 했던 이유는 다름이 아니라 Lisp에 매력을 많이 느껴서 입니다. Lisp은 거의 정체상태고 Clojure는 나른 떠오르는 샛별인줄 알았는데.. 앞으로 전망이 안 좋다면 다시 한번 생각 해 봐야 겠네요. ^^

2015년 1월 27일 화요일 오후 11시 46분 25초 UTC+9, KI-YOUNG BANG 님의 말:

[JUNG-LAE JO]

안녕하세요. 드문드문 클로저 관련 질문을 하던 사람입니다.
실운영 환경에 clojure, scala, groovy 를 이용한 개발을 몇 번 해 본 사용자로서 입장을 이야기 해봅니다. 마침 지금은 퇴직하고 쉬고 있거든요. ㅎㅎ 이전 회사가 작은 업체다 보니 제가 프로젝트의 사용되는 툴 결정권이 있었는데요, 엔터프라이즈급 규모가 아니었기에 큰 도움은 안될지도 모르겠습니다.
다른 것들 다 차치하더라도 scala, groovy 를 이용할 경우 java 는 필수적으로 따라가게 되는 게 마음에 들지 않았습니다. 오히려 코드가 관리가 안되는 느낌이고 low-level 동작은 결국 java 단에서 처리하게 되더군요. 웹을 예로 들면, 코어 기능은 모두 spring, hibernate 같은 기존 프레임웍에 의존하고 scala, groovy 같은 스크립트 언어는 비지니스 로직에서 flexible 하게 하고 싶을 때, 본인의 만족을 위해서 사용하는 기분이었습니다. 특별히 좋은 느낌이 없었어요.
반면, clojure, clojurescript 로 개발 했을 때는 산뜻한 기분이 들었습니다.
주관적인 장점을 열거해보면,
1. 가볍다.
 -여러 의미에서 가볍다는 이야기입니다. 코드 자체의 크기도 그렇고, 굳이 jrebel 같은 툴도 필요없고요.
 실제 처리루틴도 가벼울 수 밖에 없더군요. 한 예로, 커스텀 sub-protocol 을 헤더에 붙인 웹소켓 구현을 위해 spring 기반에서 groovy 를 써 만들다 한 없이 재정의 해야 하는 클래스에 지친적이 있습니다. 그 때 http-kit 으로 10줄 미만의 코드로 해결되었을 때의 기분이란.. spring 이 설계가 잘 된 프레임웍이라 하지만, 엄청난 차이였습니다.

2. clojurescript
 - 페이지의 상태를 이렇게 용이하게 추적 할 수 있다는 건 축복이었습니다.(reagent 라이브러리!)

3. 단일언어.
 - 다른 분들은 어떨지 모르겠지만 전 한 프로젝트 내에서 여러 syntax 가 얽힌 게 거슬리거든요.

퍼뜩 생각나는 건 이정도네요.
단점이 있다면, emacs 를 다른 IDE 만큼 다루지 못한다는 건데 이건 제 문제니까요. ㅎ
사족으로, clojure 를 계속 쓰면서 느낀건데 갈수록 애정이 가는 언어가 아닌가 싶습니다. 그래서 더 많이 사용되고 관련 구인도 많이 볼 수 있다면 좋겠네요. :)

2015년 1월 28일 오후 10:24, Chris <chri...@gmail.com>님이 작성:

--
이 메일은 Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 lisp-korea+...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 lisp-...@googlegroups.com에 이메일을 보내세요.
http://groups.google.com/group/lisp-korea에서 이 그룹을 방문하세요.

더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

[김영태]

http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/

위의 링크에는 GitHub repositories에 등록된 프로젝트들이 주로 어떤 언어들로 이루어져 있는가를 기준으로 평가한 프로그래밍 언어의 인기도를 측정한 결과를 담고 있습니다. 2014년의 프로그래밍 언어 선호도 조사 결과를 보면, Scala가 Clojure보다 인기도가 앞서고 있는 것은 사실입니다만, Clojure가 Groovy보다는 앞서고 있는 것으로 나타나고 있습니다. 그리고 그 상승과 하강도를 보면 Clojure가 가장 높은 상승세인 +5인 반면에 Scala와 Groovy는 둘 다 -2를 기록하고 있습니다. 위의 결과로 볼 때 현재 상황에서 Clojure가 프로그래머들에게 환영받고 있지 못하다는 결론은 다소 섣부른 듯이 보입니다.

다음의 제가 쓴 두 개의 글을 읽어 보시면, Clojure에 대한 이해에 도움이 될 수 있을 듯 합니다.  

https://groups.google.com/forum/#!searchin/lisp-korea/%EB%B3%80%EB%AA%85/lisp-korea/CkWgXTA9ymk/DKW-lx-uoR0J

https://groups.google.com/forum/#!search/authormsg$3Alisp-korea$2C0KhfrNAjbcsJ$20after$3A2013$2F8$2F1$20before$3A2013$2F9$2F1%7Csort:date%7Cspell:false/lisp-korea/sBfEoKI2fvw/26K25XL2JlAJ

프로그래머의 입장에서 볼 때, 고객을의 요구는 날로 복잡해지고 있습니다. 그로 인해 프로그램도 나날이 더더욱 복잡해지고 있습니다. 결국은 이 복잡도를 어떻게 낮출 것인가의 문제가 현재의 소프트업계가 당면한 가장 큰 화두이자 성패의 열쇠입니다.

이런 점에서 볼 때, Scala는 객체지향 방식과 함수형 언어의 특징을 모두 담고 있는데, 이러한 Multi-paradigm 전략은 장점으로 작용하기 보다는 단점으로 작용하기 쉽습니다. 절차지향도 결국은 State(멤버 변수)의 사용을 접근 지정자를 통해서 제어하고 있을 뿐, 본질적으로는 State를 적극 활용하는 프로그래밍 방식입니다. 그래서 함수형 언어 측에서는 객체지향을 절차지향과 크게 다르지 않은 부류로 취급합니다. 함수형 언어에서 State의 사용을 가능한 한 최소화하려는 이유는, 그럼으로써 프로그램의 복잡도가 줄어들어 유지/보수가 수얼해지기 때문입니다. 

객체지향에서는 클래스 간의 의존 관계가 발생할 때 그 관계를 어떻게 설정할 것인가의 문제도 엄청난 복잡성을 추가합니다. 의존하는 클래스가 늘어날수록 복잡도는 기하급수적으로 증가합니다. Clojure에는 그런 복잡성이 존재하지 않습니다. 왜냐구요? 클래스라는 개념 자체가 없는데, 클래스간의 관계를 고민해야할 필요가 있을까요? Clojure는 객체지향을 지원하지 않습니다. 객체 지향이 문제의 복잡도를 줄이기는 커녕 오히려 높이고 있는 원인으로 진단하고 있기 때문입니다. 그래서 Clojure에서는 데이터를 클래스로 감싸지 않습니다. 클래스로 감싸지 않고 데이터를 있는 그대로 이용합니다. 데이터를 클래스로 감싸게 되면서 코드는 길어지게 되고, 그로 인해 불필요한 복잡성이 증가하기 시작합니다. 예를 들어, 동일한 일을 수행하는데 10,000줄 짜리 코드와 1,000줄짜리 코드가 있다면, 당연히 짧은 코드가, 구현 로직의 이해나 유지/보수에 월등한 우월성을 지니게 되는 것은 자명합니다. 적어도 제 경험에 따르면, Java로 작성할 때보다 Clojure로 프로그래밍할 때 코드의 길이는 적어도 1/5, 크게는 1/10로 줄어듭니다. Java 프로그래밍할 때 제일 짜증나는 일이 gettter/setter만 작성했는데도 이미 코드는 수 백줄을 넘어가 있다는 것입니다. 가끔은 내가 지금 타이핑을 하고 있나 프로그래밍을 하고 있나 혼동이 들 정도입니다.

결론적으로 제가 말씀드리고 싶은 것은, 객체지향 프로그래밍 방식의 접근으로 인해 많은 문제가 발생하고 있다는 것을 있는 그대로 인정하자는 것입니다. 그래야 대안을 모색하기 시작할 수 있습니다. 그리고 그 대안을 찾아가는 과정에서, Clojure는 훌륭한 해결잭이 될 수 있는 언어라는 것입니다. 

2015년 1월 27일 화요일 오후 11시 46분 25초 UTC+9, KI-YOUNG BANG 님의 말:

왜 운영툴로 clojure를 생각하시는지 여쭤봐도 될까요?

[KI-YOUNG BANG]

일단... 제가 말씀드린 "환영 받지 못함"은 제가 일하는 곳에 국한 되었다는 점을 먼저 설명 드리지 못한 것 같습니다.

제가 일하는 곳은 국내에서 적당히 알려진 적당한 규모의 자체 프로젝트를 하는 회사인데...

현재까지도 주력 언어는 Java 입니다. 그런데 몇 년 전 부터 Scala 붐이 일어나기 시작하면서, 최근에는 신규 프로젝트는 Play로 하는 곳이 눈에 띄고 있습니다.

Groovy의 경우는 또, 회사에서 Spring 프레임워크를 주력으로 사용하면서 자연스럽게 노출되고 있는 듯 합니다. 하다못해 Gradle도 있으니...

반면, Clojure는 그 언어 존재 조차 모르는 분들이 많고, 제가 운영툴이라도 Clojure로 해보자고 했을때도 상당한 설득이 필요한 상황이었습니다. 그리고 설득하지 못했고요.^^

그저 소일거리로 혼자 하는 프로젝트 정도만 사용하는 수준입니다.

나름 밥아저씨 이름 팔아가면서 사내 커뮤니티를 만들어 봤지만, 스칼라에 비해서는 초라한 편이고요. 

이런 우물안 관점에서 말씀드린거니, 오해가 있으셨으면 사과드리겠습니다.

저도 다음 프로젝트는 어떻게 Clojure로 해 볼까 고민하는 상황에서 적어주신 글들이 많은 도움이 되었습니다. 고맙습니다.

2015년 1월 29일 목요일 오전 11시 31분 34초 UTC+9, 김영태 님의 말:

[Chris Kim]

안녕하세요.

메일 주소를 잘못 적으셨네요. ^^

제이메일 주소는 ch...@blackspotent.com  입니다.

감사합니다.

 

 

From: dongjin jung

Sent: Thursday, January 29, 2015 12:03 AM

To: lisp-...@googlegroups.com

Subject: [K-Lisper] Re: [구인] Clojure 또는 Clojurescript 개발자를 찿습니다.

 

안녕하세요. 클로저 구인광고를 보다니 신기하네요 :)

 

개인적으로 짧지만 클로저 경험이 있고, 구직중이라 관심이 가는데요.

 

좀 더 자세히 물어보고 싶어서 메일 보냈더니 모두 반송되네요;;

 

blcakspotent닷컴에 메일 전송이 안된데요.

 

위 메일 말고 다른 메일 주소를 알 수 있을까요? ;;

 

 

--
이 메일은 Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹의 주제에 가입한 분들에게 전송되는 메시지입니다.
이 주제에서 탈퇴하려면 https://groups.google.com/d/topic/lisp-korea/i4FJXX143jw/unsubscribe을(를) 방문하세요.
이 그룹 및 그룹의 모든 주제에서 탈퇴하려면 lisp-korea+...@googlegroups.com에 이메일을 보내세요.

이 그룹에 게시하려면 lisp-...@googlegroups.com에 이메일을 보내세요.
http://groups.google.com/group/lisp-korea에서 이 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[박영식]

리스크가 있었네요. 어쿠쿠 ㅎ

2015. 1. 29. 오후 5:26에 "Chris Kim" <chri...@gmail.com>님이 작성:

이 메일은 Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹에 가입한 분들에게 전송되는 메시지입니다.

이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 lisp-korea+...@googlegroups.com에 이메일을 보내세요.

[Chris]

안녕하세요. 답변 감사드립니다.
지난 며칠 동안 이것 저것 살펴보고 있는데 지금까지 전반 적인 느낌은 이렇습니다.
Clojure에 관련된 자료를 검색해보면 대부분 2012 전후의 자료가 대부분이고 2014년도는 특별한 이슈가 없었던것 같습니다.
초기의 반짝 관심후 모멘텀을 잃고 Lisp의 또다른 dialect로 전락되는건 아닌지..
앞으로의 로드맵을 찾아 보려고 했지만 별다른 소득은 없었습니다.
저보다 많은 지식을 가지고 계시는 분께 앞으로 전망에 대해서 여쭤봅니다.

말이 나온김에 Clojure 관련 몇가지 질문을 드리고 싶습니다.
지금 당장 온라인 게임 운영툴을 개발 하려는데, UI 는 어떤걸 써야하나 고민에 빠졌습니다.

1. JavaFX가 Swing을 대채한다고 되있던데, 기왕이면 최신 UI Framework를 쓰고 싶지만 Clojure JavaFX 래퍼 프로젝트는 이제 시작하는것 같고, Seesaw 를 가지고 해야할까요? 추천할만한 UI toolkit이 있으면 부탁드립니다.  (오늘 테스트중 seesaw로 간단한 윈도우를 띄우고 종료하면 emacs 에서 nrepl connection 이 끊깁니다. 혹시 뭣 때문에 그런지... Java, Cider, Clojure, Seesaw 모두 최신버전을 사용중입니다.)

2. 혹시 조만간 또한번 Clojure 스터디 그룹을 시작하실 계획이 있으신지 궁금합니다.

3. 운영툴이 MongoDB, MSSQL과 연동이 되야하는데, 혹시 해보신분 중에 특별한 문제가 있는지 궁금하네요.

4. Docjure 로 Excel (.xls)파일을 읽어오는데, interger 값이 자동으로 float으로 변환되서 읽혀옵니다. 혹시 무슨 문제일까요?

5. Emacs 에서 Clojure 를 기동하는데 시간이 좀 오래걸리는 편입니다. (10+초), Leiningen 에서 run 을 할때도 마찬가지.. 원래 그런건가요? 아니면 뭔가 제가 셋업을 잘 못 한건가요? 

지금까지 테스트해보면서 궁금했던 점입니다.


많는 조언 감사 드립니다. 스터디를 하게되면 한번 쏘도록 하겠습니다. ^^

 


2015년 1월 29일 목요일 오전 11시 31분 34초 UTC+9, 김영태 님의 말:

http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/

[넷평]

1번, ... 저도 괜찮은거 찾아봤는데.. 작년 기준으로는 쓸만한게 없더군요... 제 기준에선 seesaw도 별로였구요.. 혹시 괜찮은거 찾게 되신다면 공유해주셨으면합니다 ㅠㅠ
4번, 다른 언어(python, java, csharp..)의 라이브러리에서도 cell value를 numeric = double로 읽어들이더군요. 꼼수로, 값을 int로 캐스팅하여 비교해서 같으면 int로 찡겨넣는 식으로도 해봤는데... 저같은 경우 타입을 지정한 row를 하나 파서 캐스팅하는 방식이 괜찮게 느껴졌습니다.



2015년 1월 29일 목요일 오후 5시 57분 43초 UTC+9, Chris 님의 말:

[박상규]

2015년 1월 29일 오후 5:57, Chris <chri...@gmail.com>님이 작성:

안녕하세요. 답변 감사드립니다.
지난 며칠 동안 이것 저것 살펴보고 있는데 지금까지 전반 적인 느낌은 이렇습니다.
Clojure에 관련된 자료를 검색해보면 대부분 2012 전후의 자료가 대부분이고 2014년도는 특별한 이슈가 없었던것 같습니다.
초기의 반짝 관심후 모멘텀을 잃고 Lisp의 또다른 dialect로 전락되는건 아닌지..
앞으로의 로드맵을 찾아 보려고 했지만 별다른 소득은 없었습니다.
저보다 많은 지식을 가지고 계시는 분께 앞으로 전망에 대해서 여쭤봅니다.

 

어떤 언어의 전망에 대해 말하는 것이 어떻게 타당하게 가능한지 모르겠습니다만...

3가지 측면에서 살펴 볼 수 있지 않나 합니다.

1. 트랜드적 측면

 

일단 구글 트렌드로 확인해 보신다면 조금이나마 도움이 되지 않을까 합니다.

구글 트렌드로 보면 클로저는 스칼라난 그루비보다는 아직 그 사용이 미미합니다만,

그루비는 2005년 이후 지속적인 하락 추세이고, 스칼라도 2005년 이후 거의 추세에 변동이 없는 반면,

클로저는 2008년 이후로 상당한 모멘텀의 상승 추세를 보이고 있네요. 하지만 클로져도 2014년 하반기부터는

약간 숨고르기를 하는 것 같습니다.

2. 역사적 측면

오랜동안 C++이라는 멀티 패러다임 언어를 한 입장에서, 멀티 패러다임 언어인 스칼라는 C++처럼 장기적으로 하락 추세가 되지 않을까 하는 개인적인 의견입니다. 스칼라가 클로저보다 현재 인기가 있는 것은 C언어에서 C++로 가는 것이 자연스러웠던 것처럼 java에서 객체지향이 되는 스칼라로 가는 것이 자연스럽기도 한 이유겠지요. 

C++은 절차지향과 객체지향을 둘 다 되다보니 C언어를 하던 사람들이 C++을 하면서도 쉽게 절차지향으로 하는 것을 가능해지게 되면서 객체지향 기법을 배우는데 매우 오래 걸리게 되지만, 반면 자바의 경우 객체지향만 할 수 밖에 없어 빠르게 OOP를 배우게 되는 것 같습니다. 따라서 절차지향에서 객체지향으로의 패러다임의 이동이라는 당시의 시대적 요구에 가장 잘 부응한 것은 자바였던 것이죠.

마찬가지로 스칼라는 객체지향과 함수형 프로그래밍이 둘 다 된다는 것이 기존에 자바 프로그래머들에게 친숙하게 느껴지는 부분이 있지만 이것은 역시 C++ 처럼 함수형 프로그래밍을 배우는데 방해 요소가 될 것이라고 생각합니다. 객체지향 프로그래밍 방식을 배우려면 순수 객체지향 언어를 해야 하듯이, 함수형 프로그래밍을 배우려면 순수(?) 함수형 언어를 하는 것이 현재의 객체지향 프로그래밍 방식에서 함수형 프로그래밍 방식으로의 패러다임의 전환의 시대에 부응하는 것이 아닐까 합니다.

3. 본질적 측면

저는 언어가 얼마나 단순한가를 그 언어의 본질적 속성이라고 생각합니다. 

즉 언어가 단순할 수록 보다 우수한 언어라고 생각합니다.

(그리고 우수한 언어가 전망이 좋을 가능성이 분명 많겠죠)

클로저는 제가 생각하기에 현재까지 가장 단순하면서도 전도유망한 언어입니다.

이 부분에 대해서는 제가 테크수다에 작성한 글을 보시면 도움이 되실 것입니다.

1. [왜 클로저(Clojure)인가?] 1. 최후의 프로그래밍 언어

2. [왜 클로저(Clojure)인가?] 2. 클로저(Clojure)의 본질적 우수성

3. [왜 클로저(Clojure)인가?] 3. 단순성이 궁극의 정교함이다.

4. [왜 클로저(Clojure)인가?] 4. 단순한 코드와 복잡한 코드

말이 나온김에 Clojure 관련 몇가지 질문을 드리고 싶습니다.
지금 당장 온라인 게임 운영툴을 개발 하려는데, UI 는 어떤걸 써야하나 고민에 빠졌습니다.

1. JavaFX가 Swing을 대채한다고 되있던데, 기왕이면 최신 UI Framework를 쓰고 싶지만 Clojure JavaFX 래퍼 프로젝트는 이제 시작하는것 같고, Seesaw 를 가지고 해야할까요? 추천할만한 UI toolkit이 있으면 부탁드립니다.  (오늘 테스트중 seesaw로 간단한 윈도우를 띄우고 종료하면 emacs 에서 nrepl connection 이 끊깁니다. 혹시 뭣 때문에 그런지... Java, Cider, Clojure, Seesaw 모두 최신버전을 사용중입니다.)

제가 추천드리고 싶은 것은 다음과 같습니다.

1. ClojureScript

2. reagent (Facebook React.js를 ClojureScript로 랩핑한 것 중 가장 단순함)

3. bootstrap

이런 조합은 웹 어플이긴 하지만 node-webkit을 사용하면 아주 쉽게 deskop 어플로 바꿀 수 있습니다.

 

2. 혹시 조만간 또한번 Clojure 스터디 그룹을 시작하실 계획이 있으신지 궁금합니다.

현재 SICP 스터디 이후에나 어떻게 될 지 결정될 것 같네요...

 

3. 운영툴이 MongoDB, MSSQL과 연동이 되야하는데, 혹시 해보신분 중에 특별한 문제가 있는지 궁금하네요.

저희는 CouchDB를 사용하면서 크게 문제가 없었습니다만...

MongoDB나 MSSQL의 경우에는 어떤지 잘 모르겠네요...

제 생각엔 이 둘이 JAVA와 연동하는데 문제가 없다면 클로저로 연동하는데도 당연 문제가 없을 듯 합니다.

클로저는 모든 자바 라이브러리를 사용할 수 있으니까요.

 

 

4. Docjure 로 Excel (.xls)파일을 읽어오는데, interger 값이 자동으로 float으로 변환되서 읽혀옵니다. 혹시 무슨 문제일까요?

원래 Excel 문서는 모든 수를 float로 저장하는 것으로 알고 있습니다.

 

 

5. Emacs 에서 Clojure 를 기동하는데 시간이 좀 오래걸리는 편입니다. (10+초), Leiningen 에서 run 을 할때도 마찬가지.. 원래 그런건가요? 아니면 뭔가 제가 셋업을 잘 못 한건가요? 

저는 Emacs를 쓰지 않지만 주변에 이맥스를 쓰시는 분들을 보면 그렇게 느리지 않는 것 같다는...

문제되는 상황을 좀 더 상세하게 기술해 주시면 이맥스 도사분들이 많으니 분명 도움을 받으실 수 있을 것입니다.

 

 

지금까지 테스트해보면서 궁금했던 점입니다.


많는 조언 감사 드립니다. 스터디를 하게되면 한번 쏘도록 하겠습니다. ^^

기대되는 바입니다. ^^

 

 


2015년 1월 29일 목요일 오전 11시 31분 34초 UTC+9, 김영태 님의 말:

http://redmonk.com/sogrady/2014/01/22/language-rankings-1-14/

위의 링크에는 GitHub repositories에 등록된 프로젝트들이 주로 어떤 언어들로 이루어져 있는가를 기준으로 평가한 프로그래밍 언어의 인기도를 측정한 결과를 담고 있습니다. 2014년의 프로그래밍 언어 선호도 조사 결과를 보면, Scala가 Clojure보다 인기도가 앞서고 있는 것은 사실입니다만, Clojure가 Groovy보다는 앞서고 있는 것으로 나타나고 있습니다. 그리고 그 상승과 하강도를 보면 Clojure가 가장 높은 상승세인 +5인 반면에 Scala와 Groovy는 둘 다 -2를 기록하고 있습니다. 위의 결과로 볼 때 현재 상황에서 Clojure가 프로그래머들에게 환영받고 있지 못하다는 결론은 다소 섣부른 듯이 보입니다.

다음의 제가 쓴 두 개의 글을 읽어 보시면, Clojure에 대한 이해에 도움이 될 수 있을 듯 합니다.  

https://groups.google.com/forum/#!searchin/lisp-korea/%EB%B3%80%EB%AA%85/lisp-korea/CkWgXTA9ymk/DKW-lx-uoR0J

https://groups.google.com/forum/#!search/authormsg$3Alisp-korea$2C0KhfrNAjbcsJ$20after$3A2013$2F8$2F1$20before$3A2013$2F9$2F1%7Csort:date%7Cspell:false/lisp-korea/sBfEoKI2fvw/26K25XL2JlAJ

프로그래머의 입장에서 볼 때, 고객을의 요구는 날로 복잡해지고 있습니다. 그로 인해 프로그램도 나날이 더더욱 복잡해지고 있습니다. 결국은 이 복잡도를 어떻게 낮출 것인가의 문제가 현재의 소프트업계가 당면한 가장 큰 화두이자 성패의 열쇠입니다.

이런 점에서 볼 때, Scala는 객체지향 방식과 함수형 언어의 특징을 모두 담고 있는데, 이러한 Multi-paradigm 전략은 장점으로 작용하기 보다는 단점으로 작용하기 쉽습니다. 절차지향도 결국은 State(멤버 변수)의 사용을 접근 지정자를 통해서 제어하고 있을 뿐, 본질적으로는 State를 적극 활용하는 프로그래밍 방식입니다. 그래서 함수형 언어 측에서는 객체지향을 절차지향과 크게 다르지 않은 부류로 취급합니다. 함수형 언어에서 State의 사용을 가능한 한 최소화하려는 이유는, 그럼으로써 프로그램의 복잡도가 줄어들어 유지/보수가 수얼해지기 때문입니다. 

객체지향에서는 클래스 간의 의존 관계가 발생할 때 그 관계를 어떻게 설정할 것인가의 문제도 엄청난 복잡성을 추가합니다. 의존하는 클래스가 늘어날수록 복잡도는 기하급수적으로 증가합니다. Clojure에는 그런 복잡성이 존재하지 않습니다. 왜냐구요? 클래스라는 개념 자체가 없는데, 클래스간의 관계를 고민해야할 필요가 있을까요? Clojure는 객체지향을 지원하지 않습니다. 객체 지향이 문제의 복잡도를 줄이기는 커녕 오히려 높이고 있는 원인으로 진단하고 있기 때문입니다. 그래서 Clojure에서는 데이터를 클래스로 감싸지 않습니다. 클래스로 감싸지 않고 데이터를 있는 그대로 이용합니다. 데이터를 클래스로 감싸게 되면서 코드는 길어지게 되고, 그로 인해 불필요한 복잡성이 증가하기 시작합니다. 예를 들어, 동일한 일을 수행하는데 10,000줄 짜리 코드와 1,000줄짜리 코드가 있다면, 당연히 짧은 코드가, 구현 로직의 이해나 유지/보수에 월등한 우월성을 지니게 되는 것은 자명합니다. 적어도 제 경험에 따르면, Java로 작성할 때보다 Clojure로 프로그래밍할 때 코드의 길이는 적어도 1/5, 크게는 1/10로 줄어듭니다. Java 프로그래밍할 때 제일 짜증나는 일이 gettter/setter만 작성했는데도 이미 코드는 수 백줄을 넘어가 있다는 것입니다. 가끔은 내가 지금 타이핑을 하고 있나 프로그래밍을 하고 있나 혼동이 들 정도입니다.

결론적으로 제가 말씀드리고 싶은 것은, 객체지향 프로그래밍 방식의 접근으로 인해 많은 문제가 발생하고 있다는 것을 있는 그대로 인정하자는 것입니다. 그래야 대안을 모색하기 시작할 수 있습니다. 그리고 그 대안을 찾아가는 과정에서, Clojure는 훌륭한 해결잭이 될 수 있는 언어라는 것입니다. 

2015년 1월 27일 화요일 오후 11시 46분 25초 UTC+9, KI-YOUNG BANG 님의 말:

왜 운영툴로 clojure를 생각하시는지 여쭤봐도 될까요?
요즘 java 대안으로 scala나 groovy는 핫한데... clojure는 그리 환영을 못 받고 있거든요.

--

[chri...@gmail.com]

안녕하세요.

 

자세한 답변 감사 드립니다.

Lisp에 익숙한 저로서는 Clojure가 당연 매력적이지만 경험상 한 언어가 성공하려면 tooling, library 등 eco system이 같이 발전 해야 하기 때문에 여쭤 보고 싶었습니다

앞으로 많은 발전 기대해 보겠습니다.

 

말씀해주신 ClojureScript + reagent + bootstrap 조합은 한번 살펴보고 혹시 질문이 있으면 또 여쭤 보겠습니다.

 

감사합니다.

이 메일은 Google 그룹스 'Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)' 그룹의 주제에 가입한 분들에게 전송되는 메시지입니다.
이 주제에서 탈퇴하려면 https://groups.google.com/d/topic/lisp-korea/i4FJXX143jw/unsubscribe을(를) 방문하세요.

이 그룹 및 그룹의 모든 주제에서 탈퇴하려면 lisp-korea+...@googlegroups.com에 이메일을 보내세요.

이 그룹에 게시하려면 lisp-...@googlegroups.com에 이메일을 보내세요.
http://groups.google.com/group/lisp-korea에서 이 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

---

이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다. www.avast.com