왜 스칼라를 비롯한 잡종/순수 함수형 언어가 메이져가 될수 없는가..

OKKY 및 페이스북 에서  두서없이 작성했던 글을 모아보았습니다.

(정확한 통계가 아니라 제 협소한 경험에 의한 주장이라는 점과 대중화의 정의가 사람마다 다를것이기때문에 그냥 이런 생각도 있구나 하시면 될 거 같습니다.:-) )

유망언어들 중 클래스가 없는 언어들이 있죠.클로저,golang  말입니다. 이 언어들은 클래스의 무용과 그 자체가 가진 복잡함을 단점으로 대비시켜 자기 언어를 광고 하기도 합니다.  맞는 부분도 있지만 대중화에 있어서는 틀렸다고 봅니다. 인간이란 사회적 동물입니다. 어떤것들의 집합,연관성,소속,계층에 대해 인식하는것을 애초부터 자연스럽게 느껴왔죠. 클래스가 그런겁니다. 사람들은 뭔가가 하나에 뭉쳐있다는것 만으로 큰 안정감을 얻게 됩니다. C++ 자바가 대규모 프로젝트에서 계속 사용되는 증거라고 봅니다. 저는 이 안정성에 주목 하였으며 이 특장점 때문에 클래스기반 객체지향언어는 계속 대중성에 있어서 최상위에 위치 할 것입니다.

---

이 글의 조회수가 높아짐에 따라 스칼라에 대한 안좋은 인식이 생길까 우려스러워 한 마디 추가 합니다.

개인적으로는 스칼라 언어  굉장히 좋아합니다. 그래서 제 블로그에는 수많은 스칼라,AKKA,Play 글이 올려져있습니다. 웹개발에 있어서 스칼라기반  play2  가 스프링 보다 즣은 면이 많다고 생각합니다. Reactive 프로그래밍에 적합합니다.Akka 로 마이크로서비스 구현하는것도 편리하구요.그러나 내가 좋다고 대중적 1,2 등 언어가 될 순 없습니다. 10등 20등 언어면 어떻습니까 내가 우리팀이 좋아하면 쓰는거죠. ㅎㅎ

물론 모든 언어 파라다임은 장단이 있으며 함수형 프로그래밍의 단점이 없는것은 아닙니다.

함수형프로그래밍의 단점1  

함수형프로그래밍의 단점2

@ 아래부터 원글입니다. 
미리 정리해서 쓴 글이 아니라 어떤 글에 대한 반박 형식의 글을 모음집이라 
정리가 잘 안된 점 양해해주세요. 

---

" list.map( x => User(x.name, format("Y-m-d", x.regdate) ) ) 로해결합니다. "  - notice 님 글 발췌.

스칼라 그러니깐.. 저런 함수형 표현들이 굉장히 깔끔하긴하죠.

그리고 저런표현이 훨씬 좋다고 많이들  광고합니다. 심취하면 notice 님처럼 과격한  글도 쓰는것이구요. 

라인수가 줄어들었으니.. 유지보수가 편해진다. 길게 늘어쓰지 않고, 함수(이름있는) 로 표현하니깐

이게 무엇인지 명확하게 알려줘서 유지보수가 편해진다. 내부적으로 성능을 높이게되면 공짜점심이 생긴

다 등등.. 엄청 좋긴 합니다. 

근데 하나의 함정은 for 문 대신해서 저런 추상층이 높아진 표현은 그 만큼 오류에 대한 복잡도도 증가합니

다.  뭐 그렇다고 "그럼 c 로 짜거나 어셈블리로 짜면 더 단순해서 좋겠네? " 라고 말하실 수 도 있으나, 

제 생각은 보통 사람들이 받아드리는 최적의 추상단계로 "자바" "파이썬" 정도로 생각합니다.(물론 Java 8 

Stream API 도 제외. 그것도 모두가 평범하게 사용되기까지는  10년 있어도 무리라고 봅니다.) 

(저도 함수형 좋아합니다. ^^) 근데 제가 10년넘게 C++ 을 주력언어로 사용하면서 느낀게..  

(C++ 은 10년전부터 함수형 패러다임을 추가하고있음) 

대부분의 개발자들은 혹은 인간은  본능적으로 함수형 패러다임을 어려워합니다. (익숙해지기 오래걸림) 

그냥 for문을 여러줄에 걸쳐서 작성한것을 읽는걸  "함수자"  등을 쓴것보다 더 쉽게 읽는다는 말입니다.

흡사 절차지향적으로 쭈욱 써놓은걸 , 객체지향적 패턴으로 마구 추상화 시켜놓은것보다 

코드리딩이 쉬운것 처럼말이지요.

 ( 객체지향적 코딩이 대중적 인간이 익숙해질수있는 최상점이라고 봄,  SQL 이나 LINQ 등을 양념으로) 

bool is_cool (const Thing& x) { ... }
find_if(begin, end, not1(ptr_fun(is_cool)));

* c++ 은 10년전부터 함수형을 지원했지만..이런 코딩을  일반적으로 실무에서 찾아보기 힘들죠..

  그냥 자기만족 수준. (물론 람다가 최근에 표준이 되어서.. 앞으로는 좀더 많이 쓰이겠지만..) 

내가 notice  님 이전글에서 , 함수형언어가 메이져가 될 가능성은 0%라고 예견했는데...

결국 이유가 단순합니다. 어려워서 입니다.   (단순 Functor 유틸조차 어렵습니다. 포인터,레퍼런스형 따로

있는 바인더,부정자..등등)    좀더 정확히 말하면  C++ 개발자들한테 어려운것을 감수할만큼 강력함을 어

필하는데 실패한거겠지요. (최근 자바8 Stream API 는 성능이라는 공짜점심때문에 더 좋아지긴 했습니다)

아마.. 순수함수형식의 코딩이 어렵지 않게 느껴지는 그룹과  꼭 필요한그룹에서는 사용되겠지요. 

근데 대중적이기는 무리라고 봅니다. 아 클로저는 아예 언급도 안하렴니다.  결국 자바는 쭈욱 갈거라고 생각합니다.(조금씩 차용하며)

(저런 함수형 표현을  쓰지 않더라도 충분함, 오랜기간 크게 사용되지도 않을거라 예견)

(먼가 엄청 강력한걸 어필할수있으면 자연스럽게 , 자바8이 각광받거나 스칼라로 옮겨감)  

대중에게 퍼트리고 싶어하시는 마음 알겠으나 ..그러기 위해서는 그렇게 과격하게 하지말고..

짧게짧게 팁/테크로 올리면.. 대중화까지는 안되더라도 많이들 쓰실겁니다.

( 추가)

혹자는 현재 미국에서는 스칼라가 많이 쓰인다느니..자바,c#,javascript들도 함수형계열 아이디어를

앞다투어 차용하지 않느냐? 다음세대는 함수형 페러다임에 쉽게익숙해질거다.등등

흠흠 얼핏 생각하면 그럴수도있겠습니다만..

근데 함수형패러다임은 아시다시피 요즘 튀어나온거도 아닐뿐더러  최근 스칼라로 코딩하는 데 이상한

우월감을 느끼는 몇몇 수준이하의 사람들처럼 옛날부터 Lisp 등에 자부심을 갖고있는 사람들은

존재했었지요 .근데 lisp / 헤스켈 / 얼랭 은 대증화와는 거리가 멀지요.

최근들어 분산환경이나 멀티코어를 적극적으로 활용해야하는 시대가 되기도 했고 사람이라는게 예전것,

오래된것은 쿨하지 못하다고 생각하는것등이 합쳐지면서 함수형패러다임의 고유의 장점들과

합쳐지면서 각광을 받습니다만..15 년전에 lisp을 처음봤을때부터 느낀게 함수형은 이질적이다라는거죠. 일단 재귀를 생활화한다는것 자체부터 대중과는 거리가 있습니다.

보통어렵다는 C++ 가 훨씬 코드리딩하는데 쉽게 다가왔었습니다.

자바는 더 정제되서 깔끔하구요.  제가  머리가 안좋아서 그럴수도있겠지만 해커와 화가 쓴 그 분

(폴그레이엄) 수준의 개발자가 기준이 될수가 없잖습니까. 고로 여러언어에서 함수형언어의

아이디어는 가져오겠지만 그리고 스칼라를 예로들면  기존에 C++ 의 boost split 보다 훨씬 파서구현에

용이하기때문에 특화되서 사용된다든지, akka  를 사용하는 병렬분산솔 루션이라든지 사용처는

충분히 존재 하겠지만  (물론 여러 대형싸이트에서도 사용중) 그런식의 코드가 대중화되거나

 (c++ 에서 단지 함수자,함수형 헬퍼 들조차 10년지난 아직까지 대중화 되지 않은 사례,템플릿메타프로그

래밍은 말할것도없고) 함수형언어가 객체지향언어를 제치고 메이져가 될꺼라는 생각은 아직 안듭니다.

한 10~20 년후에 어찌될지 굉장히 기대됩니다.  (추가: 10년후에도 여전히 C,C++, 자바, 파이썬, 자바스크립트가 대중언어일거라 예측합니다. Swift  가 강력히 올라갈것이고 그 뒷자리를 스칼라, Go 가 차지) 

(상세 추가 2 : 다른곳에 쓴 댓글을 가져옴) 

스칼라를 쓰면서 단지 제공되는 functor util 쓰는것에 대한 이득만으로 스칼라를 사용하는건 낭비라고

보구요. 말씀대로 강제하진 않지요. 잡종인 이유가 그런회유책이니깐요. (C++ 처럼) 자바도 대략

다 지원하는데 굳이..

결국 C++ 을 제대로 쓰려면 자바등을 공부해야 하는 or  하면 좋은것처럼 스칼라도 제대로 쓰려면

그 실제 철학을 잘알아야 하는데 아시다시피 스칼라는 이름이 나타내는것처럼 추상을 극대화하는것을

쉽게 해주며  언어를 사용하는 사람이 언어내에서 다른언어를 만들수있을 만큼 자유도를 높여주고자하는

철학을 가지고 태어났으며  그것을 이해하고 사용하려면 소위  함수형프로그램의 특성인  상태불변성,일

차/고계함수,클로저, 모나드등 뿐만 아니라 트레잇,  타입을 요리할수있는 능력이 필요하다고 할수있습니다.

일단 저런것에 대한 helloworld 로 간단한  파서를 만들어보는게 가장 빠르겠지요..

굉장히 간결해보이긴 합니다만..

이 모든것들이 많은 대중적인 소프트웨어에서 필요로 하는것 이상인거 같습니다.

 제 짧은 시야로는 저런 자유도가 오히려 부담감으로 다가오면서 객체지향언어와 그 동안 해온

 동적언어만(필요한것은 LINQ  처럼 언어안에 포함및 라이브러리 제공)으로 계속가자 라는 분위기속에  

 점유율은 크게 변동이 없을것이며 더 간단하면서 강력한 이상향의 무기를 기다리며 시대가 흘러가리라

 봅니다.

ps.

다양한언어가 공존해야한다는것을 부정하는글도 아니고 스칼라/클로져를 쓰지말자 혹은 나쁘다라는 글이 아닙니다.

---

A님: 

솔찍히 댓글을 달까 말까 하다가 걍 달아봅니다. 어짜피 프로그래밍을 잘 알지도 못하는 초보의 멍멍이 소리라고 생각하세요.FP가 재미 없다. 뭐 이건 취향이니 어떻게 할 수가 없어요. FP가 실버불렛도 아니고 FP만 써야 되는 것도 아니니까요. 한가인/김태희/전지현이 자기 취향 아니라고 주장을 한다면 뭐 어쩔수 없는거지요. (FP가 한가인 처럼 이쁘다는 건 절대 아님) 

FP가 어렵다. 이건 조금 논란의 여지가 많다고 생각해요. 저같은 경우 ASM과 C를 먼저 접했고 그담음 VB를 접하고 그다음 C++ 그리고 나서 Java & C# 그다음 Scala & F#이네요. 패러다임이 바뀔때 마다 말 그대로 캐고생을 했던 기억이 납니다. (c++ -> java는 쉬웠던거 같아요 ㅋ) 어렸을때 성질이 속된 말로 멍멍이랑 동급이라 문자 그대로 제 멍청함은 탓하지 않고 키보드 여러번 접어서 화풀이 했습니다. FP가 어려운지 평가하려면 지금 자신의 OOP 지적 수준과 FP에 지적 수준이 동일하진 않더라도 최소한 비슷한 수준은 되야 되겠지요. (지적 수준이 평가잣대가 되기 어렵다면 OOP로 프로그래밍한 시간에 필적하는 시간을 FP에 썻거나요.) OOP는 구루 소리 듣는데 FP는 중급이면서 어렵다고 판단하면 안될것 같아요. 반대로 FP로 구루 소리 들으면서 OOP는 많이 안해보고 학계에 몸담고 있으면서 헤스켈만 왕창해보고 OOP프로그래밍은 해본적도 없으면서 OOP를 까도 안되고요.

FP가 실용적인가? 저는 이 부분은 네라고 말할수 있을것 같습니다. 다만 분야가 어떤 분야인가가 중요하겠죠. 예를 들어 절대 예전 특정 시점의 히스토리를 확인할 필요가 없는 어플리케이션에 오버 엔지니어링을 해서 ES+CQRS를 하면 실용적일까요? 대부분의 FP 입문 책을 보면 이부분을 명확히 언급하고 있습니다. 상태변화가 심각한 문제의 소지를 발생시키지 않는 분야/어플에서는 주저 없이 저는 OOP 언어를 선택할꺼 같습니다. 하지만 병렬/분산 프로그래밍을 해야 한다면 OOP 언어는 안쳐다 볼꺼 같습니다. 제가 싸랑하는 스파크가 이부분을 잘 증명해 주고 있다고 생각합니다.

하마: 

얼핏 보면 교과서적인 말이라 반박하긴 머합니다만.. 좀 더 생각해보면 오류가 있어요. "당신이 OOP를 아는만큼 FP를 알지못하니 비교가 불가능하다." 이건 틀렸습니다. 절대적 노력의 값으로 생각해보면 FP로 처음 시작하는 경우 및 FP로 파라다임을 뼛속까지 바꾸기에는 엄청난 노력이 필요합니다. 왜 FP의 구루가 아닌데도 그걸 알 수 있냐? 경험적으로 이정도면 OOP에서는 충분했는데 FP는 아직 멀었다고 사람들이 몸소 느끼고 있기때문입니다. 굳이 FP를 OOP와 동일한 수준까지 하지 않아도 알 수 있는것이지요. 왜 역사적으로 OOP는 수많은 평범한 사람들이 해왔고 지금도 학원에서 열심히 공부하고 쉽게(?) 취직하여 개발을 하고 있는데 FP로는 그게 가능할까요? 그게 가능했다면 왜 지금까지 순수FP가 대중적으로 쩌리였을까요? 순수 FP는 대형벤더의 도움을 못받았다? 이 핑계는 좀 말이 안된다고 생각하지만 그렇다고 치더라도 좀 궁색하죠. 제 생각엔 filter, fold, reduce, map 류의 함수형도우미(?)들이 각 언어에 차용되어서 사람들이 조금씩 익숙해져가는것은 가능하지만 완전한 파라다임변환으로의 대중이 옮겨가는것은 아예 불가능하다라고 말하고 싶네요.

동시성 얘기도 나와서 말인데.. FP는 광고하죠. 상태가 없으니 동시성프로그래밍에 최선이다라고... 그래서 현재 더 FP가 주목받고 있는 것도 사실입니다. 다만 생각해볼것은 해결해야하는 문제들을 살펴보면 그렇게 동시성 문제가 복잡하게 얽혀있지 않은 문제들이 많다는것이며 ,(즉 자바에서 기존에 제공하는 방식으로도 충분한..굳이 언어파라다임을 바꾸지 않아도 충분한..) 클로저,하스켈을 사용하거나 Scala 를 완전한 FP로 사용하기보다는 그냥 객체지향식으로 사용하면서 Future, Observerble , Akka 같은것을 적용해서 문제를 해결하는 경우가 훨씬 많을 거라는 얘기죠. 즉 순수FP가 동시성 프로그래밍에 더 좋다는 교과서적인 멘트(광고)에 의해 사람들이 그쪽으로 옮겨갈꺼라 생각하는것은 여러 측면에서 매우 순진한 생각이라 봅니다. 

A님: 

승현님이 하시는 이야기에 저는 많은 부분 동의합니다. 제가 FP 신봉자도 아니고요. 분명한 것은 FP가 어렵다고 하는점에는 동의하지 않는 것은 분명합니다. 

승현님께서 분명히 언급 하셨지만 """순수"""라는 말을 FP 붙이셨는데 순수 FP의 정의를 어떻게 잡느냐는 문제도 있습니다. 뭐 잘 아시겠지만요.

개인적으로 대부분의 사람들이 FP로 갈꺼라고 """전혀""" 생각하지 않습니다. 이는 쉽고 어려움의 문제와는 "크게" 상관이 없다고 생각합니다.. 제가 생각할 때 많은 사람이 그 언어를 쓰려면 재밌고 좋고 파워풀하고 등등등은 일급시민이 아니라고 생각해요. 제가 생각할 때 가장 큰 펙터는 잡마켓이라고 생각합니다. 아직도 저는 생생하게 기억나는데 마켓 시장의 크기가 C++ 보다 JAVA가 좀 작을 때 사람들이 커뮤니티에서 논쟁을 많이 했죠. Java의 안좋은 점을 까면서 Java가 성공하지 못할꺼라고 햇었어요. Java가 C++보다 좋고/나쁘고 쉽고/어렵고를 떠나서 Java 마켓이 C++보다 커졌고 그로 인해 나중에 시작하는 사람들은 자바를 배우고 시작을 하는 사람이 많아졌다고 생각합니다. FP 프로그래머가 많아 지려면 개인적으로는 잡마켓이 커지는게 가장 확실한 방법이라고 생각합니다. 그런 점으로 인해 FP 프로그래머가 다수가 될꺼라고 생각하지 않습니다. 

승현님과 생각을 제가 달리하는 부분은 FP가 어렵냐에 대한 부분인 것같은데. 저는 FP가 꼭 모나드/카테고리 이론 등등의 괴수들을 소환하는 것만이 FP라고 생각하지 않습니다.또한 FP를 하기 위해서 꼭 스칼라를 써야할 필요도 없다고 생각해요. 승현님 언급하신것 처럼 C#에 LINQ나 JAVA의 스트림 또는 얼랭에 영향을 받은 Akka등을 쓰는것도 FP를 하는거라고 생각합니다. 어찌됐건 FP가 장점이 있고 지금 쓰는 언어에서 그 FP에 장점을 얻기위해 펑셔날하게 쓰면 FP를 한다고 말해도 된다고 생각합니다. C#이든 JAVA든 언어가 허락하는 범위 내에서 얼마든지 펑셔날하게 짤 수 있고 그로인해 장점을 얻을수 있는데 굳이 순수형 FP로 넘어가서 FP를 해야될 이유도 모르겠고요. 저는 많은 개발자들이 쉽게 LINQ/Stream을 쓰는데 FP가 어렵다고 주장하는게 맞냐는거죠. 어렵다고 주장하는게 모나드/카테고리 이론등등등 이라면 모를까요.

제가 원하는 건 FP == 모냐드 대마왕 이런 선입견이나 좀 더 FP스러운 언어를 써서 FP 해야한다고 생각하는게 없어졌으면 하는 바램입니다. 자신이 쓰는 언어에서 FP를 통해서 장점을 얻을 수 있으면 그렇게 하면 되는거지 굳이 OOP를 버리고 FP만 고집할 필요도 없고요. 제가 FP 공부를 많이 안하고 FP에 대해 앞 뒤 설명도 없고 컨텍스트는 다날리고 FP 까대는 사람들이 많이 보여서 그런 이야기를 했습니다.

하마:

님과 저의 생각은 거의 일치하는거 같습니다. 기준을 달리 바라봤을뿐... 대중화에 대한 조금 다른 시각의 얘기를 추가해보겠습니다. "C#에 LINQ나 JAVA의 스트림 또는 얼랭에 영향을 받은 Akka등" 언급하셨는데 ..저 또한 언급했구요..이런것들 조차 대중들이 모두 자연스럽게 사용하게 되기까지는 얼마나 걸릴지 모릅니다. 단지 현재 SI 시장에서 Java8 을 안쓰기 때문이기 때문에 이런 말을 하는 것은 아니구요. 만약 Java8가 기본이되도 함수형 스타일을 쓸 까에는 조금 회의적이에요. 아시다시피 페이스북상이나 기타 인터넷상에서는 보통 얼리어댑터의 발언이 셉니다. (물론 저런것이 그렇게 얼리는 아니지만요 ㅎㅎ) 하지만 실제 현업에서는 그니깐 대중적으로는 그게 아니거든요. 이유는 저는 현재 Scala, Python 을 주로 사용하지만 C++도 2000년부터 14년간 사용했습니다. 수십만,수백만의 라인수의 솔루션에 참여도 해봤는데.. 아시다시피 C++ 은 예전부터 Functor 같은것을 제공해왔습니다. 함수형아이디어를 차용해왔다는 말이지요. 하지만 실제 프로젝트에서 그렇게 사용하는 경우는 별로 없었습니다. 거의 제가 주도적으로 적용을 했었는데요. 요즘 모던 C++ 이라고 더 강화되긴했는데 실무에서 대중적으로 받아드리기까지는 얼마나 걸릴지 모르겠습니다. 자바나 스칼라에서의 함수형스타일의 대중화도 얼마나 걸릴지 ....오래걸릴거라 유추됩니다. (어려운 모나트,카테고리이론 얘기하는건 아닙니다) 물론 예전과 다르게 요즘은 열풍이라 좀 더 뜨거워지겠지만요 ㅎㅎ 즉 대중은 for 문을 돌리는것에서 map,filter,reduce 를 사용하는것으로 변화하는것 조차 요원한게 실제 현실이 아닌가 하네요.

---