Qiita에 로그인해서 유용한 기능을 사용해 보세요
당신에게 맞는 글을 추천해 드립니다.
유용한 정보를 나중에 다시 읽을 수 있습니다.
281
좋아요한 사용자 목록 보기
127
X(Twitter)로 공유
Facebook으로 공유
Hatena 북마크에 추가
기사 삭제
삭제된 기사는 복구할 수 없습니다.
이 글의 초안도 함께 삭제됩니다.
정말로 이 글을 삭제하시겠습니까?
최종 업데이트로부터 3년 이상 지났습니다.
시작하며
제가 Haskell을 쓰기 시작한 지 어느덧 10년이 다 되어 갑니다. (제목은 조금 과장했네요)
그동안 사용해 온 소감을 정리합니다.
Haskell의 힘든 점
먼저 하소연부터 하겠습니다.
컴파일이 느리다
- 의존 모듈은 모두 소스 코드에서 빌드해야 합니다. (바이너리 형식 모듈은 없습니다)
- 첫 빌드에 20분쯤 기다리는 일은 흔합니다.
- 복잡한 타입 시스템을 쓰면 타입 추론이나 타입 레벨 계산에 시간이 걸립니다.
- 빠른 Haskell 프로그램을 쓰려면 많은 함수를 인라인화해야 합니다. 최적화 빌드에서는 인라인 전개로 코드 크기가 커지므로 시간이 더 걸립니다.
디버깅이 어렵다
- 공식 GHCi 디버거가 있긴 하지만, 아직 IDE에서 간편하게 쓸 수 있는 수준은 아니고, 컴파일된 라이브러리는 디버깅할 수 없습니다.
- 최근에는 스택 트레이스도 뽑을 수 있게 되었지만, 코딩에 신경 쓰지 않으면 그다지 유익한 정보를 얻기 어렵습니다.
- 기본은 printf 디버깅에 의존하게 되는데, 다형 함수의 인자는
Show가 안 되는 경우가 많아 디버깅을 위해 타입 제약을 추가하는 것도 번거롭습니다.
- 리소스 누수나 메모리 누수를 특정하는 일은 더욱 어렵습니다. (그리고 꽤 자주 발생합니다)
프로파일링이 어렵다
- 프로파일을 활성화하려면 의존 모듈을 포함해 재컴파일이 필요합니다. (샤워를 하거나, 우버이츠라도 시켜 놓고 기다립시다)
- 프로파일 실행은 보통보다 2~3배 느려집니다.
- 프로파일을 활성화하면 최적화가 먹히지 않아 진짜 병목을 파악하기 어려울 때가 있습니다.
- 썽크(thunk)가 쌓여 있으면 프로파일은 종종 거짓을 말합니다. 적절한 경계에서 썽크를 평가합시다.
테스트를 쓰기 어렵다
- (순수 함수의 테스트는 쓰기 쉽습니다. QuickCheck도 훌륭하다고 생각합니다.)
- 함수의 구현을 덮어쓸 수 없으므로, 테스트를 쓰기 쉽도록 구조를 미리 고민해서 작성해야 합니다.
String 타입이 느리다
- String 타입은 Haskell 최대의 설계 실수입니다.
- 문자 하나에 40바이트를 소비해서 방심하면 금세 병목이 됩니다.
- 우선
Data.Text를 쓰면 대체로 문제없다고 봅니다.
- 하지만 표시하고 싶은 타입이
Show만 사용할 수 있는 경우도 많아 괴롭습니다.
문자열 타입은 도대체 몇 개인가요
- Haskell의 문자열 타입: 분류와 특징에 따르면 11종류나 된다고 합니다.
- 앞서 말했듯 가장 표준처럼 보이는
String이 가장 문제아인 것도 괴롭습니다.
- Backpack(참고)이라는 걸로 해결할 수 있다고 들었는데, 그다지 쓰인다는 얘기를 못 듣네요. 아시는 분이 있으면 알려주세요.
언어 확장이 너무 많다
- 여러분의 터미널에서
ghc --supported-languages | grep -v '^No' | wc -w를 실행해 보세요. 몇 개가 나오나요? 제 환경에선 무려 125개였습니다.
- 반드시 써야 할 것, 주의해서 써야 할 것, 이미 레거시가 된 것들이 뒤섞여 있어 초보자에게 친절하지 않습니다.
- 마지막 언어 사양은 Haskell2010입니다. 11년이나 지나니 실제로 쓰이는 확장과의 괴리가 큽니다.
‘쓸 만한’ 라이브러리가 적다
- 그럭저럭 라이브러리는 풍부하지만, ‘쓸 만한’ 라이브러리인지 판단하기 어렵습니다.
- 유명 라이브러리도 메인테이너가 적어 업데이트 속도가 느립니다. (마이너 언어의 숙명이지요)
그럼에도 왜 Haskell을 쓰는가
여기까지 여러 불만을 늘어놓았지만, 저는 Haskell이 더할 나위 없이 훌륭한 언어라고 생각합니다.
실용 언어 중 최강급의 타입 시스템
- GHC의 타입 시스템은 정말 강력해서, 타입을 잘 설계하면 그에 이끌리듯 올바른 프로그램을 작성할 수 있습니다.
- 복잡한 데이터 타입도
unsafeCoerce를 거의 쓰지 않고 표현할 수 있습니다. (동적 타이핑마저도!)
- 프로그램의 사양 변경도 대개는 타입을 바꾸고 타입 에러를 고치면 돌아갑니다.
참조 투명성
- 변수의 값이 결코 변하지 않는다는 성질은 리팩터링 시 큰 안도감을 줍니다.
- 참조 투명이기에 가능한 퓨전 변환(참고)을 능숙하게 다룰 때의 전능감은 각별합니다.
단순한 문법과 깊이
-
Haskell의 항은 본질적으로 함수이거나 패턴 매치일 뿐입니다. 그 외는 모두 설탕 문법입니다.
- GHC의 Core 언어 AST에도 9종류의 생성자만 있다고 합니다. (참고)
-
고차 함수를 쓰면 어떤 공통된 부분이든 뽑아 DRY할 수 있습니다. 이는 Haskell(계 언어) 외에는 좀처럼 맛보기 어려운 경험입니다.
-
문법의 단순함과는 달리 해마다 새로운 프로그래밍 기법과 언어 확장이 태어나고 있습니다. 제가 아는 범위만 해도 다음과 같은 신기술이 나왔습니다. 공부가 지루할 틈이 없습니다.
-
라이브러리
- Lens
- Free/Operational Monad
- Functional Reactive Programming
- Iteratee/Conduit
- Extensible Effects
-
언어 확장
- TypeFamilies
- DataKinds
- OverloadedLabels
- LinearTypes
- PatternSynonyms
앞으로
안타깝지만 Haskell이 Rust처럼 성공을 거두는 일은 앞으로도 없을 것입니다.
하지만 Haskell의 발전은 멈출 기미가 없고, Haskell에서 태어난 프로그래밍 기법이 다른 언어에도 흡수되어 갈 것입니다.
평생 파고들 수 있는 언어라는 점은 자신 있게 보증할 수 있습니다.
이 글을 읽고 Haskell에 관심을 가져 주는 분이 늘면 좋겠습니다.
또한 야생의 Haskeller 여러분의 마사카리(매서운 태클)도 기다리고 있습니다.
281
좋아요한 사용자 목록 보기
127
X(Twitter)로 공유
Facebook으로 공유
Hatena 북마크에 추가
신규 가입하고 Qiita를 더 편리하게 이용하세요
- 니즈에 맞는 글을 받아볼 수 있습니다
- 유용한 정보를 효율적으로 다시 읽을 수 있습니다
- 다크 테마를 사용할 수 있습니다
회원 가입으로 할 수 있는 일
Qiita Conference 2025 Autumn 개최!: 11/5(수) - 11/7(금)
Qiita Conference는 AI 시대의 엔지니어를 위한 Qiita 최대 규모 테크 컨퍼런스입니다!
기조 연사
piacere, Tsuyoshi Ushio, Esteban Suarez, Takuto Wada, seya, MinoDriven, Toshihiro Ichitani, Karaage, Yoshimasa Iwase, Matz, Minorun 등…
이벤트 상세 보기
281
좋아요한 사용자 목록 보기
127
기사 삭제
삭제된 기사는 복구할 수 없습니다.
이 글의 초안도 함께 삭제됩니다.
정말로 이 글을 삭제하시겠습니까?
