Search Results for '헤스켈'

4 POSTS

  1. 2008.04.30 Crossing borders (2)
  2. 2007.05.20 Haskell 독서중. (2)
  3. 2007.05.18 Haskell에 대한 오해?
  4. 2006.10.08 Dynamic Typing과 Test Driven Development (6)

Crossing borders

Posted 2008.04.30 16:47
IBM dW의 연재 중에 Crossing borders는 프로그래밍 언어와 기술 간의 경계를 뛰어넘어 새로운 세계를 맛 보자는 뜻으로, 다양한 함수 언어를 소개하고 있습니다.

헤스켈 소개

Crossing borders: Explore functional programming with Haskell


얼랑 소개

Crossing borders: Concurrent programming with Erlang


비함수형 개발자에게 함수 언어의 개념을 소개하는 것은 비교적 쉽습니다만, 그 다음 단계인 함수 언어로 실제 어플리케이션을 작성하는 일과는 상당한 괴리가 있는 것으로 보입니다. 저 역시 함수 언어에 관심 갖고 공부해온 지가 꽤 오래되었지만 비교적 최근에서야 업무를 비롯해서 시험적으로 조금씩 써보는 정도거든요.

특히, 함수 언어를 실제 어플리케이션 작성에 쓰기 위해 반드시 풀어야할 문제는 IO, 외부 함수 호출, 동시성(concurrency) 등인 것 같습니다. Real World Haskell은 Haskell로 연습 문제만 풀지 말고 실제 어플리케이션을 작성할 수 있도록 가이드하자는 취지해서 작성되고 있는 책인데, 얼마나 성공적일지 지켜봐야겠습니다.


신고

Haskell 독서중.

Posted 2007.05.20 06:46
주말 동안에 Haskell, The Craft of Functional ProgrammingThe Haskell School of Expression을 열심히 읽고 있습니다. 2001년도에 프로그래밍 언어(PL) 수업 들으면서 한참 함수형 언어에 빠져들어서 샀던 책인데, 최근에 다시 한 번 읽어보는 중입니다.

최근 프로젝트에서 파이썬을 주 언어로 사용하고 있는데, 제대로 된 타입 시스템이 없는 파이썬 코드에 영 적응이 안 되던 차에 강력한 타입 시스템을 제공하는 헤스켈에 대한 향수가 생겼달까요.

그때만 해도 컨셉은 좋지만 실용적으로 쓰기에는 무리라고 판단을 내렸었는데, 다시 보는 헤스켈이 생각보다 성능이 좋군요. 헤스켈을 바이너리로 컴파일해 주는 GHC(Glasgow Haskell Compiler)의 성능도 상당히 향상된 것으로 보이고요.

심볼 연산(symbolic computation)이 주가 되는 실무에 일부 활용해 보려고 고민 중인데, 관련 소식을 업데이트 하겠습니다.

신고

Haskell에 대한 오해?

Posted 2007.05.18 04:57
현대 함수형 언어의 대표격인 Haskell은 이제 대부분 개발자가 이름 정도는 들어본 언어가 되었죠?
그리고 Haskell의 강력함을 소개하는 예제로 빠지지 않고 등장하는 것이 바로 C 언어로 정확하게 구현하려면, 머리 잡아 뜯으며 디버깅해야 한다는 퀵소트(QuickSort)를 다음과 같이 매우 직관적이고 손쉽게 할 수 있다는 것이죠.

사용자 삽입 이미지

위 간단한 예제는 Haskell의 List Comprehension이나 Generic Recursion 같은 함수 언어 특유의 여러 특징을 잘 보여줍니다.

그런데 요즘 주변 친구들에게 Haskell 언어 아냐고 물어보면 이런 대답이 돌아옵니다. 그거 퀵소트 잘하는 언어 아냐? 그냥 퀵소트 잘하는 언어. 아무 짝에도 쓸모 없는 퀵소트만 잘하는 언어...

프로그래밍 언어도 보다 적극적인 마케팅이 필요한 시대입니다.

신고
Dynamic Typing과 관련된 글을 블로그에 Static Type Checking이란 제목으로 쓴 적이 있는데 여기서 다시 한 번 정리해 보고자 한다.

블로그를 돌아다니다보면 많은 사람들이 TDD가 Dynamic Typing하는 언어의 특징이라고 생각하고 있음을 알 수 있다. 특히 일부 파이썬/루비 팬들이 운영하는 블로그에서 TDD가 언급되면 어김없이 동적 타이핑 언어의 테스트 편리성(혹은 크게는 생산성)에 대한 이야기가 뒤따라 온다.

하지만 C/C++처럼 수십 년도 더 된 구세대 언어와, 소프트웨어 개발 방법론과 테스팅에 대한 어느정도 이해가 쌓인 후에 나온 파이썬/루비와 같은 언어를 정적/동적 타이핑 면에서만 놓고 비교하는 것은 공정하지 못한다. 사실 너무 불공평하다.

파이썬/루비와 정반대 선상에서 정적 타입핑의 극상을 달리는 친구들은 ML과 Haskell 같은 함수형 언어(functional)들인데, 이 놈들은 C/C++ 보다 더 엄격하게 컴파일 타임에 타입 검사를 한다. 하지만 이쪽 언어 사용자들의 주장에 따르면 ML과 Haskell은 절대 테스트하기 불편한 언어도 아니고, 코드 길이가 길거나 생산성이 떨어지는 언어도 아니다.

순수하게 타이핑 측면에서만 바라본다면, 동적 타이핑은 컴파일 타임에 해주는 검사가 적은만큼(상당히 귀납적이다) 테스트를 통해 더 많은 버그를 찾아내야 하므로, 테스트를 훨씬 더 철저하게 많이 해야 한다. 잘못된 타입 연산 등의 간단한 버그 조차도 테스트를 통해서만 발견할 수 있다는 것은 재앙이다(타입 검사는 연역적이다)

테스트의 부담이 더 큰 파이썬/루비 같은 동적 타이핑 언어가 테스트를 강조하는 것은 당연한 일이다. 같은 기능을 하는 다른 프로그램 보다 더 많은 테스트를 해야 프로그램이 제대로 동작하기 때문이다. 즉 원래 언어적인 측면에서 태생적인 약점이 있으므로, 후천적인 노력으로 개선을 한 셈이다.

파이썬과 루비 같은 동적 타이핑하는 스크립트 언어의 테스트 편리성은 동적 타이핑이라는 속성에 기인한 것이 아니다. 이는 언어의 추상화(abstraction) 수준과 관계가 있다. 추상화 수준이 높을수록 코드는 사람이 생각한 바(스펙)에 가까워지고, 알아보기 쉬워지며, 금방 만들 수 있다.

C 언어와 파이썬/루비의 추상화 수준은 어떻게 다를까? 간단한 통계로 C 언어 construct 하나가 보통 1-10개의 머신 인스트럭션으로 컴파일 되는 반면에, 파이썬과 루비의 construct 하나는 100-1000개 이상의 머신 인스트럭션으로 실행된다.

즉, 파이썬이나 루비 개발자가 그토록 강조하는 "가독성", "짧은 코드"는 절대로 동적 타이핑(흔히 스크립트 언어)의 특성이 아닌 셈이다. 강력한 정적 타이핑 언어인 헤스켈(Haskell)의 퀵 소트 코드를 본 적이 있다면, 타이핑은 생산성이나 테스트 편의와는 직접적인 상관 관계가 없다는 데 동의할 것이다.

qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

위 Haskell 코드는 polymorphic하다. qsort에 넘길 수 있는 타입은 >= 연산자가 정의된 list이기만 하면 된다. Haskell이 이처럼 간결한 코드를 보여줄 수 있는 이유는 파이썬/루비와 같은 수준의 추상화 레벨이면서, type inference를 통해 불필요한 타입 어노테이션을 필요를 상당히 줄였기 때문이다.

이처럼 같은 추상화 수준이라면 당연히 동적 타이핑보다는 정적 타이핑이 유리하다. 비유하자면, 타입 이론은 '사람은 모두 죽는다' '그러므로 소크라테스도 죽는다'라고 말하는 것이고, 테스트는 'A도 죽었고, B도 죽었고, C도 죽었으니 아마 소크라테스도 죽을 것이다'라고 말하는 셈이다.
신고

티스토리 툴바