OOP에 대해 이해하는 바가 다르고 절차지향적 프로그래밍과 OOP를 비교하는 글들이 있지만 이것들이 확실히 OOP를 설명하고 있다고 생각이 들지 않았던 이유가 있었다.
첫번째로, "누가" 이 말을 만들었는지 "어떤"의도로 만들었는지가 매우 궁금했고 몇가지 자료를 찾았다. 그중 하나로 스테판 람이란 사람이 OOP라는 말을 처음 사용했던 엘런케이와 주고 받은 편지가 온라인에 있어, 원문을 한번 번역해 보았습니다.
아래는 그 번역입니다.
--------------------------------------------------------------------------------------------------------
Date: Wed, 23 Jul 2003 09:33:31 -0800
To: Stefan Ram [removed for privacy]
스테판 람에게
From: Alan Kay [removed for privacy]
엘런케이로부터
Subject: Re: Clarification of "object-oriented"
답장 : 객체지향에 대한 해명
[some header lines removed for privacy]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Content-Length: 4965
Lines: 117
Hi Stefan --
안녕 스테판
Sorry for the delay but I was on vacation.
답장이 늦어서 미안해요. 휴가중이었습니다.
At 6:27 PM +0200 7/17/03, Stefan Ram wrote:
> Dear Dr. Kay,
> 케이 박사님께
>
> I would like to have some authoritative word on the term "object-oriented programming" for my tutorial page on the subject.
> 저는 제 강의 페이지의 주제로 OOP라는 용어에 대해 정식으로 이야기를 나누고 싶습니다.
> The only two sources I consider to be "authoritative" are the International Standards Organization, which defines "object-oriented" in "ISO/IEC 2382-15", and you, because, as they say, you have coined that term.
> 제가 유일하게 권위있다고 생각했던 두개의 출처는 ISO/IEC 2382-15에 "객체지향"을 정의한 국제표준조직과 박사님이었습니다. 왜냐하면, 그들이 말하듯, 박사님이 그 용어를 만들었기 때문입니다.
I'm pretty sure I did.
맞아요 제가 그랬죠
>
> Unfortunately, it is difficult to find a web page or source with your definition or description of that term.
> 안타깝지만, 용어에 대한 정의나 설명이 있는 웹페이지나 원본을 찾기가 힘들었습니다.
> There are several reports about what you might have said in this regard (like "inheritance, polymorphism and encapsulation"), but these are not first-hand sources.
> 상속, 다형성, 캡슐화와 같은 것들과 관련해서 박사님이 말했다고 여겨지는 것에 대한 몇개의 보고서가 있습니다만, 이것들이 원본은 아닙니다.
> I am also aware that later you put more emphasis on "messaging" - but I still would like to know about "object oriented".
> 저는 또 좀더 뒤에 박사님이 "메시징"에 대해 강조하셨던 걸 알고 있으며, 여전히 "객체지향"에 대해 알고 싶습니다.
>
> For the records, my tutorial page, and further distribution and publication could you please explain:
> 여러 기록들, 제 강의 페이지, 추후 배포, 그리고 출판물들을 위해서 아래 몇가지 질문에 설명을 부탁드립니다.
>
> When and where was the term "object-oriented" used first?
> 언제 그리고 어디서 "객체지향"이란 용어를 처음 사용하셨습니까?
At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming.
유타에서 1966년도 11월이후 어느날엔가, Sketchpad, Simula, ARPAnet에 대한 디자인, Burroughs B5000, 생물학과 수학에 대한 나의 배경지식에 영향을 받아서, 저는 프로그래밍 아키텍쳐에대해 생각하고 있었습니다.
It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming".
누군가 나보고 지금 무엇을 하고 있는지 물었을 때가 아마 1967년도였고, 저는 그게 "객체 지향 프로그래밍"이라고 말했습니다.
The original conception of it had the following parts.
그것의 원래의 개념은 아래 부분에 나옵니다.
- I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).
- 저는 오직 메시지로만 커뮤니케이션 할 수 있는 생물학적인 세포같은 무언가 또는 단일 네트웤상의 각각의 컴퓨터들에 대해 생각하고 있었습니다. (그래서 메시징은 매우 초기부터 있었고, 충분히 유용할만큼 효율적으로 프로그래밍언어 안에서 메시지를 주고받는 방법을 보기까지는 시간이 좀 걸렸습니다.)
- I wanted to get rid of data. The B5000 almost did this via its almost unbelievable HW architecture.
- 저는 데이터를 없애고 싶었어요, B5000는 거의 신뢰하기 어려운 하드웨어 아키텍쳐 위에서 이것을 했습니다.
I realized that the cell/whole-computer metaphor would get rid of data, and that "<-" would be just another message token (it took me quite a while to think this out because I really thought of all these symbols as names for functions and procedures.
세포와 전체 컴퓨터 비유가 데이터를 제거할수 있고, "<-"기호는 단지 또다른 메시지 기호일수도 있다는 것을 알게 되었습니다. (제가 이 생각을 지우는데도 시간이 좀 걸렸습니다. 왜냐하면 저는 모든 이러한 심볼들을 함수나 프로시져를 위한 이름으로서 생각하고 있었거든요.)
- My math background made me realize that each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful.
저의 수학적인 배경지식은 각 객체가 관련된 몇몇 공식들을 가질수 있으며, 이에 연관된 분류들이 존재할수 있고, 매우매우 유용할수 있다는 것을 깨닫게 해주었습니다.
- The term "polymorphism" was imposed much later (I think by Peter Wegner) and it isn't quite valid, since it really comes from the nomenclature of functions, and I wanted quite a bit more than functions.
- "다형성"이라는 용어는 (제생각에 피터 웨그너라는 사람에 의해서) 매우 나중에 추가되었고, 그렇게 타당하지도 않습니다. 그 이유는 그것이 함수들의 명명법으로부터 나왔고, 저는 함수보다는 훨씬 더 나은 무언가이길 바랬죠.
-
- I made up a term "genericity" for dealing with generic behaviors in a quasi-algebraic form.
- 저는 "보편성"이라는 용어를 유사대수학 형태의 일반적인 행동들을 다루기 위해 만들었습니다.
- I didn't like the way Simula I or Simula 67 did inheritance
(though I thought Nygaard and Dahl were just tremendous thinkers and designers).
저는 Simular 1이나 Simula 67이 상속했던 방법을 좋아하지 않습니다. (니가드와 달이란 사람들이 엄청난 사색가이면서 디자이너라고 생각하지만...)
So I decided to leave out inheritance as a built-in feature until I understood it better.
그래서 저는 그게 더 낫다고 생각될때까지 내장기능으로서의 상속을 제거하기로 마음먹었습니다.
My original experiments with this architecture were done using a model I adapted from van Wijngaarten's and Wirth's "Generalization of Algol" and Wirth's Euler.
이 아키텍쳐에 대한 제 원래의 실험들은 위즌가텐과 윌스의 "알골의 일반화" 윌스의 Euler로부터 차용된 모델을 사용해서 진행됬습니다.
Both of these were rather LISP-like but with a more conventional readable syntax.
두개모두 좀 LISP같았지만 더욱 규약적이고 가독성좋은 문법을 가지고 있었습니다.
I didn't understand the monster LISP idea of tangible metalanguage then, but got kind of close with ideas about extensible languages draw from various sources, including Irons' IMP.
만질수 있는 메타언어라는 괴물같은 LISP아이디어를 이해했을 뿐만 아니라 Iron들의 IMP를 포함해서 다양한 소스로부터 연상되는 확장성있는 언어들에 관한 아이디어에 가까워 질수 있었습니다.
The second phase of this was to finally understand LISP and then using this understanding to make much nicer and smaller and more powerful and more late bound understructures.
이 다음에는 결국 LISP를 이해하게 되었고 이 이해를 사용해서 좀더 멋지고, 작고, 강력하고, 하부 구조에 늦게 바인딩되도록 만들게 되었습니다.
Dave Fisher's thesis was done in "McCarthy" style and his ideas about extensible control structures were very helpful.
데이브 피셔의 논문은 "McCarthy" 스타일로 완성이 되었고, 확장가능한 제어 구조에 관한 그의 아이디어는 매우 유용했습니다.
Another big influence at this time was Carl Hewitt's PLANNER (which has never gotten the recognition it deserves, given how well and how earlier it was able to anticipate Prolog).
그때의 또 다른 큰 영향은, 칼 휴렛의 "PLANNER"였습니다. (얼마나 멋지고, 빠르게 Prolog(언어)를 앞질렀던지, 마땅히 받아야할 주목을 받지 못했습니다.)
The original Smalltalk at Xerox PARC came out of the above.
제록스 PARC에서 원조 Smalltalk는 그 위에서 나왔습니다.
The subsequent Smalltalk's are complained about in the end of the History chapter: they backslid towards Simula and did not replace the extension mechanisms with safer ones that were anywhere near as useful.
스몰토크의 다음버전은 역사의 마지막장에서 비난 받았습니다.. 그들은 Simula로 타락했고 확장 매커니즘을, 어디서나 유용했던 좀더 안전한것으로 교체하지 않았습니다.
>
> What does "object-oriented [programming]" mean to you?
> "객체지향프로그래밍"이 당신에게 의미하는 것은 무엇입니까?
> (No tutorial-like introduction is needed, just a short explanation [like "programming with inheritance, polymorphism and encapsulation"] in terms of other concepts for a reader familiar with them, if possible.
> 강의같은 설명은 하지 않아도 되구요. 가능하시다면 그것들에 친숙한 독자를 위해, 다른 개념들에 관한 단지 짧은 설명이면 됩니다(ex/상속, 다형성 그리고 캡슐화의 프로그래밍)
> Also, it is not neccessary to explain "object", because I already have sources with your explanation of "object" from "Early History of Smalltalk".)
> 또, 객체에 대한 설명은 안해주셔도 됩니다. 제가 이미 "스몰토크의 초기 역사"에서 박사님의 "객체"에 대한 설명이 담긴 자료를 가지고 있습니다.
>
>
(I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.)
(저는 타입에 대해 적대적이지는 않습니다만 완벽하게 고통이 없는 타입시스템은 본적이 없습니다. 그래서 여전히 다이나믹 타이핑을 좋아합니다.)
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
저에게 있어서 OOP는 오직 메시징, 지역보존 및 보호, 상태-처리의 은닉, 모든것들에 대한 최후의 late-biding(Dynamic Binding)입니다.
It can be done in Smalltalk and in LISP.
스몰토크와 LISP에서 가능합니다.
There are possibly other systems in which this is possible, but I'm not aware of them.
이러한 것들이 가능한 다른 시스템들이 있을수 있지만 저는 그러한 시스템을 모릅니다.
Cheers,
화이팅,
Alan
앨런
>
> Thank you,
>
> Stefan Ram
>On Wed, Jul 23, 2003 at 09:33:31AM -0800, Alan Kay wrote:
>> OOP to me means only messaging, local retention and protection and
>> hiding of state-process, and extreme late-binding of all things.
>
> Hi Alan,
안녕하세요 알렌
>
> I just want to say "thank you" for your explanations
설명너무 감사하다고 말씀드리고 싶어요
> (including the parts not quoted above)!
(위에 인용된 내용말고도 전부)
>
> "local retention" is a new notion to me in the context of OOP, and I assume it refers to state-process and means that an object is in possession of its state-process, so that the state of an object is kept locally with the object and not elsewhere.
OOP의 문맥에서 "지역보존"이라는 말이 저에겐 생소했는데요, 제가 생각하기에 상태-처리를 설명하는 것으로 생각되고, 객체가 그자신의 상태-처리를 소유하고 있다, 그래서 객체의 상태는 다른 곳이 아닌 객체안에 유지된다고 생각됩니다.
>
> I have published your reply on the web, but have removed the E-Mail addresses and similar header lines for privacy.
제가 박사님의 답변을 웹에 올렸습니다만 프라이버시를 위해서 이메일주소와 유사한 해더는 삭제했습니다.
>
> Thanks again,
>
> Stefan
--
E-Mail of 2003-07-26
Clarification of "object-oriented", 1 [E-Mail]
Date: Sat, 26 Jul 2003 13:47:59 -0800
To: Stefan Ram [removed for privacy]
스테판 람에게
From: Alan Kay [removed for privacy]
엘런 케이가
Subject: Re: Clarification of "object-oriented"
객체지향의 해명
[some header lines removed for privacy]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Content-Length: 3145
Lines: 68
One of the things I should have mentioned is that there were two main paths that were catalysed by Simula.
제가 언급하고 싶었던 것들중 하나는 Simular에 의해 촉발된 두가지 중요한 갈래가 있었다는 것입니다.
The early one (just by accident) was the bio/net non-data-procedure route that I took.
하나는(단지 우연에 의해) 제가 했던 생물학/네트워크 비데이터 프로시저 갈래였습니다.
The other one, which came a little later as an object of study was abstract data types, and this got much more play.
또다른 갈래는, 객체에대한 연구로서 좀 나중에 떠올랐던 것은 추상데이터 타입이었으며, 이것이 좀더 재밌었습니다.
If we look at the whole history, we see that the proto-OOP stuff started with ADT, had a little fork towards what I called "objects" -- that led to Smalltalk, etc.,-- but after the little fork, the CS establishment pretty much did ADT and wanted to stick with the data-procedure paradigm.
만약 우리가 전체 역사를 돌이켜본다면, 초기OOP 구현이 ADT와 함께 시작되었음을 알수있습니다. ADT는 제가 말하는 객체들을 향한 작은 모임(Smalltalk등으로 이어지는) 을 가지고 있었습니다. 하지만 그 모임 이후에, CS 기구가 좀더 ADT를 했었고, 데이터-프로시져 패러다임에 가까워지길 원했습니다.
Historically, it's worth looking at the USAF Burroughs 220 file system (that I described in the Smalltalk history), the early work of Doug Ross at MIT (AED and earlier) in which he advocated embedding procedure pointers in data structures, Sketchpad (which had full polymorphism -- where e.g. the same offset in its data structure meant "display" and there would be a pointer to the appropriate routine for the type of object that structure represented, etc., and the Burroughs B5000, whose program reference tables were true "big objects" and contained pointers to both "data" and "procedures" but could often do the right thing if it was trying to go after data and found a procedure pointer.
역사적으로, 몇가지 시스템을 보는게 좋습니다.
1. (스몰토크역사에서 제가 설명했던) USAF 버로스 220 파일시스템
2. MIT 더그로스의 초기 작업들, 그는 데이터 구조안에 프로시저 포인터를 내장하는것을 지지했습니다.
3. Sketchpad(완전히 다형적, 데이터 구조안의 같은 파생물은 display를 의미하고 구조가 표현하는 객채의 타입에대한 적절한 루틴을 포인터가 있을수 있음
4. B5000, 프로그램 참조 테이블들이 진짜 대형 객체들이었고 데이터와 프로시저모두를 포함하고 있었고 데이터 이후에 진행되거나 프로시저 포인터가 발견되면 정상적으로 동작하곤 했습니다.
And the very first problems I solved with my early Utah stuff was the "disappearing of data" using only methods and objects.
그리고, 제가 유타 작업물에서 풀었던 초창기 문제들은 메서드와 객체만을 사용해서 "데이터를 제거" 하는 것이었습니다.
At the end of the 60s (I think) Bob Balzer wrote a pretty nifty paper called "Dataless Programming", and shortly thereafter John Reynolds wrote an equally nifty paper "Gedanken" (in 1970 I think) in which he showed that using the lamda expressions the right way would allow data to be abstracted by procedures.
제생각에 60년대 말 밥발저님이 "비데이터 프로그래밍"이라는 매우 훌륭한 눈문을 작성했고, 조금 뒤에 존 레이놀드분들이 동일하게 1970년대에 "Gednaken"이라는 좋은 논문을 작성했고 거기서 람다표현을 적절한 방법으로 사용하는것이 데이터가 프로시저에의해 추출될수 있음을 보여주었습니다.
The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others -- pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer.
객체들을 비데이터로서 좋아하는 사람들은 저, 칼 휴잇, 데이브 리드와 몇몇 를 포함해 소규모였고, 이 그룹의 꽤많은 사람들이 ARPA 커뮤니티에서 왔으며, 연산의 기본 단위가 전체 컴퓨터라는 ARPAnet->Internet디자인 작업에 참여하였습니다.
But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages.
하지만, 어떻게 고집스럽게 하나의 아이디어가 바뀌지 않는지 보여주자면, 7~80대 내내, 객체와 메시지에 대해 생각하는 대신, "원격 프로시저 전송"을 시도하는 사람들이 많았습니다.
Sic transit gloria mundi.
이 세상의 영화는 이처럼 사라져 간다.
Cheers,
화이팅,
Alan
앨런
At 10:05 PM +0200 7/26/03, Stefan Ram wrote:
출처 :
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
