그냥 뻘글임. 하스켈을 빤다고 표현한 건 어느정도 호감이 있다는 거로 해석하면 됨.
프로그래밍 언어 추세가 정적 타입 체크를 강화하는 방향으로 가고 있음. 컴파일 전에 버그의 싹을 제거하자는, 빠른 반복 주기를 위한 선택이지.
타입 체크를 강화하는 것 자체는 어렵지 않음. 문제는 안정성을 유지하면서 스크립트 언어만큼 자유도를 늘리는 게 어렵다는 점임. 이 문제가 해결되면 어떤 게 가능할지 알아보자.
C의 배열은 임의 원소 접근은 범위 검사가 아예 없고 그래서 위험하지. C++ array는 어느 정도 정적 검사가 되지만 길이 변경은 여전히 불가능하고 런타임에 완벽하게 안전하다곤 할 수 없음. 이걸 컴파일 타임에, 문제가 없다는 사실을 증명하는 게 하스켈 커뮤니티가 추구하는 방향임. 가까운 기술로는 LiquidHaskell이 있음. 근데 이건 언어 확장일 뿐이고 실제 언어에 통합하려면 타입이 값을 가져야하기에 그걸 가능하게 하는 Dependent type이 이슈가 되는 거임.
다른 예로 모나드는 일종의 DSL로 볼 수 있음. 일반적인 C패밀리는 함수 본체에서 어떤 함수든지 실행할 수 있지만, 하스켈은 (IO 모나드가 아닌 한) 모나드 레이어에서 제공하는 기능밖에 쓸 수 없음. 즉 함수 호출 금지가 가능하고, 일종의 XML처럼 되는 거임. 이걸로 뭐가 가능하냐면……
UI 디자이너를 생각해보자. 클래스 생성자에 메시지박스 코드를 넣으면 WPF XAML 에디터에서 편집할 때 메시지 박스가 뜨는 걸 본 적이 있음. 잠재적으로 위험한 동작이지. 문제는 이걸 문법적으로 막을 수단이 없음. 하스켈이었다면, UI 컴포넌트 조작만 하는 순수한 연산만 받는 게 가능하지.
아니면 안드로이드 앱을 짤 때, 어떤 권한은 요청하지 않았으므로 컴파일 타임에서 문제가 있다고 오류를 뿜뿜할 수도 있겠지. 자바나 코틀린은 어노테이션이랑 컴파일러 플러그인 떡칠을 해서 해결하지만, 이걸 순수 타입시스템으로 해결하고 싶다는 생각이랄까.
요컨대, 하스켈 자체보다 가능성을 보고있다고 생각할 수 있을 듯. 그래서 연구용 언어라고 부르고.
하스켈은 내가 보기엔 이상주의자들의 언어임. 각각의 문법을 보면 흠잡을 게 그닥 없음. 근데 합쳐놓고 보니까 별로 쓸만한 게 못 될 뿐. 하스켈을 실제로 쓰는 사람들은 심각한 빠요엔이니 따라하면 안 됨. 하스켈의 장점보다 단점을 열거하는 게 더 쉬움.
글쎄 프로덕션 레벨에서 생각보다 꽤 사용경험이 있어서 ㅇㅇ 페북에서는 스팸 필터를 하스켈로 만들었던게 유명하지. 엔터프라이즈 레벨에서도 꽤 쓸만하다는것 - return 0;
하스켈을 현업에서 쓰심? ㄹㅇㄹ?
나 말고; - return 0;
아니 엔터에서 쓰는 사례가 있는 건 맞는데, 그게 빠요엔들이라서 그런 거라는 거죠. 제가 고용주 입장이면 하스켈 못 반김. 무한루프 하나만 있어도 디버깅 토나오는데.
페북이라도 빠요엔들이 많다고 말할 수는 없을 것 같은데;;; - return 0;
페북은 특이케이스 중의 특이케이스예요;; 거긴 오히려 안 쓰는 언어를 찾기가 힘들 텐데. 아예 새로운 언어까지 내놓는 곳에서 하스켈 쓴다고 이상할 건 없죠. PHP로 시작해서 그거 버리는 과정에서 짬뽕된 거 아닌가요.
아니 그런 뜻이 전혀 아니고, 페이스북의 엔지니어 population 이 님이 생각하는 것만큼 그렇게 고인물들이 아니라는 말임. 그 중에 하스켈을 이미 할줄 알았던 사람들이 얼마나 많을 것 같아? - return 0;
컴파일러에서 버그 찾고 수정하시는 분들이 고인물들이 아니라고 생각하신다면야……
https://code.fb.com/security/fighting-spam-with-haskell/
Did we find bugs in GHC?
GHC 코드 한 모듈이라도 해석 가능한 인력이 얼마나 될까요.
하스켈 코드를 할 줄 알았던 사람은 적겠죠. 그 사람들은 하스켈 코드를 볼 일조차 없을 테니까요. 근데 하스켈 코드를 짜고 연동시키는 사람들은 이 정도 수준을 갖추지 않았나 생각해요.
그걸 찾는게 진짜 한 두명이고; 나머지 대부분은 평범한 엔지니어들이지 뭔소리야. 그런식으로 따지면 구글 몇만 엔지니어들이 뭐 다 켄 톰슨이게? - return 0;
이 친구 엔터프라이즈들을 너무 과대평가하는데.. - return 0;
확실히 전 딱히 경력이랄 게 없지만, 하스켈 디버깅하면서 똥줄탄 경험은 있어요. 자신의 경험으로 하스켈이 쓸만하다고 생각하는 점을 알려주실 수 있나요?
폴직히 말해서 디버깅 안 좆같은 언어가 어딨음? 나는 C++ 하는데? 세그폴트 일주일 잡아봄? - return 0;
컴파일러를 디버깅 했다는 말은, 실제 컴파일러 버그를 맞닥뜨렸다는 걸 의미해요. 현업에서 그 상황을 만나는 건 결코 장점이 되지 못해요.
세그폴트가 더 나아요. 세그폴트가 안 나고 무한루프를 도는데, 그 무한루프를 어디서 도는지 알 수 없는 게 더 화가 나요.
난 gcc segfault 한 3번인가 경험했고 아는 사람은 gcc 파싱에러 경험했는데? - return 0;
컴파일러 버그 경험하는 것 정도로 왜 엄살이야 - return 0;
저기서 고쳤다는 버그엔 GC 문제도 있어요. 런타임 버그요. 이거 고칠 수 있을 것 같아요? 프로그램이 죽는데 죽는 원인 아는 거 부터 막막할 거 같은데요.
옆 동네는 런타임 에러 디버깅 하다가 인텔 CPU 도 찾았는데; 불만을 갖는 포인트를 모르겠네. 뭔 런타임에 버그 있는 플랫폼은 평생 못 쓰겠다 이거야? - return 0;
저도 컴파일러 문제를 맞닥뜨렸어요. 하스켈에서 빈번하게요. 맞닥뜨려보니까, 나중엔 차라리 제 잘못이면 좋겠다는 생각이 들더라고요. 문제 우회가 가능하면 다행인데, 안 되면 재앙이죠.
이런 실드가 필요하다는 거 부터가 이미 좀 못쓸만한 부분을 알려주는 거예요. gcc버그는 진짜 안 나와요. 컴파일러 버그도 버그의 퀄리티가 달라요. 유지보수 인력 규모부터 다르니까요. GHC는 기능 깨지는 거부터가 그렇게 드문 일이 아니고요.
뭔 개소리야 gcc 버그가 얼마나 많은데;;; - return 0;
최소한 전 C/C++계열 컴파일러 버그로 곤란한 적은 없었어요. 하스켈은…… 윈도 계열 버그는 버그로 취급하지도 않죠. 안 고쳐요.
이럴 줄 알았으면 단점 글을 정리할 걸 그랬나봐요. 분량도 많이 뽑을 수 있고 이런 댓글이 달릴 일은 없었을 지도. 쓸지 안 쓸진 모르겠지만……
나올 예시가 몇개 밖에 없는데 뭔 쓸만해.
그런식으로 따지면 세상에서 제일 쓸만한 언어는 파이썬 자바 C냐? - return 0;
자바써도 GC문제 발생 할 텐데.. 그럼 자바개발자들은 최도 GC소스 뜯어서 고쳐가며 쓸 정도는 되어야하나? ㅋ
물론 GC 문제를 해결해야만 하스켈을 사용할 수 있진 않겠죠. 언어의 우열을 가리자는 게 아니라, 하스켈을 실사용하면 별별 난관을 맞닥뜨린다는 거예요. 다른 언어에 비해서 당연한 게 당연하지 않게 돼요. 사용자 수 차이가 괜히 있는 게 아니라는 걸 알게 돼요. 제가 하스켈을 싫어하는 게 아니라 좋아하는 편이예요. 원래 제가 이 글에서 전달하려던 건 하스켈이 어떤 매력과 가능성을 가지고 있는지였는데, 제 능력이 부족하니까 하스켈을 못 쓰는 게 아닌가하는 전개가 되니 좀 씁쓸하네요.
그게 하스켈의 특징이 아니라는 얘기를 하고 있는데 왜 말을 못 알아듣냐 - return 0;
지금까지 하스켈의 특징을 얘기하고 있다고 생각지도 못했는데, 그럼 하스켈의 특징이 뭐라고 얘기하려던 거였나요?
너 진짜 한글 못하는구나 하스켈이 다른 언어에 비해 특별히 더 불안정하지 않다는거야. 프로덕션 레벨로 가면 다 빵빵 터진다는거야 - return 0;
'하스켈이 타 언어에 비해 불안정하지 않다'를 하스켈의 특징으로 볼 수 있는지는 넘어가고, 돌아가게만 만들 수 있다면 안정성이 있다고도 할 수 있겠죠. 더 마이너한 언어보단 안정성이 있을 테니까요. 서로 생각하는 기준과 정도가 달랐던 거려나요. 저는 좀 더 편해지지 않으면 일반적으로 사용하긴 무리라고 생각하거든요.
얘는 자기가 무슨 말을 하는지도 모르네. 까놓고 말해서 하스켈 써본거 같지도 않고.. 글고 "프로그래밍 언어 추세가 정적 타입 체크를 강화하는 방향으로 가고 있음. 컴파일 전에 버그의 싹을 제거하자는, 빠른 반복 주기를 위한 선택이지" 여기서 거른다
애자일 얘기를 섞어서 강조하고 싶은 것 같은데.. 반복 주기 용어는 iteration이고 이런데 쓰는 용어가 아니다. 아마 개발 라이프 사이클을 줄인다는 말을 하고 싶은거 같은데 타입클래스 정의 -> 컴파일 ->유스케이스 구현 -> 컴파일 -> 테스트 확인. 이딴 사이클이 어딜 봐서 빠른 반복주기(개발라이프사이클)?
TDD조차 개발라이프 사이클이 늦어서 REPL로 즉시 피드백을 뽑고 테스트 횟수를 최대한 줄이는 식으로 가고 있고.. 타입을 강화하기는 커녕 역으로 타입추정을 최대한 늘려서 타입 정의하는 부분을 최소화 하는게 추세임. 요즘 나온 언어들 스칼라, 클로져, 코틀린, 고랭, 크리스탈 중에 타입이 빡빡한거 있음? 심지어 개발프레임워크 조차도 명시적으로 규정하기 보다 관행을 강조하는 쪽으로 가고 있는 마당에;;
음…… 반복 주기라는 용어를 그 애자일 사이클의 의미로만 쓰는 건지는 모르겠지만, 저는 런타임에 발생할 문제를 타입 체크 단계에서 발견할 수 있으니 오류 수정이 빨라진다는 의미로 썼어요. REPL로 피드백을 뽑는 것도 반복을 빠르게 하는 거라고 본 거죠. 타입 강화와 타입 추정은 서로 별개의 영역 아닌가요? 위키를 보면 strong/weak 타이핑이랑 manifest/inferred로 나와있어요. 타입 추론이 잘 된다는 게 weak typing이라는 걸 의미하지는 않는다고 생각해요. 제가 뜻한 타입 체크 강화는, 타입 시스템을 섬세하게 해서 컴파일 시간에 오류를 잡고 (strong typing의 특징) 언어의 표현력(expressiveness)을 늘리는 걸 말하는 거였어요.
하스켈 깊게 공부해볼뻔 했는데 고마우이!