순수 객체 지향 프로그래밍 언어의 장단점은?

이 두 종류는 거의 같은 패러다임으로 프로그래밍이 진행됩니다. 즉, 함수형 언어(Haskell이나 ML같은)나 논리형 언어(Prolog나 LambdaProlog같은)와는 큰 차이가 있지만, 이 두 종류는 거의 차이가 없다고 봐도 무방합니다.

Object-Oriented라는게 사실 특별한게 아니라, 이전에 쓰던 함수나 데이터, 모듈의 확장에 불과한 것이죠.

정확히 따지자면, 오브젝트라고 하는 개념은 OO이전에 있었고, 메시지패싱은 Object가 아니라도 쓸 수 있는 기법이라서, 역시 OO가 나오기 전부터 쓰던 기법이고, 데이터 추상이나 캡슐화라고 해봐야 모듈이나 데이터 선언에서 이미 해오던 것이고, 다형성 역시 dynamic typing언어에서는 말할필요조차도 없고, 뭐 질문과는 상관없지만 static typing이라고 하더라도 객체지향보다 오히려 함수형 언어에서 보여주는 것이 더 뛰어나죠. 클래스 상속이라는 것도 더 깊게 파고들어가면 "import 모듈"에 불과한 것이고, 델리게이션이라 해봐야 "Ctrl+C, Ctrl+V"하면 해결되는 것이고, 타입 상속은 static typing에서나 소용있는 것이고, 등등...

즉 이 두 종류는 "문법"이 다릅니다. 속에 들어있는 개념은 매우 비슷합니다. 즉 하나를 제대로 알고있다면, 다른 하나를 아는게 그리 어렵지 않은 것이죠. 심하게 말하자면, 순수객체지향언어니 뭐라고 해도 그냥 손으로 해야할 일을 조금 편하게 할 수 있게 문법을 재구성한것에 불과합니다.

정말 차이가 난다고 생각할 정도라면 역시 함수형 언어나 논리형 언어를 써보면, 무엇이 정말 "차이"인지 알게 될겁니다.

요즘에 나오는 인기있는 언어는 OO패러다임, 함수형 패러다임정도는 쓸 수 있게 해줍니다. OO가 데이터 중심으로 설계를 해 나간다면, 함수형은 연산(함수) 중심으로 설계가 진행됩니다.
그나마 OO와 함수형은 "문제를 푸는" 방식으로 프로그래밍하지만, 논리형은 "문제를 증명하는" 방식으로 프로그래밍을 하기 때문에 소위 인기있는 언어중에서 논리형 패러다임이 첨가된 언어는 극히 드물지요.
어쨌든 OO와 함수형 패러다임을 같이 지원한다는건 중요한 것인데, OO만 지원하고 함수형 패러다임을 지원하지 않는 언어는 연산에 중점을 둬야하는 문제를 풀어야 하는 상황이 오면 복잡한 꼼수를 써야 해결이 가능합니다. 보통 말하는 "디자인 패턴"이 대부분 이런 경우입니다.
함수형 패러다임도 마찬가지인데 OO가 지원하지 않으면(실제로는 알맞은 이론이 정립되지 않았기때문에 지원하지 않는 경우가 대부분이죠.) 고급의 데이터 추상을 쓰기가 힘듭니다. 즉, 원래의 소스를 고치지 않고 코드를 추가하는게 어렵게 됩니다.
ruby가 세계적으로 각광받는 이유는 순수한 OO라서가 아니라, OO와 함께 함수형 패러다임을 그나마 그럭저럭 지원하는 편이기 때문이라 생각합니다.

복잡한 걸 간단하게 만드는 기법입니다.
원래 오래전부터 수학에서 써오던 개념을 그저 프로그래밍으로 옮겨놓았다고 생각하시면 됩니다.
프로시저 추상이라는 말이 있는데 이것은 프로그램이 여러 단계(또는 과정;프로세스)를 마치 하나의 프로세스 인냥 만들어서 그 복잡함을 감추는 것이라 생각하면 되겠습니다.
데이터 추상 역시 마찬가지입니다. 복잡한 데이터가 있다고 하더라도 마치 하나의 데이터인 것처럼 다룰 수 있다면 데이터 추상이 되었다고 보면 됩니다.
예를 들어서, 우리가 푸리에변환 같은 프로그램을 짠다고 생각하면 이것은 크게 몇 단계의 추상으로 이루어짐을 알 수 있습니다.
일단 임의의 Real(실수) 형을 표현할 수 있는 모듈이 있다고 칩시다. - 첫번째 추상 단계 입니다. 물론 안으로 들어가면 더 많은 추상이 있을 수 있습니다. 이런 각 모듈은 모두 아시다시피 프로시저와 데이터로 구성이되고, 각 프로시저와 데이터는 어떤 복잡한 것을 표현하는 하나의 추상이 될 수 있습니다.
두 Real 형을 묶은 Complex 형을 표현하는 모듈을 만듭니다. - 두번째 추상 단계입니다. 이 단계에서 Complex를 쓰는 사람은 Real의 속이 어떻게 생겼는지 알 필요 없습니다. 즉, 이런 과정이 프로그래밍을 단순하게 만들어줍니다.
Complex형 끼리 서로 연산하는(사칙연산 등의) 모듈을 만듭니다. - 세번째 추상 단계입니다. 일부 OO언어의 예제에서는 두번째와 세번째 단계가 서로 섞여있는 경우가 있는데 원래 이 두 가지는 엄연히 구분되어야 합니다. 물론 구현상의 이유(속도 등의)로 합치는 것은 몰라도 당연한듯 섞는 것은 문제가 있는 것이지요.
Complex 연산을 할 수 있는 모듈을 가져와서 퓨리에변환하는 모듈을 만듭니다. - 네번째 추상 단계입니다. 물론 세번째와 네번째 사이에도 더 많은 추상 단계가 있을 수 있습니다.
(참고로, 이런 추상 단계는 영어로는 abstraction barrier라고 부릅니다.)
우리가 마침내 퓨리에변환을 하기 위해서 Complex에 관련된 연산을 쓴다고 하면, 우리는 Real이 어떻게 구현이 되어있는지, Complex가 어떻게 구현되어있는지, Complex의 연산이 어떻게 구현되어있는지 신경쓸 필요가 없습니다. 이런 구현을 신경쓸 필요가 없다는 것은 지금 당장 우리가 집중해야 하는 문제의 영역이 크게 줄어든다는 말이고, 프로그래밍이 쉬워진다는 말입니다.
고급의 추상이라고 하면, 이런 추상 단계가 충분히 많아서 우리가 쓰는데 그 구현을 전혀 신경쓰지 않고도, 맘대로 프로그래밍 할 수 있는 수준이라고 말할 수 있습니다. 우리가 차를 달리게 만드는데는 엑셀을 밟고, 핸들을 돌리는 것(간단한 인터페이스)만 알면되지, 엑셀을 밟았을때 어디가 어디로 연결(복잡한 연관관계)이 되는지, 핸들을 돌리면 뭐가 어떻게 동작하는지(복잡한 구현)는 알필요 없는 것이지요.
덧붙여, 윗 글에서 밝힌 "고급의 데이터 추상"은 원래의 소스를 고치지 않고, 기능을 추가하는 그런 기법을 말씀한 것입니다. OO에서 말하는 상속이나 델리게이션이 이런 기법을 쓰기 위한 방법입니다. 이것 역시 이전의 구현이 어떻게 만들어졌는지 신경쓰지 않고, 지금 필요한 데이터를 만드는 것을 의미하는 추상이지요.

함수형 패러다임은 OO패러다임이나 명령형 패러다임과 문제에 접근하는 방법이 틀릴뿐이지 그 외의 대부분은 유사합니다.
단지 람다를 이용한 "증명가능한" 코드를 작성하려할 뿐입니다. 여기서 "증명가능한"이라는 말은 컴파일이 된다면 반드시 동작한다는 말입니다.
OO나 명령형 패러다임의 문제점은 assignment(=연산)를 쓰기때문에 상태가 "알 수 없게" 변한다는 겁니다. 즉, 어느 시점에서 어떤 변수가 어떤 값을 들고 있을지는 일일이 따라가보지 않으면 알 수 없다는 것이지요. 즉, 디버거가 필요한겁니다.
함수형 패러다임은 어느 시점에 어떤 변수가 어떤 값을 들고 있는지 반드시 확인할 수 있습니다. 디버거가 없이도 디버깅이 가능합니다.
하지만 순수한 함수형 패러다임은 상태를 바꿀 수 있는 손쉬운(?) assignment를 포기했기때문에, 그 아래에 있는 시스템콜을 쓰기가 불편합니다. 시스템콜은 대부분 assignment를 써서 구현되어있고, 즉 시스템을 상태로 보고 프로그래밍 해왔기 때문에 함수형 패러다임에 적합한(스트리밍같은) 상태바꾸기는 힘듭니다.
그래도 사람들이 가장 많이 쓰는 함수형 언어인 ML(또는 CaML, OCaML)이나 Lisp(또는 Scheme)같은 언어는 assignment를 쓸 수 있게 만들어져있기때문에 큰 불편함은 없을 정도입니다. 물론 assignment를 쓴 부분을 디버깅하려면 반드시 적당한 디버거가 필요합니다.
함수형 패러다임 언어로 성공한 프로젝트는 이미 너무 많습니다. 가깝게는 야후 쇼핑도 중요한 부분은 모두 Lisp으로 만들어졌습니다. 폴 그래험이 야후 쇼핑의 개발과정에서 밝혔듯 상태가 없이 코딩한다는 것은 아주 큰 장점입니다.
말씀하신 술어형, 제가말하는 논리형 패러다임 언어의 경우에는 보통 연구용으로 많이 쓰입니다. 보통은 공학쪽 연구라기보다는 수학쪽 연구라고 보는게 맞겠지요. 말씀하신 프롤로그의 경우에는 고전적인 논리(classical logic;정확하게 한분야는 아닙니다.)을 기초로 하고 있기때문에 약간 부족합니다만, 요즘의 논리형 패러다임은 선형 논리(linear logic)이라 불리는 영역까지 확장되어 있습니다. 간단한 오토마타는 코드 몇 줄이면 표현할 수 있습니다. 이 선형 논리는 고전 논리와 달리 상태까지 표현할 수 있기때문에 대단한 잠재력을 가지고 있다고 볼 수 있습니다.
어쨌든 논리형 패러다임의 경우에 해당 언어를 직접 쓰는 경우는 드물지만 패러다임은 이미 널리 쓰이고 있습니다. NP문제가 아닌 다음에야 논리형 패러다임은 가장 간단하면서 확실한 해결책을 제시해줍니다.
하지만 pok님이 말씀하신 "특히나 술어형인경우, 그냥 오토마타를 구현하면 될수 있을것 같거든요. 게다가 현재의 언어가 non-deterministic한것까지 처리해줄만큼 강력하지도 못하고 술어와 리스트와의 관계라는것 자체가 명제함수적으로 처리가 가능하니까 현재의 언어패러다임으로 "라이브러리"로 구축하는게 낫다고 생각하거든요."에 대한 제 생각은 부정적입니다.
현재 논리형 패러다임을 쓸 수 있는 라이브러리는 이미 몇가지가 나와있습니다. 하지만 논리형 패러다임은 단지 어떤 알고리즘만을 의미하는 것이 아닙니다. 다른 언어에서는 패턴매칭이나 리스트같은 구조를 적절하게 나타내지 못합니다. 결국 C++같은 언어에서 그런 라이브러리를 쓴다고 하더라도 프롤로그에서 보이는 그런 간결한 모양이 절대 나오지 않습니다.
Leda같은 언어는 기존의 언어형태에 논리형 패러다임을 어떻게 섞어쓸 수 있는지를 약간 보여주고 있지만, 만족할만한 수준은 아닙니다. 빨리 프로그래밍 언어 연구가 발전해서, 그리고 그것을 바탕으로 논리형 패러다임까지 포괄하는 더 좋은 언어가 나오기를 바랄뿐입니다.
-추가 자료
The Forte Formal Verification System (실제로 인텔에서 마이크로프로세서의 오류를 찾기 위해 만든 함수형 언어) : http://web.comlab.ox.ac.uk/oucl/work/tom.melham/res/forte.html
Logic Programming in C++ (C++에서 로직프로그래밍) : http://www-static.cc.gatech.edu/~yannis/lc++/
지금 바빠서 찾아서 나중에 더 올리께요.

추천감사드리구요, 함수형이란게 그런것이었군요.
헤스켈부터 공부해봐야겠네요.

이런 말 하기 뭣하지만 써보시기는 하고 말씀을 하시는 건가요?
현재 세계에서 가장 인기있는 언어가 ruby입니다.
뉴스그룹가서 하루에 올라오는 글 수만 비교해보세요. C++의 10배는 그냥 넘습니다.
이 많은 사람들이 다 연구나 실험을 위해서 장난처럼 쓴다고 생각하십니까?
An님이 말씀하신 것중에 맞는 말은 속도가 좀 떨어진다는 것 말고는 다 틀렸군요.
또한 그렇다하더라도 속도도 쓸 수 없을 만큼 나쁘지는 않습니다.
-애플리케이션을 만들 수 없다. => ruby는 프로토타이핑을 만들고 실제 어플리케이션을 만드는 성과에서 perl, python과 경쟁중입니다.
-실험적으로 만든 언어 => ruby는 가장 실용적인 언어중에 하나입니다.
-생산성 떨어짐 => lisp, perl, python과 비교해봐도 차이를 느낄 수 없을 정도고, C나 C++, Java보다는 월등한 생산성을 갖추고 있습니다.
저도 ruby를 딱히 좋아하는 것은 아닙니다만, ruby만큼 쓰기 편하고 좋은 언어가 거의 없다는 건 분명한 사실입니다.
괜히 화나게 만드는 댓글이군요.