Haskell을 직접 실무에서 사용해 본 뒤, 그 장점과 한계, 그리고 Simple Haskell이 왜 중요한지에 대한 생각을 정리한 글.
가입하기
앱 받기
가입하기
fommil 추천
fommil 추천
fommil 추천
fommil 추천
fommil 추천
fommil 추천
fommil 추천
팔로우
6분 읽기
·
2020년 5월 22일
363
5
공유
거의 2년 전, 나는 안락한 대기업 Scala 일자리에서 더 위험한 중간 단계 스타트업으로 옮겼고, 그곳에서는 Haskell을 사용했다. 이 글은 Haskell을 직접 경험한 뒤 내가 갖게 된 생각을 정리한 것이다.
Haskell은 천상의 언어다. 내가 Java, Scala, Python으로 지금까지 써 온 모든 것은 이에 비하면 장황하고 문자열과 질긴테이프로 겨우 붙들어 놓은 것처럼 느껴진다.
Haskell의 빌드 도구와 런타임 분석 도구는 엔터프라이즈 언어의 업계 표준에 뒤지지 않으며, 어쩌면 그보다 낫다.
Haskell 컴파일러는 매우 견고하고, 아주 빠르며, 높은 성능의 결과물을 만들어 내고, 훌륭한 경고와 오류 메시지를 제공한다. 다만 실험적인 언어 기능으로 벗어나지만 않는다면 그렇다.
Haskell 문서와 처음부터 학습하기 쉬운 정도는 주류 언어와 비교할 만하다. 즉, Haskell 지식이 전혀 없는 프로그래머도 교재(Graham Hutton의 책이 최고다)와 오프라인 강의 또는 장난감 프로젝트를 결합하면 배울 수 있다. 또는 유료 현장 교육도 받을 수 있다. 참고로 많은 EU 및 영국의 컴퓨터과학 졸업생은 학업 과정에서 Haskell을 배운다.
에디터 지원도 꽤 좋고 계속 발전하고 있다. 언어 자체가 도구를 만들기 쉽게 설계되어 있다. 파일 헤더를 정적으로 분석하면 그 파일에서 사용된 어떤 심벌이든 완전 수식 이름으로 해석하는 데 필요한 모든 정보를 알 수 있고, 매우 개방적인 컴파일러 api 덕분에 REPL과 LSP 구현도 가능하다. 많은 사람이 곧 IDE가 다른 언어에서만큼 필수적이지 않다는 것을 깨닫는다.
강한 타입 시스템은 모든 것을 인덱싱할 수 있게 하고, 이는 Hoogle을 통해 검색 가능하다는 뜻이다. 나는 Lisp / Scheme의 열렬한 팬으로서, 1인 프로젝트에서는 타입이 내 발목을 잡고 속도를 늦춘다고 느낀다. 하지만 발견 가능성은 그 단점을 상쇄해 준다. 물론 프로젝트가 커질수록 그 이점은 더 커지고, 타입 안정성의 진가도 그때 발휘된다.
개 주인들이 결국 자기 개를 닮아 가는 것처럼, 언어 공동체도 그 언어의 어떤 근본적인 측면이나 핵심 사명을 닮아 가게 된다고 나는 믿는다.
Haskell은 연구용 언어로 설계되었고, 주요 구현체인 ghc에는 많은 언어 확장이 있다. 그중 다수는 박사 논문의 산물이다. 무언가를 폐기하는 일은 출시하는 일보다 더 어렵기 때문에, 한 번 들어간 것이 제거되는 일은 드물다.
이처럼 끊임없이 “더 낫게”, “더 멀리” 가려는 욕망은 공동체에도 반영되어, 수많은 기초 프레임워크를 만들어 내고 아주 사소한 세부 사항까지 끝없는 기술 논쟁을 벌이게 만든다. 백 개의 꽃이 피게 하라! 안타깝게도 이는 애플리케이션을 어떻게 구조화할지에 대해 명확하고 방향성이 있는 지침을 요구하는 산업계와는 맞지 않는다.
이는 공동체 안에 Marston의 분류법으로 말하는 성실형 사상가와 영감형 인물이 지나치게 많다는 점에도 드러난다. 그래서 균형 잡힌 팀을 만드는 일이 더 어려워진다. 나는 의도적으로 균형을 맞춘 팀의 일원이었던 운 좋은 경우였지만, 이것은 일반적이지 않다. 순진하게 구성된 팀은 세부 사항에 발목 잡히거나 상아탑을 쌓는 데 빠져, 비즈니스에 중대한 목표를 향해 진전하지 못한 채 실패할 위험이 있다. 반대로 Python 공동체에는 “일단 해치우자” 유형의 성격이 과도하게 많아서 단기적으로는 눈에 보이는 결과를 내는 경향이 있지만, 다른 방식으로는 불균형하다.
일자리는 거의 없고, 그마저도 대부분 업계 평균보다 훨씬 낮은 급여를 준다.
이 작성자의 업데이트를 받으려면 무료로 Medium에 가입하세요.
구독
구독
더 빠른 로그인을 위해 기억하기
결국 Haskell은 30년이나 되었음에도 임계 규모를 얻지 못했다. 더 빨리 성장시키려는 모든 접근은 실패하고 있다.
내 생각에 Haskell이 여전히 틈새에 머무는 이유는 기술적 문제가 아니라 사회적 문제다.
Haskell은 배우기 어렵고, 느리며, 개발자 도구가 형편없다는 오해가 널리 퍼져 있다. 거대한 홍보 예산이나, 많은 교육과 많은 시간과 인내 없이는 오해와 싸우는 것이 불가능하다. 더구나 Haskell 공동체의 완벽주의 진영은 도구가 프로덕션 준비가 되었다는 어떤 제안이 나오더라도 “음, 사실은…” 식으로 반박할 수 있으니, 말하자면 이 공동체는 스스로 제 발등을 찍는 데 능숙하다.
(여기서 선한 인물이 악당을 쏘고, 그다음 금을 찾는다)
Simple Haskell 같은 이니셔티브는 Haskell에 대한 널리 퍼진 오해를 바로잡는 데 어느 정도 도움이 될 수 있다고 나는 믿는다. 하지만 시간이 걸릴 것이고, 어쩌면 컴퓨팅 아키텍처의 발전이 Haskell을 구식으로 만들어 버릴 정도로 오래 걸릴 수도 있다.
더 급진적인 접근도 있을 수 있다. 성공 가능성은 매우 낮지만, 일정은 앞당길 수 있다. 즉, Simple Haskell 이니셔티브가 자체 브랜드를 포함할 수도 있는 자체 컴파일러를 만드는 것이다. 그 컴파일러는 컴파일 및 런타임 성능이라는 당근(예를 들어 Unison 스타일 AST 해싱과 전체 프로그램 최적화)과 에디터 도구를 제공할 수 있다. 언어 범위가 줄어들면 제약을 충족하는 더 단순한 생태계를 암시하고, 여기에 걸맞은 훌륭한 온보딩 문서도 만들 수 있다. 분열이 아니라 엄격한 부분집합이어야 한다.
분명히 하자면, 그런 컴파일러는 초심자에게 맞추어선 안 된다. 이것은 Haskell을 “쉽게 만들어 주자”는 이야기가 아니다. 보수적인 컴파일러는 미지의 영역을 탐험하고자 하는 훌륭한 연구 공동체와는 다른 요구사항을 가진, 경험 많은 산업 실무자를 대상으로 해야 한다. 이런 노력은 ghc 연구 공동체와 좋은 관계를 유지하도록 매우 신중해야 한다. 경쟁이 아니라 상호보완이어야 한다. 대단히 성공적인 확장은 훨씬 더 느린 시간표로 이식될 수 있다. 예를 들어, 현재의 모든 단점을 해결하는 레코드 인코딩이 나온다면 말이다.
표준과 완전히 호환되는 상태를 유지한다면, 이 “더 단순한” 컴파일러가 팀의 요구에 비해 지나치게 미니멀하다고 판명될 경우 언제든 ghc로 옮겨 갈 수 있어야 한다.
나는 그들이 권장하는 언어 확장보다도 더 작은 부분집합을 제안한다. DeriveGeneric과 GADTs는 제외하고, orphan instance나 합 타입에서 total하지 않은 필드도 허용하지 않는 수준이다. 제네릭의 가장 흔한 사용 사례는 JSON 직렬화 / 역직렬화이며, 이것은 정말 좋은 보일러플레이트 생성 도구로 달성할 수 있다. 타입 레벨 프로그래밍은 대부분의 사람이 정적 타이핑 열차에서 내리는 지점이며, 컴파일러 오류 메시지가 궤도를 벗어나기 시작하는 곳이기도 하다.
_업데이트: _DeriveGeneric를 제외하는 것은, 이것이 Haskell98이나 Haskell2010의 일부가 아니긴 하지만, 많은 사람에게는 너무 과한 조치로 보인다. 나는 JSON 인코더 같은 일상적인 사용 사례에 대해 우리가 아직 충분한 대안을 탐색하지 못했다고 생각한다. 나는 타입클래스의 보일러플레이트 코드 생성을 위한 도구(ghc와 호환되는)에 관심이 있다. 예를 들면 scalaz-deriving에서 탐구한 Divisible/Decidable/Applicative/Alternative 형식주의를 따르는 방식이다. 이것은 여러 Derive* 확장을 대체할 수 있다.
또한 Haskell에는 더 근본적인 언어(그리고 그 언어는 C로부터 컴파일되는)에서 컴파일할 수 있는 신뢰할 만한 컴파일러가 필요하다고도 생각한다. 내가 찾을 수 있는 가장 유력한 주류 후보는 Scheme, Typed Racket, Swift이고, Nim과 Shen도 흥미롭다. 그렇지 않으면 언어는 역사적인 바이너리에 “갇히게” 되고, 생태계 전체가 손상되지 않았는지 검증하는 것이 불가능해진다. Joachim은 이에 대해 몇 가지 생각을 적었고, C로부터 컴파일되는 Hugs Haskell98 컴파일러를 되살리는 것도 가능할지 모른다. Hugs는 공동체가 C로 작성된 컴파일러를 유지보수하길 원하지 않는다는 점을 이미 보여 주었다. 하지만 훨씬 축소된 ghc나 처음부터 새로 만든 대안의 부트스트랩 용도로는 쓸 수 있을지도 모른다.
하지만 누가 그런 노력을 지원하겠는가? 컴파일러로 돈을 벌 수는 없으니, 자금이 조달되지 않을 것이다. 그래서 나는 슬프게도 그 컴파일러는 쓰이지 않을 것이고, 설령 쓰이더라도 대중화되지 않을 것임을 받아들여야 한다. 우리는 “많은 교육과 많은 시간과 인내”의 세계에 살고 있다.
결국 Simple Haskell은 그렇게 논쟁적인 아이디어여서는 안 된다. C 개발자들에게 gcc나 LLVM의 내부 세부 사항에 의존하는 대신 C18 표준만 지키라고 말하는 상황을 상상해 보라. Haskell에서 아무도 그렇게 하려 하지 않는 이유는 보상이 없기 때문이다. 그래서 사람들은 구현체 확장으로 손을 뻗는다.
나는 프로그래밍 언어 전도사는 아니지만, 이것만은 말하겠다. 당신이 의사결정권자이고, 당신 팀이 다음 프로젝트에 Haskell을 기꺼이 쓰고 싶어 한다면, 그 제안에 열린 태도를 보여 달라. 팀의 성격 구성이 잘 섞여 있는지 확인하고, Simple Haskell을 지키도록 요청하라. 그러면 결과에 기분 좋게 놀랄 수도 있다. 덤으로 지금은 접근하지 못하는 놀라운 인재를 끌어들일 수도 있을 것이다!
363
363
5
팔로우
팔로우
응답 작성
취소
응답
참고로: F#에 관해서. 나는 SML/NJ와 F#로 처음 기초를 다졌지만, 이제는 꼭 F#의 팬은 아니다. F#에서 가장 크게 실망한 점은 Haskell처럼 순수하지 않다는 것이고, 그것이 온갖 문제를 열어 둔다는 점이다… 물론 Visual의 F# 디버거는…더보기
--
답글
나는 Haskell을 거의 이해하지 못하지만, 당신 의견에 대체로 동의한다. 집에서 재미로 Haskell을 쓰거나 직장에서 “스크립팅” 용도로 쓸 때, 나는 그저 가능한 한 가장 쉬운 접근을 택한다.
안타깝게도 여전히 너무 많은 사람이 Haskell이 배우고 쓰기 어렵다고 생각한다. 그것은…더보기
--
답글
PureScript를 살펴보셨나요? 아주 좋습니다.
--
답글
모든 응답 보기
## 극축 정렬의 수학 ### 나는 최근 내 오픈 소스 천문학 도구 luddcam에 극축 정렬 기능을 추가했고, 그 과정에서 재미있는 토끼굴로 빠져들었기에 여기 기록해 둔다…
3월 24일
2일 전
## 오픈 소스에서 실명을 숨기세요 ### 오픈 소스에 기여할 생각이라면, 그것이 당신의 경력에 미칠 수 있는 부정적 영향을 잠시 생각해 보세요…
2018년 9월 19일
In
작성자
## Scala는 거의 성공했었다 ### 그리고 지금도 그럴 수 있다
2019년 8월 25일
In
작성자
3월 21일
In
작성자
3월 18일
In
작성자
2일 전
In
작성자
## 신경과학자로서 나는 당신의 뇌를 망치는 이 5가지 아침 습관을 끊었다 ### 대부분의 사람은 깨어난 지 10분 안에 1번을 한다. 그리고 그것이 하루 전체를 망친다
1월 14일
In
작성자
3월 20일
In
작성자
## “신은 주사위 놀이를 하지 않는다” — Einstein이 실제로 뜻한 바 ### Einstein은 수학은 받아들였지만, 그 이야기는 받아들이지 않았다.
3월 23일
