Arc가 특별히 객체 지향적이지 않은 이유 | undefined

현재 객체 지향 프로그래밍에 대한 일종의 열풍이 불고 있지만, 내가 아는 가장 똑똑한 프로그래머들 중 일부는 그것에 대해 가장 시큰둥하다.

내 생각에 객체 지향 프로그래밍은 어떤 경우에는 유용한 기술이지만, 그것이 당신이 작성하는 모든 프로그램에 스며들어야 하는 것은 아니다. 새로운 타입을 정의할 수 있어야 하지만, 모든 프로그램을 새로운 타입의 정의로 표현해야 할 필요는 없다.

사람들이 객체 지향 프로그래밍을 좋아하는 다섯 가지 이유가 있다고 생각하는데, 그중 세 개 반은 좋지 않다:

정적 타입 언어에 렉시컬 클로저나 매크로가 없다면 객체 지향 프로그래밍은 흥미롭다. 어느 정도는 이러한 제약을 우회하는 방법을 제공한다. (그린스펀의 열 번째 규칙 참조.)
객체 지향 프로그래밍은 대기업에서 인기가 있는데, 그들이 소프트웨어를 작성하는 방식에 적합하기 때문이다. 대기업에서는 소프트웨어가 대규모의 (그리고 자주 바뀌는) 평범한 프로그래머 팀에 의해 작성되는 경향이 있다. 객체 지향 프로그래밍은 이들 프로그래머에게 규율을 부과하여 그들 중 누구도 너무 많은 손상을 입히는 것을 방지한다. 그 대가는 결과 코드가 프로토콜로 부풀어 오르고 중복으로 가득 찬다는 것이다. 이는 대기업에게는 그리 비싼 대가가 아닌데, 그들의 소프트웨어는 어차피 부풀어 오르고 중복으로 가득 찰 가능성이 높기 때문이다.
객체 지향 프로그래밍은 많은 양의 '일처럼 보이는 것'을 생성한다. 팬폴드(fanfold) 시절에는 한 페이지에 코드 다섯 줄이나 열 줄만 넣고, 그 앞에 스무 줄의 정교하게 형식화된 주석을 붙이는 프로그래머 유형이 있었다. 객체 지향 프로그래밍은 이런 사람들에게 마약과 같다: 이 모든 비계(scaffolding)를 소스 코드에 바로 통합할 수 있게 해준다. 리스프 해커가 심볼을 리스트에 푸시하는 방식으로 처리할 수 있는 것이 클래스와 메서드로 가득 찬 파일 전체가 된다. 그러므로 자신이, 또는 다른 사람이 많은 일을 하고 있다고 확신시키고 싶다면 좋은 도구이다.
언어 자체가 객체 지향 프로그램이라면, 사용자들에 의해 확장될 수 있다. 음, 그럴 수도 있다. 아니면 객체 지향 프로그래밍의 하위 개념들을 단품(a la carte)으로 제공함으로써 훨씬 더 잘할 수도 있다. 예를 들어, 오버로딩은 본질적으로 클래스에 묶여 있지 않다. 두고 볼 일이다.
객체 지향 추상화는 시뮬레이션 및 CAD 시스템과 같은 특정 종류의 프로그램 도메인에 깔끔하게 매핑된다.

나는 개인적으로 객체 지향 추상화가 필요했던 적이 없다. Common Lisp는 엄청나게 강력한 객체 시스템을 가지고 있지만, 나는 단 한 번도 사용해 본 적이 없다. 나는 더 약한 언어에서는 객체 지향 기술이 필요했을 많은 일들(예: 클로저로 가득 찬 해시 테이블 만들기)을 해왔지만, CLOS를 사용해야 했던 적은 한 번도 없다.

어쩌면 내가 그저 어리석거나, 제한된 응용 프로그램 하위 집합에서만 작업했을 수도 있다. 자신의 프로그래밍 경험에 기반하여 언어를 설계하는 데는 위험이 따른다. 하지만 좋다고 생각해서 한 번도 필요 없었던 것을 넣는 것이 더 위험해 보인다.