Haskell을 처음 접하는 사람들이 더 즐겁고 효과적으로 배우기 위한 동기 설정, 학습 태도, 타입클래스 사용, 실용적인 프로젝트 선택에 대한 조언을 정리한다.
Haskell for all: Haskell 초보자를 위한 조언
===============
===============
이 글은 Haskell을 어떻게 배우기 시작해야 하는지 묻는 초보자들에게 내가 자주 해 주는 조언을 정리한 것이다.
먼저, 전반적으로는 Haskell Programming from first principles 책을 읽기를 권한다. 이 책은 Haskell을 가르칠 때 중요 디테일을 생략하지 않고, 이해를 점검해 볼 수 있는 충분한 연습문제까지 제공한다. Haskell이 첫 프로그래밍 언어라면 보통 이 정도로도 충분하다.
다만, 다른 프로그래밍 언어를 해 오다가 Haskell에 접근하는 사람들에게 몇 가지 추가 팁을 더하고 싶다.
어떤 사람들은 Haskell을 배우면 일종의 프로그래밍 깨달음이나 니르바나에 도달할 거라 기대한다. 만약 그런 비현실적인 기대를 갖고 언어에 임한다면 실망할 것이다. 학습은 결승선이 아니라 끝이 없는 과정이므로 Haskell은 잠금 해제할 업적이나 획득할 트로피가 아니다.
현실적인 기대치는 Haskell을 실제 문제 해결에 집중하게 해 주는, 쓰기 즐거운 언어로 대하는 것이다(널 포인터나 "undefined is not a function" 같은 스스로 만든 사소한 문제를 고치는 데 시간을 낭비하지 않게 해 준다는 점에서).
Haskell 초보자들이 흔히 하는 실수는 첫 프로그램을 쓰기 전에 언어를 최대한 많이 배우려 들고, 초안부터 과도하게 설계하는 것이다. 이렇게 하면 금방 지치게 된다.
JavaScript, Python, Ruby처럼 정적 타이핑이 없는 동적 타입 배경에서 왔을 수도 있다. 그런 환경에서는 정적 타입이 없어서 대규모 코드베이스 리팩터링을 피하는 법을 배운다. 이 리팩터링 기피는 "처음부터 큰 설계" 문화로 이어지는데, 처음 시도에서 프로젝트를 최대한 정확하게 만들려 하여 나중에 코드를 리팩터링하지 않으려는 태도다.
이건 Haskell을 배우는 데 아주 나쁜 방식이다. 이유는 두 가지. 첫째, Haskell은 대부분의 다른 언어보다 천장이 훨씬 높기 때문에 그 천장에 닿을 때까지 기다렸다가 뭔가를 만들려고 하면 아주아주아주 오래 기다리게 된다. 둘째, Haskell에서 리팩터링은 비용이 싸기 때문에 처음부터 완벽할 필요가 없다.
손을 더럽히고 실수할수록 학습 속도가 빨라진다. 보기 흉하고 민망한 코드를 과감히 쓰고, 구현을 점진적으로 다듬어라. Haskell 학습에는 지름길이 없다.
구체적으로 말하면, 언어에 충분히 익숙해질 때까지 새로운 타입클래스를 만들지 말아라.
함수형 언어가 뛰어난 이유는 많은 언어 기능이 "일급(first-class)"이기 때문이다. 예를 들어 Haskell에서는 함수와 효과가 일급이어서 리스트에 넣거나, 합성하거나, 중첩하거나, 인자로 전달할 수 있다. 이는 많은 명령형 언어에서는 (쉽게) 할 수 없는 일이다.
하지만 타입클래스는 일급이 아니다. 따라서 이를 과도하게 사용하면 간단한 일도 하려면 금세 고급 언어 확장에 의존하게 된다. 용어(항) 수준에서의 함수형 프로그래밍은 타입클래스가 부추기는 타입 수준 Prolog식 프로그래밍보다 훨씬 단순하고 즐겁다.
먼저 평범한 함수와 평범한 데이터 구조로 문제를 푸는 법을 배우라. 그런 간단한 도구들로도 대부분의 유용한 문제를 푸는 법을 이해했다고 느껴질 때쯤 더 강력한 도구인 타입클래스로 넘어가도 늦지 않다. 숙련자의 손에서는 타입클래스가 상투적 보일러플레이트를 많이 줄여 주지만, 나는 이를 필수라기보다 편의 기능 정도로 여긴다.
이 접근법은 다른 함수형 언어(Elm, Clojure, Elixir, Nix 등)에도 그대로 가져갈 수 있다. "함수 + 데이터 구조"는 단순하고 이식성 높은 프로그래밍 스타일로서, Haskell이든 아니든 당신이 쓰는 모든 코드의 질을 높여 줄 것이다.
필요는 발명의 어머니다. 실제로 자신에게 필요한 것을 만들려 할 때 학습 속도는 더 빨라진다. Project Euler 문제나 스도쿠 퍼즐만 푸는 데 Haskell을 쓰면 Haskell이 쓸모없다고 스스로 금세 단정해 버릴 것이다.
또한, 한두 개의 유용한 프로젝트 포트폴리오가 있으면 Haskell 관련 일을 얻을 확률도 훨씬 높아진다. 이런 프로젝트는 Haskell 자체를 위한 학습이 아니라 무언가를 만들기 위해 Haskell을 배웠다는 증거가 된다.
부디 이 팁들이 처음 언어를 배울 때 가드레일이 되어 주길 바란다. Haskell이 완벽하다는 말은 아니지만, 흔한 초보자 함정을 피한다면 이 언어를 즐기게 될 것이라고 생각한다.
Posted by Gabriella Gonzalez at 7:45 AM
Email ThisBlogThis!X에 공유Facebook에 공유Pinterest에 공유
한 가지 빼고요: 제게 Haskell은 실제로 "프로그래밍의 깨달음"이자 "니르바나"가 되었습니다.
[Reply](javascript:;)
2. F. Scott Fitzgerald2017년 10월 16일 오후 1:12
좋은 글 감사합니다!
한 가지요 - 이렇게 쓰셨죠. "용어(항) 수준에서의 함수형 프로그래밍은 …보다 훨씬 단순하고 즐겁다"
여기서 "term-level(항 수준)"은 무슨 뜻인가요? 온라인에서 몇 가지 레퍼런스를 찾긴 했지만 의미를 제대로 설명해 준 것은 없었습니다.
1.  [Jean-Baptiste](https://www.blogger.com/profile/12716925683997212397)[2017년 10월 16일 오후 2:27](https://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html?showComment=1508189230440#c6295291257005953761)
제 생각엔 값과 함수로 프로그래밍한다는 뜻일 겁니다. "타입 수준" 프로그래밍과 대비되는 개념이죠.
[Reply](javascript:;)
2.  [libeako](https://www.blogger.com/profile/01584915094701732892)[2017년 10월 16일 오후 3:03](https://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html?showComment=1508191437475#c7848738151498745959)
백그라운드에서 "사전(dictionaries)"로 타입클래스가 암묵적으로 하는 일을 명시적으로 하는 것이죠:
http://www.haskellforall.com/2012/05/scrap-your-type-classes.html
[Reply](javascript:;)
3.  [Gabriella Gonzalez](https://www.blogger.com/profile/01917800488530923694)[2017년 10월 16일 오후 3:58](https://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html?showComment=1508194686933#c8193560424074395933)
"terms(항)"는 보통 "타입이나 kind가 아닌 어떤 것"을 가리킵니다. 예를 들어 숫자 "1"은 항이고, "length" 함수도 항이죠. 그래서 "항 수준(term-level)" 프로그래밍은 "타입 수준 프로그래밍이 아닌" 것을 의미합니다.
[Reply](javascript:;)
1.  [Unknown](https://www.blogger.com/profile/12406928909368367691)[2017년 10월 17일 오전 6:49](https://www.haskellforall.com/2017/10/advice-for-haskell-beginners.html?showComment=1508248193675#c8807599956054797467)
저도 Project Euler 문제를 풀면서 Haskell에 발을 담갔습니다.
저자는 그 단계에서 멈추지 말고 더 깊이 언어를 배워야 한다는 점을 강조하는 것 같아요.
[Reply](javascript:;)
[Reply](javascript:;)
5. Hassan Shahin2017년 11월 15일 오전 11:35
좋은 글 정말 감사합니다. 개인적으로 특히 흥미로웠던 부분은 "Big-design-up-front를 피하라"입니다. "큰 아이디어"(자신에게 그런 아이디어가 있다고 생각하는) 사람들은 Haskell이 매우 강력한 언어라는 것을 여기저기에서 읽고 알게 되죠. 그러고는 기초를 조금 배우자마자(그들의 큰 아이디어를 들고) 구현을 시작하려 하고… 큰 벽에 부딪힙니다. 그 아이디어에는 엄청난 작업이 필요하거든요. 결과는 좌절감 등등입니다.
이 조언은 정말 귀중합니다. 다시 한 번 감사합니다.
[Reply](javascript:;)
구독: 댓글 게시물(Atom)
이 저작물은 Creative Commons Attribution 4.0 International License에 따라 이용할 수 있습니다. Simple theme. Powered by Blogger.