c++은 장난이다?
1998. 1. 1., Bjarne Stroustrup는 IEEE Computer지와 인터뷰 했다.
자연스럽게 편집자는 그가 C++을 창조한 당사자로서 7년간의
object-oriented 설계에 대한 종합적인 의견을 보여주리라 생각했다.
인터뷰가 끝날 즈음, Interviewer는 그의 기대 이상의 것을 알게 되었고,
편집자는 '산업계의 이익'을 위해 그 내용을 편집하기로 하였으나,
세상 만사가 그렇듯이 비밀은 없다.
다음은 편집되지 않은 완전한 대화 내용이며, 따라서 인터뷰 계획만큼 정리
되어 있진 않다.
Interviewer: 예, 당신이 소프트웨어 설계의 세계를 바꾼지도 수년이 지난
지금 어떻게 생각하십니까?
Stroustrup: 사실 당신이 도착하기 전 그것을 생각하고 있었죠.
기억하십니까? 모든 사람들이 'C'를 사용하고.. 문제는 그들이 아주
전문가였다는 점입니다. 대학에서도 C를 매우 훌륭히 가르쳤습니다.
졸업생들은 아주 *유능*했습니다. 이것이 문제가 되었습니다.
Interviewer: 문제요?
Stroustrup: 예. 모든 사람들이 코볼을 쓰던 시절을 기억하십니까?
Interviewer: 물론이죠.
Stroustrup: 글쎄요, 초창기에 이들은 거의 신이었죠. 높은 보수와 귀족
대우를 받았습니다.
Interviewer: 그런 시절이었죠.
Stroustrup: 그래요. 그래서 어떻게 되었습니까? IBM은 이것에 불만이었고
프로그래머들의 교육에 수백만불을 투자하여 마침내 백여명 정도의
인원을 길렀습니다.
Interviewer: 그게 바로 제가 그만둔 이유입니다. 보수가 1년만에
저널리스트 보다 적은 수준으로 떨어졌습니다.
Stroustrup: 그렇습니다. 'C'프로그래머에게도 마찬가지 일이 일어났죠.
Interviewer: 그렇군요, 근데 요점이 무었입니까?
Stroustrup: 글쎄요, 하루는 제 사무실에 앉아서 보다 균형을맞게 하기
위한 작은 계획에 대해 생각했습니다. 이런 생각을 했죠.'무척 배우기
힘든 복잡한 언어가 있다면.. 그래서 아무도 감히 프로그래머가
되려고 하지 않을 만큼.. 과연 어떨까?' 실제로 많은 아이디어를
X 윈도우(X10)에서 가져왔습니다.
이 형편없는 그래픽 시스템은 Sun 3/60에서만 돌았습니다.
제가 원하는 모든 요소가 여기 있었죠. 우스꽝스러울 만큼 복잡한
문법, 애매한 함수, pseudo-OO 구조. 지금도 아무도 순전한 X 윈도우
코드를 작성치 않습니다. 제정신이라면 Motif만이 유일한 도구이죠.
Interviewer: 진심입니까..?
Stroustrup: 사실입니다. 실제로 다른 문제도 있었습니다. 유닉스가 C로
씌어졌지요, 즉 어떤 C 프로그래머도 쉽게 시스템 프로그래머가 될
수 있단 의미지요. 한때 메인프레임의 시스템 프로그래머가 얼마나
벌었는지 기억하십니까?
Interviewer: 물론입니다, 제가 한때 시스템 프로그램을 했었죠.
Stroustrup: 좋습니다, 따라서 유닉스와 언어를 결합하는 모든 시스템
콜들을 감춤으로써, 새로운 언어는 유닉스와의 결별하도록 해야
했습니다. 이는 DOS만 아는 사람들도 왠만한 소득을 벌 수 있게끔
했습니다.
Interviewer: 믿을 수 없는 예기군요...
Stroustrup: 글쎄요, 이미 시간이 지났지만 지금쯤은 사람들이 스스로
C++가 시간 낭비였다는 것 깨달았을 겁니다. 제 생각보다 훨씬
뒤늦은 일이지만요...
Interviewer: 그래서 실제로 어떤 식으로 하였습니까?
Stroustrup: 사실 단지 장난이었을 뿐이었습니다, 사람들이 제 책을
진지하게 받아들이리라 생각치 않았습니다. 두뇌가 반이라도 있다면
object-oriented 프로그래밍이 반직관적이고, 비논리적이고
비효율적이란 걸 알 수 있습니다.
Interviewer: 뭐라구요?
Stroustrup: 또 '재사용 가능 코드'를 보세요. 한번이라도 코드를
재사용하는 회사에 대해 들어 보셨습니까?
Interviewer: 글쎄요, 아니요, 하지만...
Stroustrup: 그렇습니다. 초기에 소수 회사가 시도는 했었죠. 오레곤의
Mentor Graphics사가 90, 91년도에 모든 코드를 C++로 재작성 하다가
크게 혼난적이 있습니다. 이에 대해 진심으로 유감스럽게 생각했었죠.
다만, 우리는 실수로부터 배워야 한다고 생각했습니다.
Interviewer: 물론입니다. 그래서 사람들이 교훈을 얻었습니까?
Stroustrup: 천만에요. 문제는, 대부분 회사들이 중요 실수들을 감추려
든다는 겁니다. 3천만불 손실을 주주들에게 설명하는 걸
어려워하지요. 그래도 공이 아주 없는 것은 아닙니다. 결국에는 뭔가
해내었지요.
Interviewer: 그래요? 글쎄, 그렇다면, OO가 성공했다는 거네요.
Stroustrup: 글쎄요, 거의.. 실행코드가 매우 컸습니다. 128MB RAM의
HP 웍스테이션에서 로드하는 데 5분 걸렸습니다. 실행는 더 엄청
오래 걸렸습니다. 실제 이것이 중요한 장애물이 되리라 생각했고
1주안에 모두 이를 알아차릴 것으로 짐작했습니다만, 아무도 신경쓰지
않더군요. Sun과 HP는 엄청난 파워의 머신을 판매하는 데 신이났죠,
단지 작은 프로그램들을 실행키 위해 엄청난 리소스를 필요로 하는..
AT&T에서 첫 C++ 컴파일러를 가지고 'Hello world'를 컴파일 하고
2.1MB라는 믿을 수 없는 크기의 실행코드가 나왔었죠.
Interviewer: 네? 글쎄요, 컴파일러는 많이 개선되었죠, 그 이후로..
Stroustrup: 그럴까요? 최신 버젼의 g++에서 한번 해보세요. 1/2 메가
이상은 될겁니다. 또한, 세계 각지의 최근의 예들도 많습니다.
British Telecom이 큰 위기를 당할뻔 했으나 운좋게 벗어나서 다시
시작할 수 있었습니다. 이들은 Australian Telecom보다 운이 좋았죠.
지금은 지멘스가 공룡을 만들고 있다는 군요. 실행코드를 저장하기
위한 하드웨어가 점점 커짐에 따라 우려도 커지고 있다고 합니다.
이래도 multiple inheritance가 좋습니까?
Interviewer: 예, 하지만 C++는 기본적으로 적절한 언어이지요.
Stroustrup: 그걸 믿습니까? 한번이라도 C++ 프로젝트를 해본 적이
있습니까? 사정은 이렇습니다: 아주 소규모의 프로젝트만이 첫 시도에
성공할 만큼 함정을 많이 만들었습니다. 연산자 overloading을
봅시다. 프로젝트가 끝날 무렵, 거의 모든 모듈에서 이걸 사용합니다.
보통, 사람들은 교육 과정에서 그랬듯이, 그래야만 한다고 생각하기
때문이죠. 같은 연산자가 각각의 모듈에서 제각기 다른 의미를 갖게
됩니다. 전부 모아 놓으면 백여개의 모듈이 됩니다.
이제 data hiding을 봅시다. 각 모듈들이 서로 대화하게 함으로써
문제를 만들어 내는 회사들을 보면 웃지 않을 수 없습니다.
'synergistic'이란 말은 프로젝트 관리자의 가슴을 후벼파기 위해
만들어 진 게 아닌가 합니다.
Interviewer: 정말 어처구니 없군요. 프로그래머의 보수를 높이기 위해
이 모든 걸 했다구요. 한심하군요.
Stroustrup: 꼭 그렇지만 않습니다. 누구나 선택이 있습니다. 이렇게
까지 문제가 커질 줄은 몰랐습니다. 어쨌든, 저는 기본적으로
성공했습니다. C++는 이제 죽어가고 있습니다. 하지만 프로그래머들은
여전히 높은 보수를 받습니다. 특히 이 모든 문제들을 관리하는
불쌍한 사람들은요.. 당신이 실제로 작성한 게 아니면, 방대한 C++
소프트웨어 모듈을 관리하는 게 불가능 한 것을 알겁니다.
Interviewer: 어떻게요?
Stroustrup: 아는지 모르겠군요, typedef 기억하세요?
Interviewer: 그럼요.
Stroustrup: 변수 'RoofRaised'가 double precision 이란걸 겨우 찾아내기
위해 얼마나 오래 헤더 화일들을 뒤져야 하는지 아시죠? 대형
프로젝트에서 모든 클래스들에 있는 implicit한 typedef들을 찾는데
얼마나 걸릴지 생각해 보세요.
Interviewer: 그래서 어떻게 해서 성공했다는 거죠?
Stroustrup: 평균적인 'C' 프로젝트의 기간이 어느 정도 걸리죠? 약 6개월
입니다. 부인과 아이들이 있는 사람이 여유있게 살만큼 충분한 기간이
아닙니다. 동일한 프로젝트를 C++로 설계하면 어떨까요? 1년 내지 2년
입니다. 대단하지요? 잘못된 결정이 이 모든 안정된 직업을 가져온
셈입니다.
또 있습니다. 오랜 기간 대학에서 C를 가르치지 않은 결과, 이제
훌륭한 C 프로그래머가 부족합니다. 특히 Unix 시스템 프로그래밍의
전문가가요. 오랫동안 'new'을 써온 지금, 'malloc'을 제대로 사용할
줄 아는 사람이 몇명이나 될까요? return 값을 체크하느라 신경쓰는
일도 없죠. 실제로 대부분 C++프로그래머들은 return값을 그냥
내버립니다. '-1'을 쓰는 일은 이제 추억이 되었습니다. 적어도
'throw', 'catch', 'try' 같은 걸 쫓아다니지 않고도 에러가 있다는
걸 알 수 있던 시절이었죠.
Interviewer: 하지만 inheritance는 시간 절약을 해주지 않습니까?
Stroustrup: 그럴까요? C프로젝트 계획과 C++프로젝트 계획의 차이를
아십니까? C++ 프로젝트의 계획 단계가 3배는 길게 걸립니다. 어떤
부분이 inherit를 해야 하고어떤 부분이 안되는지 정확히 가려내야
합니다. 그리고 나서는, 여전히 뭔가 잘못되어있지요. C 프로그램에서
memory leaks이 있을 수 있습니까? 지금은 이걸 찾는 게 회사들의
중요 일이 되었습니다. 대부분 회사들이 포기하고는 그냥 제품을
내놓습니다. leak이 있다는 걸 다 알면서도 단지 그걸 찾아내는
비용을 줄이기 위해서 입니다.
Interviewer: 그걸 해주는 tool들이 있쟎아요...
Stroustrup: 그것들의 대부분도 C++로 작성되었죠.
Interviewer: 이 인터뷰가 출판되면, 당신은 아마 린치를 당할 겁니다.
안그렇습니까?
Stroustrup: 글쎄요. 말씀 드렸듯이 C++는 이제 전성기를 지났습니다.
정상적인 회사라면 선행 시도(pilot trial)을 안해보고 C++
프로젝트를 착수하지 않을 겁니다. 이를 통해서 재앙으로 가는
길이라는 걸 확인할 수 있어야 합니다. 그렇지 못하다면 그 결과는
그들의 책임입니다.
제가 Dennis Ritchie에게 C++로 Unix를 재작성토록 하려 했단 걸
아시죠?
Interviewer: 뭐라구요. 그가 뭐라고 했습니까?
Stroustrup: 다행히 그는 유머 감각이 있습니다. 그와 Brian이 제가 무슨
짓을 하고 있는지 알아냈다고 생각합니다. 그는 제가 좋아한다면,
C++ 버젼의 DOS를 작성하는 걸 돕겠다고 했습니다.
Interviewer: 흥미가 있으셨습니까?
Stroustrup: 실제로 C++로 DOS를 작성했습니다. 끝나는 대로 demo를
드리겠습니다. 컴퓨터실의 Sparc 20상에서 실행시키고 있습니다.
4 CPU에서 엄청난 속도로 실행되고, 70메가 정도의 디스크를
차지합니다.
Interviewer: PC에서는 어떻습니까?
Stroustrup: 농담이십니까? Windows 95아시죠? 저는 Windows 95를 저의
최대 성공으로 생각합니다. 비록 제가 준비하기도 전에 시합을 끝낸
셈이지만요.
Interviewer: Unix++에 대한 아이디어는 정말 생각해볼만 합니다.
어디선가 누군가 시도를 하겠지요.
Stroustrup: 이 인터뷰를 읽은 다음엔 포기하겠죠.
Interviewer: 죄송합니다만, 이 인터뷰를 출판할 수 있을 것 같지 않군요.
Stroustrup: 하지만 이것은 세기의 스토리입니다. 제가 동료
프로그래머들을 위해 한 일로 인해 제가 기억되기를 바랄 뿐입니다.
오늘날 C++ 프로그래머들이 얼마나 버는지 아십니까?
Interviewer: 제가 알기로, 제일 잘나가는 프로그래머는 시간당
칠팔십불정도이지요.
Stroustrup: 그렇죠? 그 정도 될겁니다. 제가 C++에 집어넣은 모든 기능을
파악하는게 보통 일이 아닙니다. 그리고 전에 말씀드렸듯이, 모든
C++프로그래머들이 어떤 프로젝트를 하던지, C++의 그 모든 빌어먹을
요소들을 다 사용해야 한다는 강박관념 같은 걸 느낍니다. 이건 가끔
저를 화나게 합니다, 그게 아무리 저의 처음 의도 였지만요. 결국
저는 C++언어를 좋아합니다.
Interviewer: 전엔 좋아하지 않았습니까?
Stroustrup: 싫어했었죠. 심지어 C++가 지저분하지 않습니까? 하지만 책의
인세가 들어오기 시작하면서... 글쎄요, 아시겠지요?
Interviewer: 잠깐요. reference는 어떤가요? C 포인터보다 개선된 것
아닙니까?
Stroustrup: 음.. 그거에 대해 항상 의문이었습니다. 처음엔 개선이라고
여겼습니다. 근데, 하루는 C++를 처음부터 써온 친구와 얘기할 기회가
있었습니다. 그는 변수들이 reference되었는지 dereference되었는지
도무지 기억 할 수가 없어서 항상 포인터를 쓴다더군요. '*'덕분에
쉽게 알 수 있다더군요.
Interviewer: 글쎄요, 보통 이때쯤이면 '대단히 고맙습니다'라고 말하게
되는데 오늘은 그렇기 힘들겠는데요.
Stroustrup: 인터뷰를 출판해 주십시오. 요새 제 양심이 많이 좋아지고
있습니다.
Interviewer: 나중에 알려드리겠습니다만, 편집장께서 뭐라고 할지 알 수
있습니다.
Stroustrup: 어쨌든 누가 믿겠습니까? 테입 복사한 걸 보내주실 수
있습니까?
Interviewer: 그럼요.
c++은 좋다?
여기 Linux Focus에서 취재한 내용중에서 발췌한 내용임다.
Dennis M. Ritchie와의 인터뷰 중
L.F.: UNIX가 과거와 현재의 운영체제라면, 최근 객체지향언어가 등장함
에도 불구하고, C는 별다른 논란없이 대표적인 "프로그래밍 언어"
라고 할 수 있습니다. Dennis씨는 C++와 Java를 어떻게 보시는지
요? 그리고 C 프로그래머와 C++프로그래머 사이의 흔히 등장하는
논쟁에 대해서는 어떻게 생각하시는지요?
Dennis: C는 C++이 성장하기 전에도 상당히 많은 부분을 수용했고, C++은
C를 새로운 언어를 만드는 기반으로 그리고, 그것의 컴파일러를
만드는 수단으로 삼았기 때문에, C는 C++ 에게 큰 유익을 주었다
고 할 수 있습니다. C는 이식가능한 어셈블리 언어라고 말할수 있
다.(좋기도하고 때로는 나쁘기도 하지만) 그리고,C++는 그 수준을
객체지향언어로 올리려하고 있고, 더욱 추상적인 프로그래밍을
하도록 합니다. 그 두개의 단점은 (최근에 만들어진 기준에 의하
면) 너무 장식적이고, 자질구레한 것이 많다는 것입니다. Java가
포인터를 통한 작업과 같은 C의 유산을 없애고, 기계독립적인
object 화일을 만드는 (새롭지 않은, 그러나 이제서야 구현 가능
하게 된) 아이디어를 더한, C++의 후손이라는 것은 명백합니다.
그것은 Sun과 Microsoft 사이의 음모에 붙잡혀 있고 (물론 그것도
나름의 장식물로 인한 문제가 있지만), 앞으로 어떻게 될 것인지
는 추측하기 힘듭니다.
<-- 자세한 내용은 여기에
http://www.linuxfocus.org/Korean/articles/article26.html
http://www.linuxfocus.org/English/July1999/article26.html
C has been characterized (both admiringly and invidiously)
as "a Portable Assembly Language", and C++ tries to lift its
level to object orientation and a more abstract approach
to programming
OO가 등장한 이유를 뭐라고 생각합니까??
단디 코딩의 우아함을 위해 등장한 것이 아닙니다.
바로 코딩을 쉽게 하기 위해서입니다..!!
C처럼 구조적 프로그래밍만 가지고는 커다란 프로젝트를 수행하는 것이
한계대 다다랐다고 생각을 했고, 코드의 재사용성과 효율성을 극대화하기
위해서 등장한 것입니다. (물론 지금도 C로도 커다란 프로젝트가
많이 진행되고 있고, 잘 진행되고 있습니다.)
그런데 사실상 C++은 C보다 쉬운 방법을 제공하지만은 않습니다.
C++의 객체지향의 냄새가 휙 풍기는 여러 GUI프로그래밍이나
좀 덩치가 큰 그런 프로젝트는 OO를 이용하는 것이 유리할 수 있습니다.
그 외에 간단한 프로그램이나 하드웨어를 컨트롤 하는 디바이스 드라이버,
커널 등(C++은 이미 하드웨어쪽을 위한 언어에서는 많이 벗어났습니다.)
을 OO개념을 도입해 C++로 만든다는 것은 무리가 있습니다.
또, C는 C++보다 훨씬 많은 호환성을 제공하고 OO적으로 프로그래밍이
불가능한 것은 아닙니다. 그리고 사실 C++은 C를 너무나도 수용하려고
들었기 때문에 여타 다른 OO언어 (JAVA같은)보다 배우기가 어렵고,
구조적 프로그래밍과 혼동하기 쉬운 단점이 있습니다. 그것도 C를 선호하게
되는 이유가 되겠죠..
그 C의 호환성때문에 프로젝트 자체는 C로 하고 C++로의 바인딩만을
제공하는 경우도 있죠.(GTK+과 gtkmm 처럼)
UNIX는 거의 완벽한 C 프로그래밍 환경(IDE가 아닌, 시스템 프로그래밍을
위한 환경)을 제공하고, 또한 작은 것이 아름답다는 철학을 가지고 있기에,
그런 곳에서 궂이 C++를 주장하는 것은 정말로 어리석은 일입니다.
(GUI분야같은 곳은 제외입니다..)
한마디로 각각 쓰일 데가 있다는 것입니다. 하나만 주장하는 것은
옳지 않습니다..
마지막으로 하나만 얘기하자면 우아함이 실용적인 시대는 아닙니다.
우아함도 실용적이어야 쓸만한 것입니다. C++이 실용적이지 못하는게 아니고,
C++을 잘 쓰면 우아하면서 실용적으로 쓸 수 있습니다. 그게 바로
OO를 만든 목적인 것입니다. 실용적이지 못하면서 우아하기만 한 것은
실전에 쓸 수가 없습니다. 연구의 목적에 어울리는 것이지..
http://www.linuxfocus.org/English/July1999/article79.html |
|hit:4481|2003/04/14
|
|
| xacdo |
|
저 C++ 만든 사람, 실은 1년동안 팽팽 놀다가 연봉협상 한달 앞두고 해놓은게 없으니까 실적 내려고 한달만에 C++이란 걸 만들었는데, 워낙 복잡하고 난해했던 탓에 실제 제대로 동작하는 C++ 컴파일러가 나오기까지 10년이나 걸렸다고 하지.
사실 객체지향을 C++로 구현하는 것은 상당히 힘들다. 그래서 아직도 많은 사람들이 C++을 이용해서 예전 C 스타일의 구조적 프로그래밍을 하지. 이 C++이라는 것은 예전에 C를 쓰던 사람들이 "객체지향을 하긴 해야겠는데 새로운 거 익히기는 쉽고 어디 쉽게 넘어가는 거 없나.." 라고 생각할 것을 감안해서 만든 거긴 하지만, 차라리 C++이 없었으면 제대로된 객체지향으로 넘어가는 것이 더 빨랐을 거라고 생각함. 즉 C++은 구조적 프로그래밍과 객체지향 프로그래밍 사이에서 갈등하는 개발자를 위한 일종의 사기같은 상술 아니었을까.
하지만 그런 사기같은 상술은 여전해서, C나 C++이랑 그리 비슷하지도 않으면서 이름만 C#이라고 지어서 기존 C 프로그래머들을 끌어드리려는 수작은 여전한 것 같다. |
2003/04/14 |
|
| xacdo |
|
어쨌건 프로그래머의 입장에서는 받아들일 수 밖에 없는 win32같은 프레임웍을 일부러 어렵게 만들었다는 이야기는 정말로 화가 난다. 지금이야 많은 부분 추상화가 이루어져서 그럭저럭 쓸만하긴 하지만 일부러 문턱을 높였었다니 이런 참 사람하고는.. |
2003/04/14 |
|
작도닷넷 피드백의 장으로
|
