아는 동생 블로그에 놀러갔다가, ACM에서 발행된 기사를 보았습니다. 제가 좋아하는 비얀 아저씨의 인터뷰가 실렸더군요. 짧은 시력이나마 번역을 감히~ 시도해보았습니다. 틀린데가 있으면 꼭~ 지적해주세요~~~~
-----------------------------------------------------------------------------------------------
JB: When did you first become interested in computing, what was your first computer and what was the first program you wrote?
JB: 당신이 언제 처음으로 컴퓨터를 시작했죠? 그리고 당신의 첫 컴퓨터는 무엇이고 당신이 처음 만든 프로그램은 무었인가요?
BS: I learned programming in my second year of university. I was signed up to do "mathematics with computers science" from the start, but I don't really remember why. I suspect that I (erroneously) thought that computing was some sort of applied math.
BS: 난 대학 2학년때 프로그래밍을 배웠습니다. 난 2학년을 시작하면서 "mathematics with computers science"에 등록했었죠, 하지만 그 이유는 생각이 나지 않습니다. 내 생각에는 내가 컴퓨팅을 응용 수학의 한 부분으로 생각했던것 같습니다.
My fist computer was the departmental GIER computer. It was almost exclusively programmed in Algol-60. My first semi-real program plotted lines (on paper!) between points on the edge of a superellipse to create pleasant graphical designs. That was in 1970.
내 첫 컴퓨터는 매장에 있던 GIER 컴퓨터였습니다. 그것은 거의 알골60으로 프로그램 되어있었죠.
내가 처음만든 절반짜리 프로그램은 우스꽝스러운 그래픽 디자인을 만들기 위해, 커다란 원 가장자리상의 몇개의 점들과 몇줄의 코드사이에(그것도 종위 위에!) 구상되었습니다.
JB: When you created C++, was the object oriented programming (OOP) paradigm (or programming style) obviously going to gain a lot of popularity in the future, or was it a research project to find out if OOP would catch on?
JB: 당신이 C++을 만들었을때, OOP 패러다임이 장래에 분명 많은 인기를 얻거나, 혹은 C++가 OOP개념이 인기를 인기를 얻을지, 그렇지 않을지를 알게될 연구 프로젝트가 될것을 알았나요?
BS: Neither! My firm impression (at the time) was that all sensible people "knew" that OOP didn't work in the real world: It was too slow (by more than an order of magnitude), far too difficult for programmers to use, didn't apply to real-world problems, and couldn't interact with all the rest of the code needed in a system. Actually, I'm probably being too optimistic here: "sensible people" had never heard of OOP and didn't want to hear about it.
BS: 둘다 아닙니다. 저는 분명 모든 현명한 사람들이 OOP는 실세계에서 동작하지 않는다는것을 알것이라 생각했죠. 분명 OOP는 너무 느렸고, 프로그래머들이 사용하기에 너무 어려웠으며, 실세계의 문제들에 적용되지 않았습니다. 거기다가 시스템안에서 특히나 필요한 코드의 모든 부분들과 함께 상호작용하지 않았습니다.
사실 저는 이것에 대해 너무 낙관적이였던것 같네요. "현명한 사람들"은 OOP를 결코 듣지 못했을것이고 듣기를 원하지도 않았을 겁니다.
I designed and implemented C++ because I had some problems for which it was the right solution: I needed C-style access to hardware and Simula-style program organization. It turned out that many of my colleagues had similar needs. Actually, then it was not even obvious that C would succeed. At the time, C was gaining a following, but many people still considered serious systems programming in anything but assembler adventurous and there were several languages that?like C?provided a way of writing portable systems programs. One of those others might have become dominant instead of C.
저는 C++을 디자인하고 구현했습니다. 왜냐하면 저는 이것이 정확한 해결책인지에 대한 명가지 질문들을 가지고 있었거든요. 저는 C스타일의 하드웨어 접근방식과, Simula스타일의 프로그램 설계방식이 필요했습니다. 이것은 저의 많은 동료들이 가지고 있던 비슷한 요구사항들이었습니다. 사실 C가 성공적이라는것은 명백하지 않았죠. 그 당시에 C는 신봉자들을 가지고 있었지만 많은 사람들은 여전히 어려운 어셈블러이외에서 중요한 시스템 프로그래밍을 생각하고 있었습니다. 그리고 포터블 시스템 프로그램들을 만들 방법을 제공하는 - C와 같은- 몇몇의 언어가 있었습니다.
JB: Before C++, did you "just have to create C++" because of the inadequacy of other languages, for example? In essence, why did you create C++?
JB: C++이전에, 단지 다른 언어들의 부족한 점 때문에 C++을 만들었나요? 본질적으로 왜 C++을 만들었죠?
BS: Yes, I created C++ in response to a real need: The languages at the time didn't support abstraction for hard systems programming tasks in the way I needed it. I was trying to separate the functions of the Unix kernel so that they could run on different processors of a multi-processor or a cluster.
BS: 네 저는 실세계의 필요에 의해서 C++을 만들었습니다. 그 당시의 언어들은 어려운 시스템 프로그래밍 업무들을 위한, 내가 필요한 방식의 - 추상화를 지원하지 않았습니다. 저는 함수들이 다중 프로세서나 클러스터의 다른 프로세스들위에서 동작할 수 있게 하기 위해서 Unix 커널의 함수를 분리하는것을 시도하고 있었습니다.
JB: Personally, do you think OOP is the best programming paradigm for large scale software systems, as opposed to literate programming, functional programming, procedural programming, etc.? Why?
JB: 개인적으로 당신은 문학적 프로그래밍이나 기능단위의 프로그래밍, 혹은 절차적 프로그래밍보다 OOP가 거대 소프트웨어 시스템들을 위한 최고의 프로그래밍 페러다임이라고 생각하나요?
BS: No programming paradigm is best for everything. What you have is a problem and a solution to it; then, you try to map that solution into code for execution. You do that with resource constraints and concerns for maintainability. Sometimes, that mapping is best done with OOP, sometimes with generic programming, sometimes with functional programming, etc.
BS: 모든 시스템에 최고인 프로그래밍 패러다임은 없습니다. 당신이 가지고 있는것은 문제이면서 해결책이죠. 당신은 실행을 위한 코드에 그 해결책을 씌우는것을 시도할것입니다. 당신은 제한적인 자원으로 그것을 하고, 유지보수가능성에 대해서 걱정하겠죠. 때로는 OOP가 때로는 제네릭 프로그래밍이, 때론 기능단위의 프로그래밍이 가장 적합할 수 있습니다.
OOP is appropriate where you can organize some key concepts into a hierarchy and manipulate the resulting classes through common base classes. Please note that I equate OO with the traditional use of encapsulation, inheritance, and (run time) polymorphism. You can choose alternative definitions, but this one is well-founded in history.
OOP는 공통 베이스 클래스들에 기반한 클래스를 조작하고, 계층구조를 이용해 몇가지 핵심 개념을 설립하는것에 적합합니다. 내가 OO(Object Oriented)를 캡슐화와 상속 그리고 (실시간)다형성의 전통적인 사용법과 동등시한것을 주목해주세요. 당신은 두 정의중 하나를 선택할 수 있죠. 하지만 이것은 역사속에서 충분히 근거가 있는것입니다.
I don't think that literate programming is a paradigm like the others you mention. It is more of a development method like test-driven development.
나는 문학적 프로그래밍이 당신이 말했던 다른 언어들과 같은 패러다임이라고 생각하지 않아요. 그것은 테스트기반 개발처럼 개발 방법에 더 가깝습니다.
