이거 장난이겠죠?

The Real Stroustrup Interview

"Computer", pp.110-114, June, 1998.

C++의 디자인과 발전에 있어서(Addison Wesley, 1994), Bjarne Stroustrup 은 아래와 같이 논의했다. "프로그래밍 언어는 실제로 세계(world)의 극히 작 은 부분입니다. 그러므로 그것은 너무 심각하게 간주되어서는 안 됩니다. 일부 분(proportion)의 감각(역자주: '프로그래밍 언어는 전 세계에 비하면, 매우 작 은 부분이다'는 감각)을 유지하면서, 그리고 더욱 중요하게 유모어(humor) 감 각을 유지해야 합니다. 중요한 프로그래밍 언어 중에서, C++는 익살과 농담의 풍부한 자원입니다. 그것은 우연이 아닙니다."

지난 몇 달 동안, Stroustrup과 Computer지와의 가짜(hoax) 인터뷰가 사이 버스페이스에서 회자(make round)되었다. 우리는 그 사건에 대해 유감스럽게 (regret) 생각한다. 하지만, 그것이 우리로 하여금 C++의 대부와, 표준 C++과 일반적인 소프트웨어 개발에 대한 그의 통찰력(insight)을 나눌 좋은 기회를 허락하였다. 우리는 또한 그의 지속적인 부분(proportion)과 유머(humor)에 대 한 감각을 증명할 수 있었다(그는 그 우스꽝스러운 인터뷰를 만약 그 자신이 썼다면, 더 재미있는 개작(parody)이 되었을 거라고 제안했다).

- Scott Hamilton, Computer

표준 C++(STANDARD C++)

Computer: ISO는 표준 C++을 1997년 11월 승인하였습니다. 그리고 당신은 당신의 책 "The C++ Programming Language(Addison Wesley, 1997)"의 3번 째 판을 출판하였습니다. 지난 몇 년간 C++가 어떻게 발전하였으며, ISO 표 준이 C++ 공동체(community)에 무슨 의미를 갖는지 이야기해 주시겠습니까?

Stroustrup: 마침내 완벽하고(complete), 상세하며(detailed), 견고한(stable) C++의 정의를 내렸다는 것은 위대한 일입니다. 이것은 C++ 공동체에 직접적 이고 간접적으로 무수한 도움이 될 것입니다. 컴파일러 제공자들은, 표준 위원 회의 내용들을 따라가는 것(catching up with the standards committee)에서 이제는 구현의 질에 관한 논쟁으로 쟁점을 이동시키기 시작함에 따라서, 분명 히 우리는 더 좋은 개발 환경을 접하게 될 것입니다. 이것은 이미 진행중입니 다.

표준을 수용하는 구현은 툴의 혜택과 큰 공통 플랫폼을 제공하는 라이브러 리 제공자의 혜택을 경험하게 할 것입니다.

표준은 프로그래머에게 새로운 기술과 함께 더 도전적인 기회를 제공할 것 입니다. 제품의 코드에서 비실제적인 코드를 사용했던 프로그래밍 양식은 실 제적인 계획(proposition)이 되어가고 있습니다. 이처럼, 더 유연하고(flexible), 일반적이고(general), 빠른(faster), 그리고 더 유지하기 쉬운 코드를 사용할 수 있습니다.

일반적으로, 우리는 냉정을 유지해야 하고, "개선된" 기교의 주연(orgy)에 탐닉(indulge)해서는 안 됩니다(역자주: 개선된 C++의 기교를 사용하는 것은 중요한 일이 아니라는 주장). 기적은 여전히 없습니다. 그리고 좋은 코드는 여 전히 탄탄한 디자인과 대부분 직접적으로 매치되는 코드입니다. 그러나, 바로 지금은, 어떤 기교가 특정한 사람, 조직, 혹은 프로젝트에 적당한지, 실험하고 살펴볼 시간입니다. The C++ Programming Language의 많은 부분은 이러한 기교와 그것들이 제공하는 흥정관계(trade-offs)를 기술하고 있습니다.

이러한 진보를 가능하게 하는, 우리가 눈으로 볼 수 있는 부분은, 언어의 새 로운 큰 기능 - 템플릿(template), 예외처리(exception), 실행시 형 정보 (runtime type information), 이름공간(namespace) - 과 표준 라이브러리입니 다. 언어의 자세한 부분의 작은 개선 또한 중요합니다. 우리는 이제 여러 해 동안 사용 가능했던 유용한 것들을 대부분 가지게 되었습니다. 하지만, 호환성 과 제품의 품질이 필요로 하는 곳에 대해서는 그것들에 크게 의존할 수 없었 습니다. 이것은 우리로 하여금, 우리의 라이브러리와 응용프로그램을 설계하는 데 있어서 최적이 아닌 차선(suboptimal)을 선택하도록 하였습니다. 그러나, 곧(올 해 1998년) 모든 큰 구현이 표준 C++를 탄탄하게 지원하게 될 것입니 다.

언어와 프로그래밍 기교의 관점에서 C++에 가해진 가장 중요한 변화는, 정 적으로 검사 가능한 형 안정성(staticaly verifiable type safety)에 대한 강조의 계속적인 증가와 템플릿의 증가된 유연성입니다. 유연한 템플릿은 우아함 (elegance)(역자주: 명시적인 형 변환이 필요없는 C++ 프로그램은 읽기 쉽다. 이것을 우아하다고 표현한 것 같다)과 효율성(efficiency)에 주목하는 형 안정 성을 강조하기 위해서 필요합니다.

새로운 기술의 실행가능성(Feasibility of new techniques)

Computer: 당신은 말하기를 "숙련된 C++ 프로그래머조차도 지난 몇 년 동 안 인지하지 못한 것은 그러한 새로운 기능이 아니라, 기본적인 새로운 프로 그래밍 기교를 가능하게 하는 기능들간의 관계의 변화이다." 라고 하였습니다. 어떻게 이것이 표준 C++에 적용 가능한지 몇 가지 예를 들어주시겠습니까?

Stroustrup: 오버로딩이나 템플릿이 함께 사용되어 우아하고 효과적인 형 안 정 컨테이너의 중요한 역할을 한다는 것을 모르고도, 오버로딩과 템플릿은 규 칙들을 각각 공부하는 것은 쉽습니다. 이러한 연결(역자주: 오버로딩과 템플 릿의 연결)은 컨테이너에서 공통적으로 많이 사용되는 근본적인 알고리즘을 자세하게 살펴볼 때에만 명확해 집니다. 그림 1a의 프로그램 조각(segment)을 고려해 봅시다. count()의 첫 번째 호출은 정수 벡터에서 7의 횟수를 헤아립니 다. count()의 두 번째 호출은 스트링 리스트에서 "seven"의 횟수를 헤아립니 다.

void f(vector<int>& vi, list<string>* ls)

{

int n1 = count(vi.begin(),vi.end(),7);

int n2 = count(ls.begin(),ls.end(),"seven");

// ...

}

(a)

template<class Iter, class T>

int count(Iter first, Iter last, T value)

{

int c = 0;

while (first!=last) {

if (*first == value) c++;

++first;

}

return c;

}

(b)

그림 1. 기능들간의 관계의 차이는 근본적인 새로운 프로그래밍 기교를 가 능하게 한다: (a) 정수 벡터의 7을 헤아리는 알고리즘과 스트링 리스트의 "seven"을 헤아리는 알고리즘이 템플릿을 이용하여 둘 모두를 다루는 (b) 로 구현할 수 있다.

오버로딩을 지원하는 각각의 언어에서 이것을 구현하는 방법은 다양합니다. 템플릿이 주어지면, 둘 모두의 호출을 다루는 하나의 함수를 그림 1b처럼 만 들 수 있습니다. 이 템플릿은 둘의 호출에 대해 최적으로 확장(역자주: 실제로 템플릿 함수는 호출되는 것이 아니라, 컴파일 시간에 템플릿을 호출한 문법에 따라 각각의 경우로 만들어진다. 그리고 실제로 만들어진 이 함수가 호출된다. 이것을 확장(expansion)이라 한다)될 것입니다. 이 count()는 표준 라이브러리 의 count()와 거의 유사합니다. 그러므로 사용자가 count()를 직접 작성할 필 요는 없습니다. count()함수는 그 자체가 오버로딩에 의존하고 있습니다: 명확 히 등호 연산자 ==는 정수와 스트링에 대해 오버로딩되어 있습니다. 게다가 * 와 ++는 각각 벡터와 리스트를 위한 반복 형(iterator type)을 위하여 "역참조 (dereference)"와 "다음 요소 참조"로 오버로딩되어 있습니다. 다시말하면, *와 ++는 포인터를 위해 그것들이 가지는 의미가 주어졌습니다.

count()의 이러한 정의는 C++ 표준 라이브러리의 컨테이너와 알고리즘에서 사용된 중요 기교의 결합을 설명합니다. 이러한 기교는 유용합니다. 그리고 그 것은 오로지 기본적인 언어의 규칙에 의해서만 간단하게 기술할 수 없습니다.

template<class Iter, class Predicatte>

int count_if(Iter first, Iter last, Predicate pred)

{

int c = 0;

while (first!=last) {

if (pred(*first)) c++;

++first;

}

return c;

}

(a)

bool less_than_7(int i) { return i<7; }

void f2(vector<int>& vi, list<int>& li)

{

int n1 = count_if(vi.begin(),vi.end(),less_than_7);

int n2 = count_if(li.begin(),li.end(),less_than_7);

// ...

}

(b)

그림 2. 카운트 예제의 더 진보된 버전: (a)는 predicate를 만족하는 요소의 개수를 헤아린다. 예를 들면 (b)는 7보다 작은 요소의 수를 헤아린다.

그림 2a에 제시된 좀 더 진보된 예를 참조해 봅시다. 값의 횟수를 헤아리는 대신에, count_if()는 predicate를 만족시키는 요소의 개수를 헤아립니다. 예를 들면, 그림 2b처럼 7보다 작은 값을 가지는 요소의 개수를 헤아릴 수 있습니 다.

이러한 기교를 일반화하여, 어떠한 형의 어떠한 값도 비교하는 것을 다루기 위해서는 함수 객체(function object) - 그림 3a처럼 객체가 함수처럼 불러 내어질(invoke) 수 있는 클래스 - 를 선언하는 것이 필요합니다. 그림 3b처럼 생성자 비교를 원하는 값의 참조를 저장합니다. 그리고 () 연산자는 비교를 수행합니다. 바꾸어 말하면, vi에 있는 요소중에 7보다 작은 요소의 수를 헤아 리고, ls에 있는 요소중에 "seven"보다 작은 요소의 수를 헤아립니다.

template<class T> class Less_than {

const T v;

public:

Less_than(const T& vv) : v(vv) {} // constructor

bool operator() (const T& e) { return e<v; }

};

(a)

void f3(vector<int>& vi, list<string>& ls)

{

int n1 = count_if(vi.begin(),vi.end(),

Less_than<int>(7));

int n2 = count_if(ls.begin(),ls.end(),

Less_than<string>("seven"));

// ...

}

(b)

그림 3. 어떤 형의 어떤 값도 비교하는 것을 다루기 위해, 우리는 클래스의 객체가 함수처럼 불러낼 수 있는 (a) 클래스를 정의한다. 생성자는 (b)에서 처럼, 비교하고자 하는 값의 참조를 저장한다(역자주: count_if()의 세 번째 파라미터는 Less_than 객체를 생성하는 문장이다. 이 임시 객체가 파라미 터로 전달된다. 물론 count_if()의 내부에서는 이 객체의 오버로딩된 연산자 ()를 사용한다).

생성된 코드는 매우 효율적이며, 특별히 비교를 수행하고, 다음 요소를 가져 오는 등의 작업을 하는데, 함수 호출 - 혹은 비슷한 늦은 연산자 - 을 사용하 지 않는 다는 것(역자주: 자세한 사항은 '함수 객체'를 참고하라)은 언급할 만 합니다.

의심할 여지도 없이, 이 코드는 C++ 프로그래머가 아닌 사람에게, 혹은 템 플릿과 오버로딩의 개념을 익히지 못한 C++ 프로그램머에게 조차도 이상하게 보일 것입니다. 물론 이것은 이 예제를 여기서 제시한 이유중의 일부입니다. 그러나, 진짜 의도(bottom line)는 이 기교가 당신에게 효율적이고, 형 안정적 이고, 일반적인 코드를 작성하게 한다는 것입니다. 함수형 언어(functional language)(역자주: LIST같은 언어를 함수형 언어라 한다)에 익숙한 사람들은 이러한 기교가 그러한 언어에서 선구적으로 개척된 기교와 유사하다는 것을 알아차렸을 것입니다.

언어의 모습은 분리되었을 때 근본적으로 지루합니다. 그리고 그것은 좋은 시스템 설계로부터 흩뜨릴 수 있습니다(오직 언어가 살아남아야 할 프로그래 밍 기교의 측면에서).

표준 라이브러리(The Standard Library)

Computer: 표준 라이브러리는 어떻습니까? 또한 그것이 C++ 공동체에 무슨 영향을 끼칠까요?

Stroustrup: 표준 라이브러리의 가장 새롭고 흥미로운 부분은 컨테이너와 알 고리즘의 일반적이고 확장 가능한 골격(framework)입니다. 그것은 종종 STL 이라고 불리는데, 근본적으로 Alex Stepanov의 작품입니다(그 당시 Hewlett-Packard에서 지금은 Silicon Graphics에 있다).

Alex는 확고하게(uncompromisingly) 일반적이면서 효율적인 근본적인 알고 리즘을 제공하기 위해 일을 했습니다. 예를 들면, 자료 구조에서 요소를 찾는 것, 컨테이너를 정렬하는 것, 자료 구조에서 값의 횟수를 헤아리는 것 등입니 다. 그러한 알고리즘은 많은 계산에서 근본적인 것입니다.

Alex는 많은 종류의 언어를 가지고 연구했습니다. 그리고 몇 년간 공동 연 구자들이 있었습니다. 주목할만한 이들은 David Musser(Rensselaer Polytechnic Institute), Meng Lee(HP Labs), Andrew Koenig(AT&T Labs) 등 입니다. 제가 STL에 공헌한 부분은 매우 작지만 중요하다고 생각합니다: 저는 어댑터(adapter)라고 불리는 mem_fun()을 디자인했습니다. 그것은 다형 객체(polymorphic object)의 컨테이너를 위해서 표준 알고리즘이 사용되는 것 을 제공합니다(역자주: 어댑터는 크기가 동적인 가변 객체를 컨테이너 연산의 대상으로 하기 위한 메모리 할당 및 처리 루틴을 말하는 것 같다). 이처럼, 객 체 지향 기술을 시도하는 것이 깔끔하게 표준 라이브러리의 일반적인 프로그 래밍 골격에 포함되었습니다.

다소 놀랍게도, STL은 제가 몇 년 전에 개발한 C++을 위한 표준 컨테이너 의 좋은 집합을 결정하는 판단기준과 일치되었습니다. 1년 후, STL에 대해 의논하고 마무리한 후, ISO C++ 위원회는 STL을 C++를 위한 표준 라이브러 리의 중요한 부분으로 받아들였습니다. 저의 판단기준도 포함되었습니다.

○ 간단한 기본 연산의 확고한 효율성(예를 들면, 배열의 인덱싱 (subscripting)이 함수 호출의 비용을 유발해서는 안 된다);

○ 형 안정성(type-safety)(컨테이너로부터의 객체는 명시적인(explicit) 혹은 함축적인(implicit) 형 변환 없이 사용 가능해야 한다);

○ 일반성(라이브러리는 벡터,리스트,맵 같은 몇 개의 컨테이터를 제공해야 한다);

○ 확장성(내가 필요로하는 컨테이너를 라이브러리가 제공하지 못하는 경 우, 내가 컨테이터를 만들어 표준 컨테이너처럼 사용할 수 있어야 한다).

약간의 수정과 추가를 거친 STL을 채택함으로써, 위원회에서 해야 할 끔찍 한 디자인을 피할 수 있었습니다.

명확히, C++ 표준 위원회의 시간제 근무자의 그룹이 프로그래머가 유용하 다고 판단하는 모든 라이브러리의 기능을 제공할 수 없습니다. 결과적으로 중 요한 쟁점은 무엇이 표준 라이브러리에 포함되어야 하고, 무엇이 기업과 개인 이 제공하는 것으로 남겨져야 하는 것을 결정하는 것이었습니다.

우리는 무엇이 포함되어야 하는가의 길잡이로 "독립적으로 개발된 라이브러 리 사이의 통신 역할을 하는데 필요한 것"을 사용하기로 하였습니다. 이처럼, I/O, 스트링, 컨테이너가 큰 촛점이 되었습니다. 우리는 표준 C 라이브러리와 수 계산을 위한 몇 기능을 역사적인 이유 때문에 포함시켰습니다. 하지만, 잠 재적으로 유용한 많은 기능들 - 날짜와 통화, 정규 표현 매칭, 그래픽 - 을 남겨두었습니다. 다행히도, 이러한 기능들은 공개 혹은 상업적으로 이용 가능 합니다.

표준 라이브러리는 프로그래머가 바퀴를 다시 발명하는 것을 구해냅니다. 특별히, 표준 컨테이너는 초보자나 숙련자 모두에게 높은 수준의 프로그램 (high level programming)을 허락합니다. 쉬운 일을 간단히 처리하는, 그림 4 의 간단한 프로그램을 고려해 봅시다.

int main()

{

cout << "Please enter your first name:\n";

string name;

cin >> name; // read into name

cout << "Hello" << name << "!\n";

}

그림 4. 간단하게 일을 처리하는 "Hello" 프로그램

매크로도 이용하지 않고, 명시적인 메모리 관리나 다른 고 수준 언어의 기 능을 이용하지 않으며, 리소스의 제한도 받지 않습니다. 특별히, 만약 어떤 익 살꾼(joker)이 자신의 첫 번째 이름으로 30,000자를 적는다고 하더라도, 에러 나 오버플로우 없이 프로그램은 충실히 이름을 출력할 것입니다.

표준 라이브러리를 이용하는 것은 C++가 배워지던 방법의 혁명을 일으킬 수 있고 일으켜야 합니다. 이제 C++을 고수준 언어로써 배우는 것이 가능합 니다. 학생들은 이제 필요할 때만 낮은 수준의 프로그래밍 기능들을 다루면 됩니다. 혹은 낮은 수준의 프로그래밍 기능들을 언급할 적절한 실력들이 쌓이 고 나서 보아도 됩니다.

이처럼, 표준 라이브러리는 도구와 교사로서의 역할을 할 것입니다.

복잡성, C++와 객체지향프로그래밍(COMPLEXITY, C++, AND OOP)

Computer: The C++ Programming Language에서 당신은 말하기를 "정상적 인 실용적인(practical) 프로그래머들은 생산성, 유지보수, 유연성과 어떠한 종 류와 스케일의 프로젝트에 대한 품질에 대해서도 놀랄만한 향상을 달성했다." 고 했습니다. 그러나 아직 몇몇 비평가들은 C++과 일반적인 OO는 여전히 너 무 복잡하고, 교정 유지보수(corrective-maintenance)문제를 일으키며, 큰 시스 템에서의 유지 문제가 있다고 합니다. 어쨌던 이러한 비평이, 당신 자신의 경 험으로 볼 때, C++로 설계하는 큰 시스템의 개발에 적용되는 것이라 생각합 니까?

Stroustrup: 저의 개인적인 경험으로, OO 설계와 OO 프로그래밍은 전통적인 절차적인 방법을 통해서 당신이 얻을 수 있는 것보다 좋은 코드를 제공할 것 입니다. 그러한 코드는 더욱 유연하고(flexible), 더욱 확장 가능하며 (extensible), 심각한 수행상의 부하(overhead)없이 유지 보수 가능한 (maintainable) 코드입니다. 위의 개인적인 의견에 반대되는 제가 좋아할 만한 강한 증거는 없습니다. 하지만, AT&T 내부에서의 몇몇 연구와 다른 연구들 은 이러한 의견을 지지합니다.

두 요소가 쟁점을 난처하게 합니다: "객체 지향적"인 것이 정말로 무엇인지 에 대한 일반적인 동의가 없습니다. 또한 토론은 좀체 경험을 충분히 설명하 지 못합니다. "OO의 문제"의 많은 부분은 정말로 OO가 무엇인지 모르는 부 분적인 이해를 가진 사람들이 야망찬 프로젝트를 진행하는데서 비롯합니다.

그렇다면 OO는 무엇입니까? 확실히 좋은 프로그램 모두가 객체 지향적인 것은 아니며, 객체 지향적인 모든 프로그램이 좋은 것도 아닙니다. 만약 그렇 다면 "객체 지향적"인 것이 단순히 "좋은 것"을 의미합니다. 그리고 이것은 당신이 실제적인 결정을 내려야 할 때 개념을 혼동하게 하는 하나의 추가된 전공용어(buzzword)에 불과합니다. 저는 OOP를 클래스의 상속과 가상함수(어 떤 언어에서는 메서드(method)라고 하는)를 많은 사용한 프로그램과 동일시하 곤 합니다. 이 정의는 역사적으로는 정확합니다. 왜냐하면, 클래스 계층과 가 상 함수는 그 당시 시뮬라(Simula)와 다른 언어를 구분짓는 철학이었기 때문 입니다. 사실, Smalltalk이 가장 중요하게 강조된 것은 시뮬라 유산의 이러한 관점 때문입니다.

클래스 계층과 가상 함수에 기초하여 OO를 정의하는 것은 OO가 성공할 것 같은 곳으로의 몇 지침을 제공하기 때문에 실용적입니다. 당신은, 정확하게 같 은 형이 아니지만 공통의 인터페이스로 조작될 수 있는 객체를 위한, 구현을 공유할 수 있는 개념들의 변체(variant)를 위한 계층적인 순서를 가진 개념들 을 찾습니다. 몇 예제와 약간의 경험을 한다면, 이것이 디자인을 위한 매우 강 력한 접근의 기초가 되는 것을 알것입니다.

그러나, 모든 개념이 자연스럽고 유용하게 계층(hierarchy)과 적합한 것은 아닙니다. 개념들간의 모든 관계가 계층적인 것도 아니고, 모든 문제에 대해 객체에 중심한 접근이 최선인 것도 아닙니다. 예를 들면, 몇 문제들은 근본적 으로 알고리즘적(algorithmic)입니다. 결론적으로, 일반 목적의 프로그래밍 언 어는 다양한 사고와 다양한 프로그래밍 스타일을 지원해야 합니다. 이러한 다 양성은 풀이해야 할 문제의 다양성과 문제 풀이의 다양성에 기인합니다. C++ 은 다양한 프로그래밍 스타일을 지원합니다. 그러므로, 객체 지향 언어라기 보 다는 멀티패러다임(multiparadigm) - 이름을 꼭 붙여야 한다면 - 언어라고 불 리는 것이 더 적당합니다.

"좋은 것" - 이해하기 쉽고, 유연하고, 효율적인 - 의 기준을 대부분 만족시 키는 디자인의 예로 전통적인 절차 코드를 사용한 재귀 경향 파서(recursive descent parser)가(역자주: 실행 가능한 코드를 생성하는 번역기를 파서 (parser)라 하는데, 재귀 호출을 사용하며, 주로 수식을 번역하기 위해 사용한 다) 있다. 다른 예로 STL이 있습니다. 이것은 전통적인 절차적인 코드와 파 라미터적인 다형성(역자주: 이름에 의한 다형성이 아닌)에 전적으로 의존하는 컨테이너와 알고리즘을 포함한 일반 라이브러리입니다.

저는 단 하나의 프로그래밍 패러다임만 지원하는 언어는 제한적이라는 것을 발견했습니다. 그것은 간단함(simplicity)을 사는 대신, 프로그래머에게 구속복 (straitjacket)을 입히거나, 언어의 복잡함을 응용 프로그램의 복잡함으로 전가 시킵니다. 이것은 특정 목적 언어(special-purpose language)에는 적합하지만, 범용 언어(general-purpose language)에는 적합하지 않습니다.

저는 종종 C++를 시스템 프로그래밍으로 편향된 범용 언어라고 특징 지웁 니다. 다음을 지원하는 "더 나은 C"로 생각하는 것이죠.

○ 데이터 추상화

○ 객체 지향 프로그래밍

○ 일반적인 프로르래밍(generic programming).

자연히, 이것은 하나의 접근법만을 허용하는 언어에 비해 복잡함을 증가시 킵니다. 저는 이러한 관점 - 문제 영역마다 최선인 각각의 디자인과 프로그래 밍 접근법이 있다 - 이 어떤 이들을 화나게 한다는 것을 주목했습니다. 확실 히, 모든 사람에게 혹은 모든 문제에 올바른 한가지 방법이 있다는 관점은 거 절합니다. 세계는 근본적으로 간단하다는 사실을 열정적으로 믿고 싶어하는 사람들은 제가 이것을 단지 프로그래밍 언어에 대해서만 적용한다는 사실과는 상관없이 격노(fury)합니다. 결국, 프로그래밍 언어는 시스템을 설계하기 위한 많은 도구들 중의 하나입니다.

이러한 두 관점을 모두 해결하는 이상적인 방법은 모든 프로그래밍 스타일 을 효율적으로 지원하는 간단한 프리미티브(primitive)의 집합을 지원하는 언 어를 가지는 것입니다. 이것이 반복적으로 계속 시도되기는 했지만, 달성되지 는 - 저의 의견에 - 못했습니다.

자바와 C++(JAVA AND C++)

Computer: 위에서와 같은 논쟁이 납득할만하게 자바(Java)로 확장 가능하다 고 봅니다. Sun이 주장하기를 700,000명의 자바 프로그래머가 있다고 합니다 (비교해서 C++ 프로그래머는 1,500,000명 정도). 당신은 C++가 C와 호환될 필 요도 없으며, 자바가 당신이 고안한 언어가 아니라는 주장을 고집합니다. 이러 한 질문을 1000번 이상 받았다면 당신은 무슨 말을 할 것입니까?

Stroustrup: 오늘날, 저는 항상 자바에 대해서 질문 받습니다. 그리고 항상 대답하기는 어렵습니다. 제가 만약 약간 부정적인 것을 말한다면, 무례한 것으 로 느껴집니다. 제가 만약 약간 긍정적인 것을 말한다면, 자바를 둘러싼 상업 적인 공간(commercial hype)에 뛰어드는 것 같고, 자바 공동체의 부분으로부 터 흘러나오는 불운한 반 C++ 선전(the unfortunate anti-C++ propaganda)에 뛰어드는 느낌이 들기 때문입니다.

저는 사람들에게 상업적인 라이벌 상태가 아닌, 자신이 개발해야 하는 디자 인 기준에 따라 두 개의 언어 중 적절한 것을 선택하라고 권장합니다. 저는 C++을 위한 디자인 표준(cirteria)을 The Design and Evolution of C++에서 개괄해 놓았습니다. 그리고 자바는 이러한 기준을 만족시키는 시작조차 못하 고 있습니다. 자바를 만병통치약으로 생각하지 않고 프로그래밍 언어의 하나 로 생각하는 것은 좋습니다. 결국, C++는 자바의 디자인 목표와 완벽하게 일 치하지 않습니다. 그러나, 자바가 유일한 프로그래밍 언어로써 진급된다면, 자 바의 결함과 제한은 심각하게 될 것입니다.

C++을 개발하는데 적용된 기준이 자바에는 적용되지 않는 몇 가지 예가 아 래에 있습니다.

○ 서로 다른 언어로부터 쓰여진 프로그램 부분들을 효과적으로 조합하는

능력

○ 다양한 디자인 스타일과 프로그램 스타일

○ 기정의 타입(built-in type)과 맞먹는 효율을 가진 사용자 정의 타입

○ 기정의 타입과 사용자 정의 타입의 일관된 처리(treatment)

○ STL처럼 실행시 부담없는 일반 컨테이터(generic container)를 사용하는 능력

프로그래머들이 우아하고 효율적인 코드를 작성할 수 있도록 제가 C++을 디자인했습니다. 많은 응용프로그램을 위해서, 우아함과 효율성을 타협하기를 원하지 않을 때 C++은 여전히 최상의 선택입니다.

저는 어떻게 사람들이 "프로그래머"를 세는지 의문입니다. 학생이 프로그래 머입니까? PC에 컴파일러를 가진 사람은 모두 프로그래머입니까? 저는 C++ 을 위해서 인용된 숫자를 이해합니다. 그것은 보수적이고 그럴듯합니다. 그것 은 지난 해 실제 팔린 금액을 위한 C++ 프로그램의 수를 적절히 근사화한 것 입니다. 저는 Sun에서 주장하는 자바 프로그래머의 수가 같은 근거인지 의문 입니다. 부수적으로, 컴파일러 판매, 책 판매, C++ 수강생 수 등의 확실한 수 에 근거해서, 제가 추측하기로 C++ 프로그래머는 매년 10%∼20%증가하고 있 습니다.

그리고 저는 자바 팬(fan)이 아닙니다. 저는 과대 선전(hype)을 싫어합니다. 저는 프로그래머가 아닌 사람에게 프로그래밍 툴을 판매하는 시장 전략을 싫 어합니다. 저는 독점적인 언어를 싫어합니다. 그리고 저는 많은 프로그래밍 언 어를 좋아합니다. 기술적인 측면에서, 자바는 저에게 다른 언어에서 받았던 것 처럼, "와 깔끔한데!"란 인상을 주지 못했습니다. 자바는 제가 생각하기에 제 한적인 형태로 다른 유명한 언어의 기능들을 제공합니다.

자바는 많은 것을 C++로부터 빌려 왔습니다. 하지만 그렇게 많이는 아니며, 원하는 만큼의 이해와 맛(taste)도 빌려오지 못했습니다. 자바를 위한 중요한 약속들을 지키기 위해선, 자바는 성장해야 합니다. 이러한 전개는 C++보다 간 단하게 라는 자바의 주장과 타협할지도 모릅니다. 그러나 저의 추측에 그러한 노력은 현재의 것보다 더 좋은 자바 언어를 만들 것입니다. 현재, 자바는 언어 의 특징들과 "표준" 라이브러리를 꽤(quite a pace) 축적하고 있는 것처럼 보 입니다. 저는 자바 버전의 템플릿이 나타날 것을 기대하고 있습니다.

자바와 그의 공동체가 성숙해가면서, 활기있고 활기있게 하는 철학 (live-and-let-live philosophy)을 희망적으로 채택할 것입니다. 이것은 자바가 프로 프로그래머들의 소중한 도구(tool chest)중의 한 언어로 자리잡게 할 것 입니다.

도구(TOOLS)

Computer: 지난 몇 년간 어떤 방법으로 시스템이 변화했습니까? 그리고 C++의 활동범위(arena)와 일반적인 시스템 디자인에 무엇이 더 필요합니까? C++가 비교적 성장한 이 시점에서, 사용할 수 있는 C++ 툴(tool)들을 어떻게 평가하겠습니까? 그리고 여전히 개선되어야 하는 것은 어떤 것들입니까?

Stroustrup: 먼저, 컴파일러, 디버거, 프로파일러(profiler)(역주: 프로그램의 성능 분석을 위한 도구), 데이터베이스 인터페이스, GUI 빌더, CAD 툴과 ISO 표준을 지원하는 기타 기본 툴들을 살펴보고자 합니다. 예를 들면, 저는 데이 터베이스 질의의 결과를 STL 컨테이너 혹은 적절한 객체 형의 istream으로 얻고 싶습니다. 툴 벤더(vendor)는 좋은 출발을 하였습니다. 하지만, 컴파일러 나 다른 소스 코드 분석기에 의존적인 작업을 너무 많이 하였습니다.

제가 리스트한 기본 도구들은 무엇이 바뀐지에 대한 부분적인 대답에 불과 합니다. 과거 몇 년 동안, 많은 수의 프로그래머들이 훌륭한 도구와 시스템 기 능을 제공하는 인터페이스 코드에 의존해 왔습니다. 이러한 도구들은 지루하 고, 에러 발생이 쉬운 작업으로부터 프로그래머들을 구제하는데 필수적입니다. 하지만, 프로그래머가(혹은 고용인이) 툴 제공자의 포로가 되는 위험에 처해 있습니다.

종종 이러한 도구들은 전통적인 프로그래밍 언어에 비해 더욱 복잡하며, 표 준은 거의 없습니다. 저는 독점성이(nonproprietary) 없는 도구와 라이브러리 를 추천하고 싶습니다. 짧은 안목으로 보면, 예를 들면 10년 정도, 많은 그러 한 표준은 형식적인 ISO 나 IEEE의 표준보다 산업계의 표준역할을 합니다. 하지만, 건강한 소프트웨어 산업을 위해, 중요 인터페이스는 잘 정의되고 대중 이 사용할 수 있는 것이 필수입니다.

COM이나 CORBA같은 시스템 레벨 객체를 위한 표준의 중요성이 증가하 는 가운데, C++가 그러한 것들과 깨끗하고(clean), 잘 문서화되어, 사용하기 쉽게 결합될 수 있는 것은 특별히 중요합니다. 불행하게도, 그러한 "표준 작 업" - 모두에게 이로운 - 은 누구에게도 짧은 안목의 이점을 제공하지 않기 때문에 소흘히 됩니다.

저는 사용 가능한 C++ 툴들을 평가하지 않겠습니다. 그것들은 매우 훌륭하 며, 다른 언어의 어떤 툴보다 더 좋습니다. 그러나, 프로그래머로서, 저는 당연 히 더 좋은 품질의 툴들을 바랍니다. 개인적으로, C++ 소스코드를 분석하는 더 좋은 툴들을 기대하고 있습니다. 저는 또한 C++ 컴파일러 벤더들이 신제 품을 개발하는 것보다, 자사 컴파일러의 품질과 수행 능력을 향상시키는데 예 산을 조금 더 투자하기를 기대합니다. 컴파일러의 실제적인 성능향상은 새로 운 버전의 완전한 C++ 컴파일러를 위한 시간보다 다소 저렴합니다. 그러나, 중요한 사용자들이 적응 테스팅(conformance testing)이나 벤치마킹 (benchmarking)을 요구하는 것을 시작하지 않는다면, 벤더들이 광고상 좋게 보이는 것을 위해 자원을 사용할 것을 느낍니다.

미래(THE FUTURE)

Computer: 저는 당신이 C++표준화 작업에 많이 참여한 것으로 알고있습니 다. 하지만, 현재 당신이 참여한 다른 프로젝트에는 어떤 것이 있으며, C++을 발전시키기 위해 어떤 작업을 계속할 것입니까?

Stroustrup: 나는 매우 큰 프로젝트를 성공적으로 완성하고 나서 고통받고 있습니다. ISO C++ 표준이 완성되었습니다. The C++ Programming Language의 제 3판에는 표준 C++이 무엇을 제공하는지 어떻게 가장 잘 사용 하는지 진지한 프로그래머들에게 알리고 있습니다. 그리고 Design and Evolution은 C++에 장착된(shaped) 디자인 결정들을 문서화하고 있습니다. 해 야할 것들이 아직 많습니다. 그러나 전시간 언어 디자이너를 필요로 하는 것 은 아무것도 없습니다. 이제 가능한 변화들에 집중하기 보다는, 코드를 작성함 으로써 C++의 힘과 유연성을 즐길 시간입니다.

그것과는 별도로, 저는 몇 가지 사실들을 배울 기회를 얻었습니다. 몇 새로 운 언어와 큰 사업에서 소프트웨어가 어떻게 사용되는지에 관한 것이 그것입 니다. 그리고 분산 컴퓨팅에서 몇 실험들을 계획중입니다.¤

Bjarne Stroustrup 은 AT&T의 대규모 프로그래밍 연구센터의 소장입니다; bs@research.att.com; http://www.research.att.com/~bs/