|
언어 혁명의 선구자 Bjarne Stroustrup
이따금 혁신적인 도약을 통해 엔지니어링의 모든 분야가 진보하고 변화해왔습니다.
소프트웨어 개발에 있어 이러한 도약은 C++ 프로그래밍 언어의 개발을 통해서 이루어졌습니다.
이러한 도약이 가능했던 것은 언어 자체에 의한 것은 아니었습니다.
Simula67이나 Smalltalk와 같은 개체 지향 언어는 C++ 이전에도 존재했습니다.
이러한 도약이 가능했던 것은 C++가 C 프로그래밍 언어에 기반을 두고 있었으며 개체 지향적 추상화를 프로그래밍 분야의 주 무대로 끌어들였기 때문입니다.
C++는 심지어 기존 C 프로그램을 컴파일할 수도 있었습니다.
C++는 디자인 패턴에서 메타 프로그래밍에 이르기까지 소프트웨어 디자인과 개발에 관련된 엄청나게 많은 아이디어에 영감을 제공했습니다.
또한 하드웨어 플랫폼 간의 이식성과 효율적인 저수준 제어 기능 덕분에 더 빠르고 작은 하드웨어에서 필수적인 존재가 되었습니다.
필자는 최근 C++의 창시자인 Bjarne Stroustrup과 언어에 대한 그의 견해에서 전반적인 업계 경향과 그의 최근 독서 목록에 이르기까지 다양한 주제에 대한 이야기를 나누었습니다.
질문 중 상당수는 필자의 블로그에 독자 여러분들이 보내 주신 질문 중에서 채택한 것입니다.
질문을 보내 주신 여러분들께 감사드립니다.
물론 인터뷰에 응해 주신 Bjarne에게도 감사 인사를 전합니다.
언어에 대한 생각
Howard Dierking 프로그래밍 언어가 마치 언어 광신자의 집단과 같이 사람들을 밀접하게 연결하는 이유는 무엇일까요?
Bjarne Stroustrup 그런 질문은 컴퓨터 과학자가 아니라 심리학자나 사회학자, 혹은 경제학자에게 적당할 것 같습니다.
제 생각에는 아이디어를 표현하기 위한 언어가 우리 자신의 일부가 되면서 한 가지 언어만 아는 사람들에게 다른 언어의 지지자가 개인적인 위협으로 느껴질 수 있는 것 같습니다.
만약 그렇다면 더 많은 언어에 대해 배우는 것이 해결책이 될 것입니다.
개인적으로는 한 가지 프로그래밍 언어만 알아서는 소프트웨어 분야에서 전문가가 될 수 없다고 생각합니다.
경제적인 이유도 있을 것입니다.
기본적인 개념은 모든 프로그래밍 언어에 있어 동일하지만 많은 실제 기술을 보면 그렇지 않은 경우가 많습니다.
예를 들어 언어 X와 도구 집합만 사용할 수 있는 사람에게 언어 Y와 도구 집합을 사용하도록 강요한다면 그 사람의 생계를 위협하는 것일 수 있습니다.
이 경우에도 역시 해결책은 다양한 언어와 도구 집합에 대해 배우고 확고한 기본 지식을 갖추는 것입니다.
아쉽게도 제가 제시하는 해결책은 대부분의 사람들에게 필요한 업무를 모두 마치고 남는 시간이 그리 많지 않다는 것은 고려하지 않은 것입니다.
그렇지만 한 가지 언어에 집착하는 데 대한 변명이 될 수는 없을 것입니다.
HD
소프트웨어 개발에서 IDE의 역할은 어떤 것이 되어야 할까요?
IDE가 언어를 어떻게 지원해야 한다고 생각하십니까?
BS
저는 IDE를 많이 사용하지는 않습니다.
제가 사용하는 언어를 위한 기능을 제공하는 응답성이 우수한 IDE 편집기를 높게 평가하지만 IDE 없이도 작업할 수 있기를 원합니다.
어디에서나 사용할 수 있는 훌륭한 IDE가 있었다면 다른 의견을 가지게 되었을 수 있을 것 같습니다만 실제로는 IDE가 언어의 일부이거나 언어가 IDE의 일부가 되는 경우가 많습니다(그림 1 참조).
코드 이식성이 필요하다는 생각 역시 제가 IDE를 좋아하지 않는 중요한 이유입니다.
C++에 있어서 저는 소스 파일에 포함된 소스 코드를 통해 시스템을 이해할 수 있기를 원합니다.
때문에 사람이 사용할 수 있는 코드로 나타낼 수 없는 변환이나 생성을 수행하는 IDE 메커니즘을 좋아하지 않습니다.
 HD
현재의 범용 언어에서 노이즈나 가독성이 문제가 된다고 생각하십니까?
그렇다면 해결책은 무엇일까요?
BS
물론 복잡한 구문보다는 간단한 구문이 좋을 것입니다.
그러나 대부분의 사람들이 가독성에 대해 불평할 때는 실제 텍스트의 복잡성이 아니라 표현하려는 개념의 복잡성이 원인이라고 생각합니다.
개중에는 어떤 언어로 작성된 어떤 프로그램이든지 약간의 온라인 지원 기능을 사용하면 프로그램을 나타내는 데 사용된 모든 구조와 프로그램의 논리를 이해할 수 있다고 생각하는 사람이 너무 많은 것 같습니다.
이를 우리가 사용하는 자연 언어와 비교하여 어떨까요?
셰익스피어풍 14행시를 아무런 배경 정보 없이 이해할 수 있겠습니까?
고대 영어로 쓰여진 베오울프 원전이라면 또 어떨까요?
우리의 프로그래밍 언어에서 너무 많은 것을 기대하고 있는 것일 수 있습니다.
광범위한 응용 프로그램에 필요한 모든 것을 표현할 수 있는 언어는 특정한 응용 프로그램에 대해서는 지나치게 복잡하게 보일 수 있습니다.
그러나 언어는 제한 없는 응용 프로그램을 지원할 수 있어야 합니다.
특정한 경우에는 특정한 분야에 국한된 언어가 도움이 될 수 있지만 이 경우에도 많은 언어의 복잡성과 해당 상호 작용이 문제가 됩니다.
HD
범용 언어가 구성 요소 프로그래밍과 서비스 프로그래밍과 같은 응용 프로그램 디자인 개념을 어떻게 지원해야 한다고 생각하십니까?
BS
범용 언어는 일반적인 개념 및 응용 프로그램별 개념을 나타내는 라이브러리 작성과 지원 도구 개발을 지원해야 하며 응용 프로그램의 다른 부분을 연결하는 기능도 제공해야 합니다.
이를 위해 언어에 필요한 것이 유연성, 표현성이 우수한 형식 시스템, 높은 기본 성능, 그리고 장기적 안정성입니다.
HD
다중 디스패치가 바람직한 것입니까?
BS
예.
Simula, C++, Smalltalk, Java 및 C#과 같은 기존의 단일 디스패치 개체 지향 언어로는 런타임까지 정확한 형식을 알 수 없는 상황에서 숫자를 곱하거나 두 가지 모양의 교집합을 찾는 등의 간단한 작업을 매끄럽게 표현할 수 없습니다.
이중 디스패치, 방문자 패턴 등을 사용하는 결과 코드는 느리며 유지 관리가 쉽지 않습니다.
Dylan이나 CLOS와 같이 런타임에 다중 디스패치를 지원하는 언어는 이러한 면에서 더 우수하며 컴파일 시에 이를 지원하는 C++와 같은 언어도 어느 정도는 도움이 됩니다.
작년에 저는 제자들과 함께 C++에 다중 디스패치를 깔끔하게 추가하는 방법에 대한 연구 논문을 발표했습니다.
다중 디스패치를 사용한 사례의 결과 코드는 다른 어떤 해결책을 사용한 코드보다 짧고 단순하며 메모리를 적게 소모하고 빠르게 실행됩니다(그림 2 참조).
그러나 이 연구는 C++0x에 활용하기에는 너무 늦게 완료되었습니다.
논문은 research.att.com/~bs/multimethods.pdf에서 볼 수 있습니다.
 HD
현재 C++의 공변성(Covariance) / 반공변성(Contravariance)에 대해서는 어떻게 생각하십니까?
현재의 동작이 향후 언어 버전에서 변경될 것으로 예상하십니까?
BS
그렇지 않습니다.
이 부분에서는 C++의 현재 동작이 타당하다고 생각합니다.
vector<Apple>을 vector<Fruit>로 변환하는 것과 같은 예를 생각하고 있습니까?
vector<Fruit>가 변경 가능하거나 여기에 Orange를 추가할 수 있다면 이것은 매우 위험하다는 것을 알아야 합니다.
저는 암시적 런타임 형식 검사가 이 문제에 대한 좋은 접근 방법이라고 생각하지 않습니다.
HD
메시지 전달을 메서드 호출과는 다른 핵심 언어 기능으로 만드는 데 대해서는 어떻게 생각하십니까?
BS
명시적 메시지 전달은 마음에 들지만 제 경우에는 오래전에 분산 시스템 환경에서만 이를 사용했습니다.
현실적으로 말해 이를 대규모 환경에서 지원하려면 언어 자체, 그리고 메시지 전달을 지원할 도구에 상당히 많은 작업이 필요합니다.
제가 알고 있는 바로는 아직 이러한 작업은 이루어지지 않고 있습니다.
메시지와 메시지 큐를 사용한다면 공유와 잠금에 관련된 많은 문제가 해결될 것입니다.
이를 위한 표준 C++ 라이브러리가 나오기를 바라며 2년 안에 현실화될 수도 있을 것 같습니다.
HD
범용 언어에서 광범위하고 다양한 사용자층을 지원하는 동시에 코드의 표현성 향상 및 정교한 디자인을 장려한다는 점에서 구조적인 충돌이 있다고 생각하십니까?
후자를 지원하기 위한 언어의 역할은 무엇입니까?
BS
전문화를 통해 정교함을 이룰 수 있다는 인식이 있는 것 같습니다.
또한 대상(사용자 커뮤니티)이 작은 규모라면 이들의 취향을 고려할 수 있으며 사용자 커뮤니티를 제어할 수 있는 방법이 있다면 기존의 표기법이나 개념을 벗어나는 것도 가능합니다.
예를 들어 "이 기능을 사용하려면 형식 이론을 읽어야 합니다"와 같이 말할 수 있습니다.
범용 언어는 다양하고 광범위한 사용자를 지원해야 하는 것은 물론 교육 수준이 크게 다른 다양한 그룹의 사용자에게 가르칠 수 있어야 합니다.
기본적인 내용은 수준이 떨어지는 교사에게 교육을 받는 고교생도 이해할 수 있어야 합니다.
그러니까 범용 언어는 언어 내에서 표현할 수 있는 수준까지는 정교함을 권장할 수 있다고 생각합니다.
C++의 경우에는 매우 정교한 코드를 작성할 수 있습니다.
범용 언어의 일부가 되어 널리 사용할 수 있게 되면 이러한 예는 수백만 명의 사용자에게 전달되며 수백만 명이 읽는 기사와 서적에 실리게 됩니다.
정교하지만 전문화되지 않은 언어가 가진 옵션이라고 할 수 있겠죠.
HD
우리가 아키텍처를 너무 강조한 것은 아닐까요?
BS
아니요, 적어도 제가 아키텍처를 정의하는 방법에 따르면 그렇지 않습니다.
오히려 아키텍처를 너무 등한시한 나머지 구조적 원칙에 대한 이해가 부족하여 나쁜 코드가 양산되고 있다고 봅니다.
제 생각에 아키텍처와 관련한 가장 큰 문제는 좋은 코드를 작성하려면 어떻게 해야 하는가에 대한 막연한 개념을 가진 프로그래머가 너무 많다는 것입니다. 좋은 코드를 보고 알아볼 수 있는 능력만으로는 부족하며, 하지 말아야 할 일에 대한 규칙을 만드는 것으로도 부족합니다.
우리에게 필요한 것은 명확하고 규범적인 규칙입니다.
HD
소프트웨어 품질, 디자인, 그리고 직업 의식면에서 공개 소스 커뮤니티가 도움이나 방해가 됩니까?
혹은 전혀 영향이 없습니까?
BS
정말 어려운 질문이군요.
코드의 품질을 향상시키거나 관련된 사람들의 직업 의식을 높이는 긍정적인 경우도 보았으며, 정말 나쁜 습관이나 태도를 가르치는 부정적인 경우도 보았습니다.
그리고 좋다 나쁘다를 말할 수 없는 경우도 많았습니다.
커뮤니티 전반에 어떤 영향을 미쳤는지, 그리고 공개 소스의 영향이 더 크거나 작았을 경우에 어떤 현상이 발생했을지를 추측할 수 있는 방법은 없습니다.
이러한 추측을 하기에 커뮤니티는 너무 거대합니다.
언어 추세
HD
가까운 장래에 동적 언어로의 급격한 변화를 예상하십니까?
BS
그렇지 않습니다.
사람들은 사과와 오렌지를 너무 자주 비교하는 것 같습니다.
일반적으로 정적 언어와 동적 언어 사이에서 선택할 수 있다고 생각하지는 않으며 게다가 언어가 이러한 두 범주 중 하나에 완벽하게 맞는 것도 아닙니다.
거의 모든 동적 언어에는 정적으로 결정되는 측면이 있으며, 모든 주요 정적 언어에는 값의 의미를 런타임에 결정하도록 하는 기능이 있습니다.
물론 유행이라는 것이 있으며 이러한 부분을 예상할 수는 없겠지만 현실적인 언어 선택은 대부분 응용 프로그램의 요구 사항과 응용 프로그램의 영역 및/또는 개발자의 기술에 따라서 이성적으로 이루어져왔습니다.
예를 들면 저라면 Ruby를 사용하여 Java 런타임을 구현하려고 한다거나 고도의 대화형 시뮬레이션 언어를 C++(구현과는 달리)와 같이 표현하지는 않을 것입니다.
HD
궁극적으로 모든 void*/variant/object/등을 제거하는 것이 바람직하다고 생각하십니까?
그림 3에는 이에 대한 좋은 예가 나와 있습니다.
BS
기본적으로는 모든 포괄적인 옵션을 제거하는 것이 좋겠지만 현실적으로 이를 위해서는 표현하려는 모든 항목에 대한 완벽한 분류를 수행하여 항상 세부적으로 지정할 수 있어야 합니다.
예를 들어 모든 개체에 대해 작업을 수행할 수 있는 함수는 본 적이 없습니다.
무엇인가를 수행하려면 항상 조작하려는 대상에 대한 약간의 가정이 필요합니다.
순수한 전달 함수는 아마도 이러한 예를 거스르는 가장 가까운 예일 것입니다.
현재 C++ 세계에서 진행 중인 몇 가지 작업(제네릭 알고리즘에 대한 제약 조건/요구 사항)이 이 부분에서 도움이 될 수 있겠지만 예상하지 못한 필요를 위해 "무엇인지 알 필요가 없는 무엇"을 나타낼 수 있는 진정으로 일반적인 메커니즘이 완전히 필요없게 되리라고는 생각하지 않습니다.
HD
느슨한 형식의 언어로 되돌아가는 추세를 감안하여 헝가리식 표기법 사용을 다시 고려해야 하는 것일까요?
BS
그러한 추세가 있는지는 확실하지 않습니다만 전체 작업 중에서 느슨한 형식의 언어가 맞는 작업이 증가하고 있는 것 같습니다.
다른 말로 하면 필자의 생각으로 정적인 형식의 언어 사용 역시 증가하고 있지만 느슨한 형식의 언어 사용이 더 빠른 속도로 증가하고 있는 것 같습니다.
그리고 헝가리식 표기법은 사용하지 마십시오.
헝가리식 표기법은 좋지 않은 아이디어입니다.
소스 코드는 형식 시스템을 시뮬레이션하는 것이 아니라 프로그램의 의미를 반영해야 합니다.
정말로 헝가리식 표기법이 필요하다고 느낀다면 응용 프로그램에 맞지 않는 언어를 사용하고 있는 것일 수 있습니다.
HD
2000년에 박사님은 "C++:A New Language for a New Millennium"이라는 프레젠테이션에서 Wrap<T>의 개념을 소개하셨습니다.
이것은 기본적으로 AOP(Aspect-Oriented Programming)였습니다.
AOP에 대해서 일반적으로, 그리고 Wrap<T> 패턴(Pointcut, Advice 등)의 해당 형식화에 대해서 어떻게 생각하시는지 알려 주십시오.
BS
AOP에 대해서는 아직 확실한 답을 제시할 만큼 충분히 살펴보지 못했습니다.
저는 다른 작업에 영향을 주지 않는 결합을 언어 자체("지원하지 않음"이나 "도구를 통한 지원"이 아니라)에서 지원하는 것이 바람직하다고 생각합니다.
추가 언어 도구와 비표준 도구 체인에 대해서는 우려하고 있습니다.
C++ 템플릿은 영향을 주지 않는 결합에서 놀라운 성공을 거두었습니다.
STL(Standard Template Library)과 임베디드 시스템 프로그래밍에서의 몇 가지 사용 예를 확인해 보십시오.
엄격하거나 미리 설계된 계층을 강제하지 않고도 아이디어를 결합할 수 있다는 것은 매우 강력한 능력입니다.
그러나 일부 개발자와 관리자에게는 관리하기가 어려웠던 것도 사실입니다.
표기법에서도 복잡했습니다.
C++0x에는 유연성이나 성능 저하 없이 이 문제를 해결하기 위한 시도가 포함되어 있습니다.
HD
C++ 언어의 몇 가지 특징은 매크로와 같은 부분에서 몇 가지 의도하지 않은 까다로운 부작용을 일으키기도 했습니다.
C++나 다른 최신 언어에서 해결되기를 바라는 다른 의도하지 않은 부작용에는 어떤 것이 있습니까?
BS
사실은 C를 사용하기 시작할 때 매크로가 까다롭다는 것을 알았습니다.
하지만 대부분의 다른 사람들처럼 그 까다로운 정도와 파급되는 부정적 영향을 과소평가했습니다.
C에서 매크로의 광범위한 사용은 10년 전에 최적의 C++ 개발 환경을 갖출 수 없었던 주요 원인 중 하나였습니다.
C++에서는 또한 개체를 초기화하기 위한 방법이 너무 많고 혼란스러웠습니다.
C++0x에서는 단일화된 메커니즘으로 이 문제를 해결하기를 원했습니다.
앞서의 질문에 대한 해답으로 템플릿을 언급했습니다.
이후의 C++(1985 이후)에서 템플릿은 큰 성공을 거두었지만 이러한 성공은 언어를 제약을 가하는 결과를 가져왔습니다.
이 부분도 역시 C++0x에서 해결될 것입니다.
우리가 수년 동안 발견한 많은 사소한 문제와 제법 중요한 문제들은 호환성 문제 때문에 C++에서는 해결할 수 없었습니다.
예를 들어 선언자 구문은 불필요하게 복잡했으며 다른 선형 표기법이 나았을 것입니다.
비슷하게 기본 설정이 잘못된 것이 많았습니다.
예를 들면 생성자는 기본적으로 변환이 되지 말아야 했으며, 이름은 기본적으로 다른 소스 파일에서 액세스할 수 없어야 했습니다.
링커를 제어하지 않은 것이 항상 변하지 않는 문제의 근원이었습니다.
특히 구현 개발자는 비슷한 기능을 호환되지 않는 형태로 제공하는 것을 즐기는 것 같았습니다.
긍정적인 효과도 있었습니다.
가장 주목할 예로 리소스 관리 및 오류 처리(예외 사용)와 관련된 기술에서 광범위한 소멸자 사용을 들 수 있습니다.
생성자의 효과를 뒤집는 기능이 필요하기 때문에 소멸자가 좋은 아이디어라는 것은 알고 있었습니다.
하지만 이것이 C++를 올바르게 사용하는 데 얼마나 중요하게 사용될지는 몰랐던 것입니다.
HD
박사님의 웹 사이트를 보면 "언어 자체에서 정교함을 찾기보다는 응용 프로그램을 정교하게 작성해야 한다고 생각합니다."라는 내용을 볼 수 있습니다.
DSL(Domain Specific Language)로의 이동이 이러한 부분의 수렴을 의미하는 것입니까?
BS
거의 그렇다고 할 수 있습니다.
이러한 방향을 위한 시도이며,때로는 성공하기도 합니다.
HD
DSL에 대해서는 전반적으로 어떻게 생각하십니까?
DSL과 범용 언어 간의 관계에 대해서는 어떻게 예측하십니까?
BS
저는 많은 언어가 설계되고, 구현되고, 멋진 선전과 함께 소개되지만 큰 영향을 주지 못하고 사라져가는 현상에 대해 걱정하고 있습니다.
이러한 새로운 언어는 몇 년간 이어지는 긴 개발 기간 동안 상당히 많은 리소스를 소비하지만 실질적인 결과물을 내놓지 못하는 경우가 많습니다.
이러한 현상에 대해 조명하는 "A Rationale for Semantically Enhanced Library Languages"(research.att.com/~bs/SELLrationale.pdf)라는 논문을 쓰기도 했습니다.
이 논문에서 저는 도구에서 지원하는 라이브러리와 범용 언어를 사용할 것을 권장했습니다.
DSL은 첫 번째가 아니라 마지막 선택이 되어야 한다고 생각합니다.
가능하다면 DSL은 범용 언어와 표준 도구 체인에 탄탄한 기반을 두어야 합니다.
DSL은 자체 구현과 자체 런타임 기본형의 구현에 범용 언어(또는 최소한 시스템 프로그래밍 언어)가 필요합니다.
의식적으로라도 DSL을 한 개 이상의 범용 언어와 견고하게 연결하여 해당 범용 언어로 작성된 라이브러리를 사용하여 손쉽게 새로운 기능을 추가할 수 있도록 하는 것이 바람직합니다.
전문가라면 분명 몇 가지 언어를 통달해야 할 것이지만 여러 DSL의 복잡성이 더해진다면 곧 문제가 될 것입니다.
또한 많은 DSL이 스스로 범용 언어가 되고 싶어 한다는 점도 문제입니다.
HD
다양한 하드웨어의 다른 정의 때문에 C++의 많은 구문을 의도적으로 모호하게 남겨두었다고 언급하신 적이 있습니다.
지금이라도 이러한 구문 중 일부를 명확하게 할 수 있는 상호 운용성 측면의 개선이 있었습니까?
BS
"모호함"은 맞지 않는 표현인 것 같습니다.
너무나 많은 부분이 정의되지 않은 상태 또는 구현이 정의된 상태로 남겨졌습니다.
C++를 처음부터 다시 정의할 수 있다면 정의되지 않은 동작은 없을 것이며 구현이 정의된 부분은 훨씬 줄어들 것입니다.
그러나 아쉽게도 타임머신은 없으며 현재의 해결책을 가지고 어마어마한 양의 코드 줄을 다시 작성할 수도 없는 노릇입니다.
방법론과 최상의 방법
HD
박사님이 선호하는, 그리고 사용하도록 가르치는 방법론은 무엇입니까?
BS
응용 프로그램 핵심 개념 식별, 유용한 라이브러리 식별, 응용 프로그램 개념의 지원에서 새로운 라이브러리 작성, 아이디어 조기 테스트, 조기 통합, 조기에 자주 테스트, 설명서와 자습서 자료를 디자인 도구로 사용, 작은 프로그램에서 큰 프로그램으로 키우기(과정에서 반복)가 있습니다.
현재는 비교적 작은 프로젝트에 집중하고 있다는 것을 알 수 있을 것입니다.
HD
언어와 개발 방법론 간에 공통점이나 유사성이 있다고 생각하십니까?
BS
라이브러리 설계를 설계/개발 기술로 본다면 그렇다고 생각합니다.
라이브러리 작성 과정에 걸쳐 응용 프로그램에 가까운 점차 높은 수준의 기능에 초점을 맞추면 언어에 요구 사항이 늘어납니다.
이 부분을 강조하지는 않겠습니다.
하지만 예를 들어 COBOL, C, Java, C++ 및 Python을 위한 단일 개발 방법론이 있다고 생각하지는 않으며 각 언어에서 최소한의 지원 이상을 기대할 수 있을 것으로도 생각하지 않습니다.
HD
소프트웨어를 개발할 때 개인적으로 중요하게 여기는 사항이 있다면 무엇입니까?
BS
핵심 개념에 집중, 해당 인터페이스에 집중, 리소스(메모리, 파일, 잠금 등) 관리에 집중, 오류 처리에 집중이 있습니다.
클래스용 고정의 올바른 설계, 그리고 RAII(Resource Acquisition Is Initialization)는 핵심 기술입니다.
HD
Agile에 대한 이야기가 많습니다.
박사님에게 "Agile"은 어떤 의미입니까?
C++가 Agile을 지원합니까?
BS
너무 애매하기 때문에 저는 그 단어를 사용하지 않습니다.
물론 의미가 어떤 것이든 C++는 Agile을 지원합니다.
미래에 대한 예측
HD
언어가 템플릿, 동적 이벤트, 자체 작성 코드와 같은 고급 기능을 지원하도록 발전하면서도 동시에 초보자가 배울 수 있는 수준을 유지할 수 있는 방법은 무엇입니까?
BS
저도 잘 모르겠습니다.
일반적인 대답이 있다고는 생각되지 않습니다.
새로운 기능이 언어 환경에서 더 효과적인 기술을 지원한다면 이를 중요하게 여길 수 있을 것입니다.
그러나 더 중요한 것은 안정성입니다.
C와 C++가 경쟁력을 이어갈 수 있었던 이유 중 하나는 수십 년 전에 작성된 기존 코드가 계속 유효하도록 유지하고 새로운 기능을 매끄럽게 통합하려는 표준 위원회의 노력이 있었기 때문입니다.
이것은 쉽지 않은 일이며 새로운 기능 추가가 항상 성공적이었던 것은 아닙니다.
초보자에 대한 배려가 표준 위원회 회원들이 의해 무시되는 경우도 많았습니다.
C++0x를 위해 계획된 단일 초기화, 해당 이니셜라이저에서 변수 형식을 유추하는 auto 키워드, 템플릿 인수 요구 사항을 검사하는 개념와 같은 몇 가지 핵심 기능은 비전문가도 언어를 더 쉽게 사용할 수 있도록 하기 위한 것입니다.
HD
언어 메타데이터가 향후 프로그래밍 언어의 핵심 기반이라고 생각하십니까?
BS
그렇지 않습니다.
개인적으로 중요한 곳에 메타데이터를 사용하는 것을 불편하게 생각합니다.
HD
CPU에서 코어의 수가 증가하면 향후 동시성에 근본적인 변화가 있을 것으로 예상합니까?
C++0x에서는 동시성의 과제가 어떻게 해결될까요?
BS
C++0x는 다중 스레딩에 적합한 기계 모델, 라이브러리 작성을 위한 저수준 기본형 집합, 그리고 스레드 및 잠금 라이브러리 API와 같은 기반을 제공합니다.
앞으로 몇 년이 더 걸리겠지만 특히 스레드 모델, 미래 및 메시지 큐에 기반을 두는 더 간단한 고수준 동시성 모델과 같은 다양한 기능이 추가되기를 기대합니다.
자동 또는 자동에 가깝게 계산을 여러 프로세서에 분산하고 이러한 프로세서에서 작업을 지역화하는 방법을 찾아야 합니다.
이러한 영역에서, 특히 C++에서는 많은 작업이 필요하지만 아직 독보적인 모델은 없습니다.
예로는 Texas A&M University의 STAPL과 Intel의 TBB가 있습니다.
HD
GPU에서의 범용 컴퓨팅(GPGPU)에 대해서는 어떻게 생각하십니까?
BS
크게 기대할 수는 없을 것 같습니다.
그러나 특수한 용도의 프로세서를 활용하는 데는 많은 기술이 필요하다는 명백한 사실 외에 의견을 제시할 만한 실제적인 경험은 없습니다.
HD
궁극적으로 프로그래머에게 HPC(고성능 컴퓨팅)가 투명하게 제공되리라고 생각하십니까?
또한 이 목표가 언어나 라이브러리 또는 프레임워크 중 어디에 속하게 되겠습니까?
BS
어느 정도는 투명하게 제공될 것입니다.
그러나 동시성이 완전하게 투명하게 제공될 수 있다고 생각하지는 않으며 그렇게 되어서도 안 됩니다.
우선 오류 처리는 프로세서, 공유(또는 비공유) 메모리, 분산(또는 비분산), 지연 시간의 사용 가능성에 따라 매우 달라질 수 있습니다.
적절한 상황에서 투명도를 어림잡는 일은 새로운 언어, 새로운 언어 기능, 그리고 제가 가장 선호하는 경우인 새로운 라이브러리의 목표로 남게 될 것입니다.
후자는 기본 언어가 기계 모델에 필요한 기본적인 보장과 매우 저수준의 기본형 집합을 제공해야만 가능합니다.
C++0x는 이를 제공합니다.
HD
C++0x 설계는 어떻게 진행되고 있습니까?
BS
이제 거의 끝났습니다.
적어도 저는 그렇게 바라고 있지만 최종 투표가 있기 전까지는 아무 것도 확실한 것이 없으며 완료 시기가 가까워질수록 긴장과 흥분이 더해질 것입니다.
현재 계획은 6월에 완전한 새 표준을 일반에 공개하는 것이며 이렇게 하면 12에서 18개월 후에 새로운 공식 표준이 완료됩니다.
이 새로운 주제에 대한 새로운 책을 쓸 수도 있을 것입니다.
새로운 표준은 어떻게 만들며, 기본 원칙은 무엇이며, 어떤 내용들이 들어 있는가 하는 점에 대한 것입니다.
사실 이에 대한 글이 있습니다. 자세한 내용은 저의 HOPL 논문 "Evolving a language in and for the real world:C++ 1991-2006"(research.att.com/~bs/hopl-almost-final.pdf 참조)과 필자의 홈 페이지에서 C++0x를 다루고 있는 문서들을 참조하십시오.
시간이 정말 충분하다면 웹에서 "WG21"을 찾아보거나 제안을 포함하여 ISO C++ 표준 위원회에서 발표한 모든 논문을 찾아 보십시오.
이를 통해 많은 작업이 필요하다는 것을 알 수 있을 것입니다.
널리 사용되고 있는 프로그래밍 언어를 개선하는 일은 어렵습니다.
특히 엄청나게 많은 도구, 언어 및 응용 프로그램의 구현 계층에 사용되고 있는 언어라면 더욱 그렇습니다.
제 C++ 페이지나 온라인에서 저나 다른 사람이 만든 몇 가지 비디오도 볼 수 있습니다.
책과 전화
HD
요즘 어떤 책을 읽고 계십니까?
BS
기술 서적으로는 기계 아키텍처에 대한 기억을 되새기는 의미에서 Hennessy and Patterson을 다시 읽고 있습니다.
또한 제자들을 가르치기 위해 좋은 코드를 작성하도록 도와주는 논문과 기사를 모으고 있습니다.
이러한 기사를 찾는 것은 예상보다 어려웠습니다.
학술 논문은 지나치게 전문적인 경우가 많았고 비학술 논문은 거창한 서론에 비해 증거가 미약한 경우가 많았습니다.
제안이 있으면 환영합니다.
그리고 물론 C++ 표준화와 엄청나게 많은 관련 문서들이 있습니다. Knuth의 책을 다시 읽을 계획이었는데 누군가 제 볼륨 III 책을 빌려간 모양입니다.
돌려줄 때까지 기다려야 할 것 같습니다.
재미를 위해서는 O'Brian의 Aubrey와 Maturin 시리즈를 읽고 있으며과학에 대한 이해를 되새기는 의미에서 Richard Dawkins의 저서를 읽고 있습니다.
또한 최근에는 Rodger의 "Command of the Ocean:A Naval History of Britain, 1649-1815"를 읽었습니다.
HD
박사님께서는
"나는 컴퓨터가 전화기처럼 사용하기 쉽게 되기를 바란다.
그리고 그 희망은 이루어진 것 같다.
이제는 전화기 사용법도 어려워졌기 때문이다."
라고 말씀하셨습니다.
스마트폰을 가지고 계십니까?
아직도 사용하기 어려우시던가요?
BS
저는 전화를 그다지 좋아하지 않습니다.
직접 대면하는 대화를 좋아하고 그것이 어렵다면 글을 주고받습니다.
아무리 환상적인 전화라고 해도 잘 다듬은 전자 메일에 비할 바는 아닙니다.
전화기는 주머니에 넣어도 편안한 슬림폰을 사용하고 있지만 기능은 거의 사용하지 않습니다.
음질이나 신뢰성과 관련된 모든 기능은 포기했습니다.
그래도 제가 위와 같은 언급을 했던 때와 비교하면 사용자 인터페이스가 많이 개선된 것 같습니다.
Howard Dierking 은 MSDN Magazine 편집장입니다.
### 출처 : MSDN Magazine / 저작권자 : Microsoft Corporation ###
|
'MSDN' 카테고리의 다른 글
| #S# [MSDN][.NET] WebClient로 비동기 I/O 사용 (0) | 2009/06/26 |
|---|---|
| #S# [MSDN] 단순히 보기 좋은 그림 그 이상 (0) | 2009/06/21 |
| #S# [MSDN] 언어 혁명의 선구자 Bjarne Stroustrup (0) | 2009/06/21 |
| #S# [MSDN][ASP.NET/AJAX] ScriptManager를 통해 웹 응용 프로그램에서 AJAX 사용 (0) | 2009/06/21 |
| #S# [MSDN][ASP.NET] ASP.NET 응용 프로그램의 확장 전략 (0) | 2009/06/20 |
| #S# [MSDN][.NET][WPF] Top Ten UI Development Breakthroughs In Windows Presentation Foundation (0) | 2009/06/01 |
