그들이 밝히는건
가독성과
빠른 속도 (함수의 투명성으로 인해 세마포어사용안함 -> 멀티프로세스 효율 극대화 및 side effect (stack계산등) 최소화)
뿐임.
이에 반박해보겠음 (주관적)
1. 가독성
우리가 (C/C++/C#/Java 등) 익숙하기에 가독성이 높다고 착각하고 있데.
그런데 이것부터 잘못된말이야. 애초에 language (not only programming language) 자체가 이상한거야......
니넨 생각하는게 말로 바로 떠오르냐? 우리도 말은 학습한거거든? 그리고 엄~청익숙해져있기에 생각하는것이 바로 말로 튀어나올 수 있는거고.
그런데 이제 나이가 드니까 영어를 공부해야해. 영어 한두번배워보니까 수많은 전치사들 그리고 관용적인 표현들...
에엥? 존나 쓸데없네 이 언어는 사실 잘못 설계되어있어! 미국인들은 익숙해서 쓰는것 뿐이지 사실 언어자체가 잘못되어있는거야!
라고 말하는거랑 뭐가 다르냐고..
가독성은 익숙함에서 나오는거야 토큰이 적다고 가독성이 높은게 아니라고 그건 쓰기 편한거고 컴파일러가 편한거겠지
씨발 클로저 차냥하는 병신새끼들아..... 한국어는 토큰 많은편이잖아 씨발럼들아 툭하면 조사 존나게 튀어나오고
주어에만 은는이가 4개나 붙는데 씨발 우린 편하잖아 개새끼들아.... 가독성은 익숙함의 문제라고 씨발것들아....
클로저 존나 괄호 존나 많거든... 이거 존나병ㅇ신같아.... 괄호가 무슨 닫힐때 5개닫히고 그러냐?
씨발 지들도 if문쓰는구만? 함수에서 if문 쓰는순간 한눈에 함수가 파악되기는 글럿어 씨발...;;;
2. 빠른 속도
클로저는 컴퓨터를 진짜로 real calculator로 사용하기에 적합한 그런 언어인거같아
변수를 re-write하는 기능이 없어졌지. (write를 하긴하지. 메모리에)
이는 멀티프로세스에서 분명히 효과적이지. 그런데.. 현재 OS들 위에서 돌아가려면
객체를 지원하는 수 밖에 없지 않을까?
왜 안드로이드가 Go언어도 안쓰고 클로저도 안쓰고
C++에서 Java로 포팅햇는지 알아? 전혀 다른 성격의 언어를 포팅시켰어..
왜냐하면 우리가 인지하고 쓰기 편한(가독성에서언급했듯이 익숙한) 체계는 Java/C#같은 언어여서그래
익숙하기도 할 뿐더러 우리가 인지하는 세계는 객체 세계잖아.
너, 나, 우리 그리고 너의 이름 나의 이름 우리의 이름이 잇는거지
이름을 구하는 함수 안에 list로 이어져있는 현재 point의 사람을 가르키는 함수를 lazy-seq로 이어낼 수 는 없는거잖아?
어휴.... 한마디로 빠른속도는 그렇게 소스코드의 생산성을 포기하면 어떤 언어도 가능한거라 봐.
소켓통신이나 등등이 없어도 된다면 말이지..
그런 여러가지 method들이 등장한다면 (영속성없는 기능 목적의 함수)
클로저는 쓰레기가 될 뿐이라 생각함.
흉 내가 보기에 클로저응 보기전에 리치히키 강연들 찾아서 이들어봐. 난 영어는 귀머거리 수준이라
https://github.com/matthiasn/talk-transcripts/tree/master/Hickey_Rich
여기 대본이랑 같이 보는데 리치히키의 현재 언어들이 가진 문제들에 대한 통찰력은 아주 대단한 것 같고 당연히 이런 점이 클로져에 많이 해
물론 나는 클로져를 익히다 이막스를 익혀서 c++에디터로 사용하는데 시간을 보내는 중이긴한데;;
형이 위에서 얘기하는 대부분의 이슈는 객제지향이 익숙해서 상대적으로 쉽다는 틀에 잡힌 것 같다. 나같은 경우엔 안드로이드가 자바를 선택한건 이식성과 기존에 많은 자바 백엔드 개발자나 새로운 개발자 유입을 위한 선택이라고 생각해
그리고 클로저는 리치히키의 생산성을 중요시하는 입장에서 나온건데 흉말대로 생산성을 포기하고 속도를 취한다는 개념은 전혀 아니지 ㅎㅎㅎ 일단 강연보고 다시 생각해봐 흉 ㅎㅎㅎ 나도 뭐 클로저 자체를 프로덕트에는 쓰는 입장이 아니어서 야이미친흉 등판하면 잘 알려줄듯 ㅋㅋㅋ
하지만 현시점에서 우월한 언어는 있어도 미래에는 쓰레기가 될지도 모른다는 생각은 전적으로 찬성