함수형언어의 장단점은?

Bini의 이미지

작년부터 취미삼아 Clean이라는 함수형언어를 배우고 있읍니다.
배우는 재미도 있고 사고방식이 꽤 독특해서 지루하지는 않습니다만...
아직도 어떤문제에 적용해보려면 상당히 까다롭다는 느낌이 듭니다.
함수형언어에 경험이 많으신분들은 이런류의 언어에 대해서 어떻게 생각하는지
궁금합니다. 한번이야기를 들어보고 싶네요...

daybreak의 이미지

함수형 언어는 절차형 언어와 다른 시점에서 컴퓨터 프로그램을 바라본 것입니다. 여러가지 장단점이 있습니다만, 그런 것에 대해서는 구글에서 검색하면 쉽게 알수 있으실 것 같구요. 참고하실만한 것을 알려드리겠습니다.

함수형 언어로 분류되는 ML 이라는 언어가 있습니다. 미국 Carnegie Mellon University 에서 이 ML 언어로 만든 FoxNet 웹 서버가 있습니다. 관련 링크는 다음과 같습니다.

http://www-2.cs.cmu.edu/Groups/fox/

http://foxnet.cs.cmu.edu/

thedee의 이미지

저도 잘 모릅니다만...

저랑 비슷한 경험을 하고 계시는군요.
저도 리스프라는 언어를 공부해 보려고 하는데
문법에는 좀 익숙해진 거 같은데 적응하기가 쉽지 않더군요.
프로시저형하고는 개념이 좀 다르니까 익숙해질 시간이
필요할 거 같다는 생각을 하고 있습니다.

ageldama의 이미지

저도 경험은 적지만 관심이 가서 몇자 적어볼랍니당.

기본적으로 근래의 함수형 언어들은 '프로그래머의 생각과 실제코드구현과의 갭을 줄인다'....라고하데요.
하스켈도 표현중심의 그런 것이라고도 하는 것 같구요.
하지만 오히려 imperative하게 문제를 해결하는데 익숙해져서
그런지 저도 함수형 언어가 더 어렵게 느껴집니다.

기본적으로 함수형 언어들과 일반적인 언어들의 소개에 대해서 들어보면
그다지 다를 것도 없다고 느껴집니다.
더나은 표현방식, 그리고 또 추상적으로 사고하는 도구로서의 기능 .
그리고 확실히 다른 점은 부수효과(이렇게 번역하는게 맞나요? side-effect)가 없다는 점.
(CL같은 것들은 모르겠지만, 확실히 대부분의 함수형 언어들은 이렇게 되죠?)

이런건 다른데서 써있는것들이고-_-;;;
제가 생각하는것은 c(극과 극의 비교 대상이지만;;;)로 제가 뭔가 끄적일때는
확실히 '이 부분은 좀 더 재사용할 수도 있는데'라거나
어쩐지 다시 작성하기도 그렇고한 중복되는 부분들...
함수형 언어의 기본적으로 제공되는 함수들은 참 부분부분이 작게 구성되어있죠?
그래서인지 또 함수들 단위로 자연스럽게 재사용할 수 있구요.
(흔히 얘기하는 HOF같은 것들)

C++의 generic플밍이나 기타 다른 분덜이 작성한 함수형 언어등의 코드를 볼때 그런 생각이 듭니다.

----
The future is here. It's just not widely distributed yet.
- William Gibson

불량도ㅐㅈㅣ의 이미지

Quote:
그리고 확실히 다른 점은 부수효과(이렇게 번역하는게 맞나요? side-effect)가 없다는 점.

side-effect 는 부수효과라기는 보단 역효과라고 해석해야겠죠.

문근영 너무 귀여워~~

thedee의 이미지

부수 작용이 맞을 겁니다.

함수형 프로그래밍이란, 간단하게 말하면 함수값 즉, 리턴값에 주로
의존하는 프로그래밍 방식입니다. 그런데 예를 들면 printf같은 함수는
의미있는 리턴값이 없습니다. 이 함수의 기능은 값을 프린트하는
것이죠. 함수의 이런 기능을 부수 작용이라고 합니다. - 좀 엄격하게
보자면 이런 루틴은 함수가 아니라 프로시저라고 말할 수 있겠죠.

많은 C 언어의 함수들은 포인터를 건드리는 조작을 합니다. 이 역시
대표적인 부수 작용에 해당합니다. 그러나 함수형 프로그래밍에서는
이러한 조작을 최소화하려 하지요.

netkid의 이미지

함수형을 포괄적의미로 받아들이면, 함수형 언어 아닌게 없습니다.
대표적으로 함수를 이용한 구조적 언어인 c가 있겠죠!!
그런데, ocaml과 같이 ml 계열 또는 python같은 언어에서 얘기하는 함수형 플밍 이란 포괄적 의미의 함수가 아니라 "집합 함수"를 쉽게 잘 다룰 수 있게 되어 있다는 의미 입니다.
만약 집함 A,B로 C라는 결과 집합을 만들어내는 플링을 한다면, 기존언어는 각각의 값 항목 하나하나 처리하는 플밍을 해야하지만, 함수형언어는 수학에서 처럼 집합을 하나의 값처럼 처리하면 된다는 것입니다.
예) "A = B+ C" <- 편하죠 !!
그런데 집합 함수형 언어는 결정적인 단점이 있습니다. 집합을 하나의 추상적 값으로 다루기 위해서 일반적으로 모든 값이(기본 리터럴 타입 까지) 레퍼런스로 다루어 집니다. 때문에 참조 작업에 의한 오버헤드가 발생하여 필연적인 성능저하가 발생하게 됩니다.

함수형 플밍 언어가 딱 집합함수 특징만이 아니라 논리 연산만을 이용한 조건문이나 루프문을 구현하는 것을 의미하기도 하지만 이런 것은 기존 언어와 특별히 구별되는 특징은 아닌것 같습니다.

다시 말하면 ml, ocaml, python, haskel 등에서 얘기하는 "함수형 언어"는 정확하게 표현한다면 "집합 함수형 언어"라고 해야 할 것 같습니다.

불행이도 매우 많은 경우 용어의 의미 전달의 불명확성으로 새로운 지식을 습득하는데, 어려움을 낳는 것 같습니다. :cry:

달리나음의 이미지

집합 함수라는 것이 올바른 단어라고 생각하지 않습니다. 함수형 언어를 함수형 언어라고 부르는 이유는 first-class function을 사용하기 때문입니다. first-class function이기 때문에 자유롭게 함수를 생성하고 주고 반환할 수 있어, 더 높은 단계의 추상화가 가능하고 프로그램의 복잡도를 낮출 수 있습니다.

thedee의 이미지

굉장히 혼란스럽군요...-.-

제가 앞에서 말한 함수형 프로그래밍이란 물론 functional programming
을 뜻합니다. 그에 반해 C와 같은 언어는 명령형, 그러니까 imperative
에 해당합니다. 둘은 아주 다른 개념입니다. 함수를 사용한다고
함수형이란 명칭을 붙인 것이 아니라는 건 잘 아시리라 생각합니다.

역사적으로 함수형 프로그래밍의 기원은 바쿠스에게서 찾을 수 있고,
바쿠스의 fp는 처치의 람다 계산에서 나왔습니다. 처치의 람다 계산의
핵심은 함수의 연속적인 적용이구요.

당시 바쿠스가 제기한 문제는 다음과 같습니다.
벡터의 내적 문제인데요...

c:= 0
for i := 1 step 1 until n do
c:= c + a[i] * b[i]

여기서 요점은 c와 같은 임시변수가 왜 필요하냐는 것이죠.
c의 존재가 의미하는 것은 프로그래머가 벡터의 내적을
구하면서 메모리 셀을 참조해야 한다는 것이겠죠.
(머신의 내부 상태를 참조해야 한다는...)

바쿠스는 대안으로 다음과 같은 정의를 제시합니다.

Def Innerproduct = (Insert +)(ApplyToAll *)(Transpose)

즉, (벡터의 각 항을 뽑아서) (* 연산을 적용하고) ( + 연산을
적용)하는 것이죠.

Common Lisp로 표현하자면,

(apply #'+ (mapcar #'* v1 v2))

이렇게 됩니다.

이 예로 명령형과 함수형의 차이를 잘 알 수 있을 것입니다.
즉, 명령형은 이 셀에 어떤 값을 넣고, 저 셀에 어떤 값을 넣고...
이런 걸 죽 지시하는 방식이지만, 함수형은 인간의 사고 과정 그대로
문제를 기술하게끔 합니다.
함수형에서 사이드 이펙트를 가급적 피하려 한다는 의미는,
프로그래밍 과정에서 메모리에 직접적인 조작을 피한다는 뜻이고요,
비슷한 맥락으로 문제 해결 과정에서 머신의 내부 상태를 고려하지
않아도 된다는 뜻이기도 합니다. -그러므로 추상적인 프로그래밍에
강할 수 밖에 없고요... 동전의 양면이죠.

음... 집합 함수형이라... 그런 용어도 쓰는가 보죠? 대표적인 함수형
언어로 꼽히는 리스프는 리스트 프로세서란 의미이지요. 당연히
리스트 조작 함수가 많구요. 다른 함수형 언어에서는 그런 걸 집합
함수라고 하는가요? - 제 알기로 set과 list는 분명 다른 거 같거든요.
set에는 순서가 없지 않나요? list에는 있구요. 그러므로 집합은 중복을
허용하지 않지만 리스트는 허용하구요.

글구... 파이썬도 함수형 프로그래밍 언어에 포함시키나요?
파이썬이 람다 연산을 지원한다는 것은 알고 있지만 함수형으로 보는 건
좀 무리일 듯 싶습니다.-개인 의견.

kyagrd의 이미지

파이썬 커뮤니티에서는 사실상 함수형 패러다임을 적극적으로 지원하려 하지도 않는 것 같습니다. 그걸 단적으로 볼 수 있는 것이 대부분의 구현에서 tail call optimization을 하려 들지 않는다는 겁니다 (심지어 gcc같은 C 컴파일러들도 tail call optimization은 지원하는데 말이죠). 이는 되돌기(recursion)을 장려하지 않고 반복문 중심으로 상태를 바꿔 나가는 프로그래밍 모델만을 지원하겠다는 뜻입니다. 함수형 패러다임을 진지하게 받아들이는 언어에서는 언어 구현에서 tail call optimization을 지원하는 건 기본 중의 기본이죠.

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

ageldama의 이미지

파이썬은 '괄호없는 리습'이라고들하데요.
뭐 실제로 그렇다는 얘기는 아닐테고(그럼 뭐 사실 함수형언어라는 것도 아니지만^^;; )
제 생각엔 cl등의 그것같은 연산자 오버로딩이나 그밖에 모양새나
그리고 뭐 문화적인 그런 것도 포함되서 그렇게들 말하는게 아닐까...하고 감히 생각을;;; 쿨럭;;;
(혹시 '기능적 플밍'이란 의미로?;;;)

----
The future is here. It's just not widely distributed yet.
- William Gibson

netkid의 이미지

또한 객제지향 언어이기도 하고요.
아래 IBM 개발자 사이트에 가시면 파이썬의 함수플밍 특성에 관해 나와있으니 참고 하세요.
http://www-903.ibm.com/developerworks/kr/linux/library/l-prog.html#1

님의 주장과 제 주장이 서로 상반되지 않는 다는 걸 아셔야 할 것 같습니다.
님이 주장하시는 것은 함수형 언어란 함수의 연속적으로 적용하는 것이라고 하였는데, 그 표현은 맞는지 모르겠지만 의미하는 바로 볼때 맞는 말입니다! 그러나 , 과연 함수의 연속인지 단순 수식의 연속인 인지 구분에 모호함이 큽니다. 수식의 연속은 대부분의 언어들이 어느 정도 이상 지원하기 때문에 함수형 언어의 특징이 구별되기 어렵게 하는 것이기도 합니다.

제가 앞에서 언급한것이 함수형 언어의 집합함수, 루프,조건 구문에 대한 것 입니다. 이것은 결국 님이 주장한 함수의 연속 적용에 의한 결과입니다. 집합함수 처리와 수식의 연속에 의한 처리에 차이 점이라면 연속적용이 겉으로 들어나는 가 아닌가의 차이가 있다고 하겠습니다.
그런데 님의 주장은 함수에 의한 루프,조건 구문같은 겉으로 들어나는 수식의 연속에 무게를 두는 것 같습니다. 여기에 문제가 있는데 겉으로 들어나는 수식의 연속은 다른 언어와 구별하기 어려운 부분이라는 겁니다. 그에 비해 집합(리스트, 튜플, 사전 등)함수는 구현방식(how)이 겉으로 드러나지않고 사람의 직관을 그대로 표현하면서 결과(what)를 돌려 준다는 것입니다. 즉 수식의 처리 과정보다는 수학에서와 같이 목적을 위한 논리의 표현에 중점을 둔다는 겁니다. 이 부분이 c와 같은 다른 언어와 구별 되는 특징일 겁니다.

그리고 모든 언어가 함수형 특징을 가지고 있다고 봐야합니다. 님의 말대로 c는 명령형 입니다. 그렇지만, 구조적 언어이기도 하고 스트럭처와 레퍼런스(object) 타입과 유사한 포인터도 가지고 있는 객체지향적 특성도 가지고 있고, 함수를 정의하여 구현이 드러나지않고 직관적으로 결과를 돌려주거나, 함수들을 하나의 수식에 연속조합하여 복잡한 과정을 드러나지 않고 매우 단순한 논리의 표현만으로 결과를 낼수 있는 함수적 프로그래밍 특성도 가지고 있습니다.

대부분의 언어를 구별하는 것은 절대적이 아닌 상대적 개념입니다. 베이직처럼 절차적 언어라고 하고, c가 구조적 언어라고한다고, c가 절차적언어가 아닌것이 아니고, java가 객체지향 언어라고 구조적/절차적 언어가 아닌것이 아닌것에 비추어 볼때, 언어의 특징을 구분하는데 있어 그 명칭의 사전적 의미에 집착하기 보다는 각 언어의 유사성에 내포된 상대적 차이에서 의미를 찾는 것이 옳을 겁니다.

집합 함수형의 특징
예) X, Y는 리스트로 입니다. 리스트,튜플,사전 모두 집합의 종류입니다.
X= [1,2,3,4,5]
Y= map(lambda i:i*i, X)
위의 식은 파이썬에서 집합 연산 수행하는 것으로 C++에 인라인 함수와 유사한 lambda 함수식과 내장함수map으로 반복되는 절차구현 없이 집합 Y=X^2를 처리한겁니다.

semmal의 이미지

펑셔날을 구분하는 중요한 잣대는 lambda-calulus를 기본으로 하고, 그 때문에 함수가 first-class여야 한다는 게 맞습니다. c나 파이선은 절대 펑셔날 언어가 될 수 없습니다.

펑셔날의 관점에서 c나 파이선의 함수는 그냥 프로시져구요. 람다를 기본으로 하고 있지도 않습니다. 기본 개념자체가 다른데 어찌어찌 보이는게 비슷하다고 다 같은게 아니죠.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

thedee의 이미지

파이썬을 매크로 없는 리스프라고도 합니다.^^

그리고 CL를 함수형 언어라고 부르기도 힘듭니다.
멀티 패러다임 언어라고들 하죠.
ml같은 언어들을 제가 접해 보지 않았는데 그게 순수 함수형
언어인가요? CL같은 언어는 굉장히 어글리한 언어이고(라고들 하고),
순수 함수형 언어는 아닙니다.

언어들은 서로를 많이 닮을 수 밖에 없는 거라고 생각합니다.
서로의 장점을 수렴해 가는 거죠. 그러니 파이썬에 함수형 특성을
가미하거나 CL에 명령형 요소를 도입하는 건 전혀 어색하지 않은
일이라고 봅니다.
이런 식의 엄격한 분리를 제가 말한 것은 아닙니다.

함수형 프로그래밍이란 수식의 연속적인 적용하고는 아무 상관이
없습니다. 그렇다면 수식을 사용하되, 임시 변수 두지 않고 연산을
첩첩히 쌓으면 그게 바로 함수형 플밍이 되어 버립니다.^^

함수의 연속적 적용은 좀 더 범용적인 접근 방법을 의미합니다.
함수형 플밍에서는 값을 여러 개 리턴받을 수 있고 함수도 하나의
객체로 넘겨지고 리턴될 수 있어야 합니다. 물론 C에서도 그렇게 할 수
있습니다. 그러나 포인터나 포인터 함수를 사용해야 하죠.
그러나 이런 게 사이드 이펙트고 함수형 플밍에서 피하려 하는 거죠.

글구 님께서 집합 함수라고 하신 함수들의 의미를 알겠습니다.
함수형 패러다임을 지원하는 언어들에서 널리 사용되는 함수들이죠.
그러나 여전히...

>반복되는 절차구현 없이 집합 Y=X^2를 처리한겁니다

라는 표현은 제게 어색하네요...

추)님과 저와의 관점의 차이를 알겠습니다.
님은 집합 함수들, 제 관점에서는 map형 함수를 주로 사용하는 방식을
함수형 플밍이라 하신거죠? 저는 역사적 의미 그대로 사이드 이펙트를
배제하고 함수의 연속적 적용을 통해 플밍하는 방식을 함수형 플밍이라
한 거고요.
본격적인 함수형 언어가 아닌 경우에는 map형 함수의 지원이나
람다 함수 도입, 재귀 연산의 빈번한 사용등이 함수형 패러다임을 지원
하는 방식이 될 수도 있겠다는 생각을 합니다.

ageldama의 이미지

sml도 아마 그럴거 같고, ocaml은 확실히 그러구... 그쪽도 순수한 함수형언어는 아닙니다.

올만에 토론란에서 좋은거 많이 배워갑니다^^/

----
The future is here. It's just not widely distributed yet.
- William Gibson

Bini의 이미지

뉴스그룹을 보니 대체적으로 순수함수형언어(pure functional language)를 이야기할때는
Haskell, Clean, Miranda을 지칭하는것 같더군요.
제가 지금 배우는 입장이라 잘은 모르지만 문법면에서는 Haskell과 Clean은
아주 비슷한것 같습니다.

ageldama의 이미지

그나저나 같이 haskell 공부하실분 안계신가요?;;;
쩝... 너무 허접해서 감히 같이 하자고 하기도 뭐하고;;;

m$n : indigo_yjh13 at hotmail.com

----
The future is here. It's just not widely distributed yet.
- William Gibson

kyagrd의 이미지

"하스켈로 배우는 프로그래밍"의 원서인 "Programming in Haskell"을 교재로 MS에서 운영하는 C9라는 온라인 TV채널에서 강의가 진행중입니다. 강의하는 Erik Meijer라는 분도 영어를 모국어로 구사하는 사람은 아니라서 말을 그렇게 어렵게 하진 않는 것 같습니다.

벌써 5장까지 나왔는데요, 앞으로 뒷부분 강의도 빨리 나와서 완결 봤으면 좋겠네요 ^^

1장 http://channel9.msdn.com/shows/Going+Deep/Lecture-Series-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-1/
2장 http://channel9.msdn.com/shows/Going+Deep/Lecture-Series-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-2/
3장 http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-3-of-13/
4장 http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-4-of-13/
5장 http://channel9.msdn.com/shows/Going+Deep/C9-Lectures-Dr-Erik-Meijer-Functional-Programming-Fundamentals-Chapter-5-of-13/

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

cedar의 이미지

netkid wrote:

집합 함수형의 특징
예) X, Y는 리스트로 입니다. 리스트,튜플,사전 모두 집합의 종류입니다.
X= [1,2,3,4,5]
Y= map(lambda i:i*i, X)

위의 식은 파이썬에서 집합 연산 수행하는 것으로 C++에 인라인 함수와 유사한 lambda 함수식과 내장함수map으로 반복되는 절차구현 없이 집합 Y=X^2를 처리한겁니다.

C++의 인라인 함수는 lambda 함수와는 상관이 없습니다.
단지 함수 호출이 런타임에 일어나는 것이 아니라
컴파일 타임에 확장된다는 차이뿐이죠.

참고로, 다음은 C++에서 같은 작업을 '절차 구현(즉 루프)'없이 구현하는 예제입니다. C++의 generic programming도 함수형 언어의 일부 특징을 가지고 있습니다.

//---------------------------------------------------------------------------
#include <iostream>
#include <vector>
#include <functional>
#include <numeric>
#include <algorithm>
#include <iterator>
//---------------------------------------------------------------------------

using namespace std;

int main()
{
    vector<int> X(5), Y(5);
    iota(X.begin(), X.end(), 1); // 1 2 3 4 5
    transform(X.begin(), X.end(),
              Y.begin(), multiplies<int>()); // 1 4 9 16 25
    copy(Y.begin(), Y.end(), ostream_iterator<int>(cout, " ")); // 표준 스트림에 출력
    cout << endl;
}
//---------------------------------------------------------------------------

여기서 iota, transform, copy 알고리듬(STL에서는 반복자만을 인자로 받는 함수를 이렇게 부릅니다.)과 multiplies 함수 객체는 모두 인라이닝을 사용합니다.

참고로 C++에서 lambda expression을 사용할 수 있게하는 라이브러리도 있습니다. Boost 라이브러리에 포함되어 있는
The Boost Lambda Library를 사용하면 되지요.

예를 들어 위 코드의 출력 루틴인
copy(Y.begin(), Y.end(), ostream_iterator<int>(cout, " "));
대신 lambda expression을 사용하면 다음과 같습니다.
for_each(Y.begin(), Y.end(), cout << _1 << " ");
즉, for_each를 사용할 때는 항상 귀찮은 함수 객체(function object 또는 functor) 선언이 필요하지만, lambda expression으로 간편하게 해결할 수 있지요.

netkid의 이미지

인라인 함수는 컴파일된 코드상에 생성되는 방식과 함수 호출 방식이 일반 함수와 다를 뿐 람다 함수와 다른게 맞습니다.

컴파일 후에도 바로 함수 호출 위치에 코드가 생성된는 경우와 함수를 소스 코드상 사용위치에 기입하는 경우를 혼동 했구요 ^^

jj의 이미지

대부분의 경우 코딩이 끝난후 컴파일이 에러없이 끝나면, 대부분 제가 원하는 대로 프로그램이 돌아간다는 것.

더 확실한건, 코딩하면서 생각하는게 너무 재밌다는것.

--
Life is short. damn short...

imyejin의 이미지

Programming in Haskell의 머릿글 원본

"Haskell로 프로그램 짜보니까 어떤 느낌 들어요?" http://kizoo.blogspot.com/2009/05/programming-in-haskell.html

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

magingax의 이미지

학문적인 측면은 다른분들이 설명하실꺼고..
실무적인 대규모 시스템을 개발해본 경험에서 말씀드리면..

장점은..편합니다..스트럭쳐나, 뭐 기타등등 잡스런 문제들에 신경안쓰고 바로 문제해결을 위한 알고리즘을 구현할수있습니다.
따라서 1인 생산성이 *매우* 높아집니다..

단점은..다른사람들과 공동작업이 어렵습니다. 개발자본인은 심오한 람다함수의 세계에 경탄을 금치 못하겠지만.
다른사람이 만든코드를 이해하기는..매우 어렵습니다. 세세한 문서 작성이 필수..
의외로 다른 언어로 만들어진 라이브러리 이용은 쉽습니다. FFI 를 쓰면 쉽지요..

한마디로..뛰어난 개발자 몇명이 대규모 개발팀이 할일을 해내는데 사용할때 적합합니다.
뛰어난 C 개발자는 일반 C 개발자의 3~5 배정도 생산성이 높아지지만.
뛰어난 LISP 개발자는 일반 LISP 개발자의 10~20 배까지 생산성이 높아집니다.
하지만..뛰어난 LISP 개발자의 5줄짜리 코드를 이해하는데 2시간이 넘게 걸릴수 있습니다.
(PAIP 의 Norvig 님의 코드를 보면..손발이 오글아듭니다..)

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

kyagrd의 이미지

일전에 KLDP에도 올렸습니다만 http://kldp.org/node/109173 [랑데브 모임 겸 대안 언어 강좌의 발표자를 찾습니다 (2009-12-12 토욜 오후 서울대)], 발표가 가능하다고 하셨던 분들 중에 사정상 당일에 오지 못하시게 된 분(여기 댓글 다신 분 중에 보이네요 ㅎㅎ)이 계셔서 아직 발표자를 한두 분 정도 더 찾고 있습니다. KLDP에도 리습에 대해서 열정적으로 포스딩을 하시는 분들도 몇 분 본 것 같고 리습 모임도 200명이 넘는 회원이 있는 것 같은데 혹시 magingax님이 안되시더라도 발표해 주실만한 분을 추천해 주셔도 좋고요. 그럼 감사합니다.

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

magingax의 이미지

APLAS 전에 한다는 모임이군요..좋은 기회 같아서 구경갈 생각입니다.
그런데 남앞에서 얘기할만큼 대단한 실력은 못됩니다.
좀 부끄럽기도 하고..

LISP 사용자모임
http://cafe.naver.com/lisper

LISP 사용자모임
http://cafe.naver.com/lisper
방송기술 개발업체
http://playhouseinc.co.kr

winner의 이미지

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

List Comprehension, Set Comprehension으로 map, filter의 필요성은 없어졌다지만
오히려 필요성이 사라지지 않은 reduce는 functools로 들어가버리고...

달리나음의 이미지

의도하지 않게 발견한 llist comprehension의 특성이 고차 함수들을 죽여가는 군요.

전 이 결정이 현명하다고 생각하지 않습니다. 고차 함수들을 쓴 기존의 유산들을 해치고 있습니다. 그리고 list comprehension이나 set comprehension을 쓴 기존 코드도 호환 되지 않을 가능성이 있습니다.

귀도는 리습의 유산을 이해하는 사람이 적다고 주장하고 있지만 대부분의 스크립트 언어에서 map과 reduce는 널리 통용되는 키워드이고 map-reduce 키워드도 구글, 야후에 의해 널리 알려진 키워드가 되었습니다. 귀도 자신이 인정하기 싫은 것이겠지요.

semmal의 이미지

제 생각은 list comprehension의 구현에 문제가 있는 것이지, 그 문법이 문제가 있다고 생각하지는 않습니다.

우리가 더 좋은 방법을 발견하지 못했을 뿐이죠.

"아름 다움은 첫번째 테스트다. 이 세상에는 못생긴 수학이 영원히 차지하고 들어 있을 자리가 없다". G.H. 하디

수학뿐만 아니라 프로그래밍 언어도 마찬가지라고 생각합니다.
------------------------------
How many legs does a dog have?

------------------------------
How many legs does a dog have?

imyejin의 이미지

reduce 는 안되겠지만요. 근데 조건제시문은 좋아라 하면서 왜 map 을 없애겠다는 건지 파이썬에서는 그게 왜 이슈가 되어야 하는지 함수형 언어로 주로 프로그래밍하는 저로서는 이해가 잘 안가는데, 좀 배경을 설명해 주실 수 있는 분 있나요?

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

winner의 이미지

Python이 추구하는 바를 보면 가독성을 상당히 중요시하는 것 같습니다.
그렇다고 Java나 Windows API와 같이 이름을 길게 쓰는 방식을 통해 가독성을 추구하는 것은 아니고요.

각 요소들을 잘게 쪼개는 형태로 조금이라도 어떤 내부 마법을 없애고 싶어하는 느낌이죠.
문서를 봐도 itertools 같은 것은 문서에 source code가 들어갑니다.
이 함수들은 이렇게 명확하게 작성되었다라는 것 같은 느낌이랄까?
(C++ algorithm의 문서가 그렇게 작성되었으면 좋겠다고 생각한 적이 있었는데 template source 보면
장황해서 짜증날게 뻔할 듯... 하지만 Python source라면 이야기는 다릅니다.)

lambda 역시 그냥 중첩함수 하나 작성하는게 뭐가 문제라고 그러냐라는 식입니다.
lambda를 넣어야 한다고 하니까 그럼 한줄만 쓰자, 그렇게 되었고...

List comprehension도 그런 맥락으로 filter, map을 대체해나가는 것 같고요.

Guido van Rossum은 list comprehension도 같은 맥락으로 중첩해서 쓰지 말기를 추천하는 것 같습니다.
그럴 바에는 fon in을 중첩하는게 낫다라고 생각하는 것 같더군요.

논문 쓸 때도 단문으로 알기 쉽게 적으라는게 요새 추세잖아요. 동일한 개념인 것 같습니다.

Python은 version의 주요변화(major change)가 일어날 때마다 legacy를 제거하는 것으로 많이 알려져 있습니다.
없애려고 하는 것은 그런 맥락인 것 같습니다.

% 연산자도 string.format으로 전환시키려 하더군요. 이유는 찾아봐도 잘 안 나옴... -_-.
아마도 명확성 때문인 것 같아요.

C에서 static keyword는 중의적인 요소가 많다고 말이 많은데 Python은 그런게 보이면 없앨려고 하더군요.
Python의 장점일 수도 있고, 단점일 수도 있는데 정말로 누구나 명확한 단 하나의 방식으로 작성하길 원하는 것 같아요.

저는 함수형 언어를 잘 모릅니다만 함수형 언어의 특징 중 하나인 lazy evaluation은 iterator를 통해서 지원하게 되더군요.

imyejin의 이미지

함수형 언어 중에는 Clean 이나 Haskell 처럼 lazy(또는 call by need) language도 있고 리습이나 OCaml 처럼 strict(또는 call be value) language도 있습니다. 다만 lazy evaluation을 바탕으로 하는 함수형 언어들은 대개 Clean이나 Haskell 처럼 순수 함수형 언어인 경우가 많습니다. 왜냐하면 lazy evaluation을 주로 사용하면서 상태를 마구 바꿔가는 명령형 방식의 프로그래밍을 하면 언제 상태가 바뀔지 예측하기 매우 어려워저 머리가 뽀개질지도 모르거든요.

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin

winner의 이미지

아, 참고로 map, filter 등은 Python에서 iterator를 반환하는 형태로 3.0에서 변경되었습니다.
따라서 list를 만들고자 한다면 list(map(f, L)) 을 하셔야해요.

IRC논의를 봤는데 list 반환이라고 되어 있어서...

개인적으로 Python 3.x의 가장 큰 불만은 sorted에 cmp가 빠진 것....

winner의 이미지

구현의 문제가 어떤 문제?

winner의 이미지

map, filter가 iterator를 반환하는 것으로 바뀌었기 때문인가요?

hongminhee의 이미지

해당 결정은 Python 3에 대한 것이고, Python 3는 Python 2와의 호환성이 목표에 없습니다. 기존의 유산을 해치는 결정들은 이미 print를 키워드에서 빼고 빌트인 함수로 바꾼다거나 하는 부분에서 많이 일어나버렸습니다;;;;

홍민희 (VLAAH, LangDev)

cleansugar의 이미지

Clean이라는 언어가 있었군요. 제 아이디 cleansugar와 비슷합니다.
___________________

http://blog.aaidee.com

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com