Alan Kay OOPSLA 1997 “The Computer Revolution Hasn’t Happened Yet”

https://youtu.be/g8meZ46pIDU?si=z7GueM-D0x12K8nV



Alan Kay OOPSLA 1997 “The Computer Revolution Hasn’t Happened Yet” 대본 (영한 한줄식, 생략 없이 최대한 완전)
[Alan C. Kay] Thank you. Well, I presume most of you have been up all night. I can’t imagine ever seeing this many programmers at eight o’clock in the morning.
[Alan C. Kay] 감사합니다. 음, 여러분 대부분 밤새워 있었을 거라고 생각합니다. 아침 8시에 이렇게 많은 프로그래머를 보는 건 상상도 못 했어요.
I guess this is the largest bathroom I’ve ever given a talk in.
이게 내가 지금까지 강연한 곳 중 가장 큰 화장실인 것 같네요.
That was just a test to see if you could understand me. I can’t actually understand myself up here.
그건 그냥 내가 말하는 걸 이해할 수 있는지 테스트였어요. 여기 위에서 나 자신도 제대로 이해 못 하겠네요.
I actually haven’t been to OOPSLA since the first one and, when I got invited to give this talk, while I was thinking—well, should I go, or should I not, or what should I do, it occured to me that this conference, on this day, is pretty much in the epicenter of the twenty-fifth anniversary of Smalltalk.
사실 첫 OOPSLA 이후로 여기 온 적이 없었고, 이 강연 초대를 받았을 때 가야 하나 말아야 하나 고민하다가, 이 컨퍼런스가 오늘 이 날짜에 Smalltalk 25주년 기념의 중심에 있다는 생각이 들었어요.
The one page interpreter scheme that I wrote out was done just a few weeks ago twenty-five years ago.
내가 쓴 한 페이지 인터프리터 스킴이 정확히 25년 전 몇 주 전에 완성됐죠.
The first working version of it was done in a few weeks from now, twenty-five years ago, so this is about in the center and—let me see if I can get our motto up on—could I have that first slide, please?
첫 작동 버전은 지금으로부터 25년 전 몇 주 후에 완성됐으니, 거의 중심쯤 되네요. 우리 모토를 띄워볼까요—첫 슬라이드 부탁합니다.
I’m not gonna give a historical talk, as I finally discharged those obligations in the History of Programming Languages Conference a couple of years ago, but I thought it might be interesting for some of you, who might not have been computing for the last twenty-five or thirty years, to take a two-minute trip.
역사 강연은 하지 않을 거예요. 몇 년 전 History of Programming Languages Conference에서 그 의무를 다 했으니까요. 하지만 지난 25~30년 동안 컴퓨팅을 하지 않은 분들에게 2분 정도 여행을 해보는 게 흥미로울 것 같아서요.
I believe that this set of images basically goes back to 1973 and 1974 at Xerox PARC—[they] show some of the first children that we worked with.
이 이미지 세트는 기본적으로 1973~1974년 Xerox PARC로 거슬러 올라가요. 우리가 처음 함께 일한 아이들 몇 명을 보여줍니다.
The music that you’ll hear on this clip was composed by one of the members of our group, Chris Jeffers. It’s called “The Happy Hacker”, in case you want a theme song.
이 클립에서 들을 음악은 우리 그룹 멤버 중 한 명인 Chris Jeffers가 작곡한 거예요. 테마송으로 원하시면 “The Happy Hacker”예요.
It’s played in real time FM synthesis that we developed for the Alto computer. This is the forerunner of the workstations and the Macintosh without any additional sound synthesis hardware at all, because why should you have that if your computer is designed well.
Alto 컴퓨터를 위해 우리가 개발한 실시간 FM 합성으로 연주된 거예요. 이는 워크스테이션과 매킨토시의 선구자예요. 추가 사운드 합성 하드웨어 없이요. 컴퓨터가 잘 설계됐다면 왜 그게 필요하겠어요.
I think you’ll get a little picture of it, but before I turn on that clip, let’s just for the heck of it see how many people are in this room today, who participated in the Xerox PARC Smalltalk experience, between roughly 1971 and 1983. Could you stand up?
조금 그림이 보일 거예요. 하지만 클립을 틀기 전에, 오늘 이 방에 1971~1983년경 Xerox PARC Smalltalk 경험에 참여한 사람이 몇 명이나 되는지 한번 보죠. 일어나 보실래요?
Let’s see if we—how many people are actually here. Anybody without gray hair?
보자, 실제로 여기 몇 명이나 있나. 회색 머리 없는 사람 있나요?
Thank you. Okay, let’s roll that, that clip.
감사합니다. 좋아요, 그 클립 틀어주세요.
Well, that was things as they existed about twenty-five years ago.
그게 약 25년 전 존재했던 것들이었어요.
The other thing I wanted to do in the beginning part of this talk—I tried to figure out how to work my way into it, and I finally remembered a paper that Dijkstra—I don’t know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano Dijkstras.
이 강연의 시작 부분에서 하고 싶었던 다른 것—어떻게 시작할지 고민하다가 Dijkstra의 논문을 떠올렸어요. Dijkstra를 만난 분이 몇 명이나 될지 모르겠지만, 컴퓨터 과학에서 오만함은 nano Dijkstras로 측정된다는 걸 아실 거예요.
He once wrote a paper—of the kind that he liked to write a lot of—which had the title On the fact that the Atlantic has two sides.
그가 좋아하던 스타일의 논문을 하나 썼는데, 제목이 “대서양에 두 개의 면이 있다는 사실에 관하여”였어요.
It was basically all about how different the approaches to computing science were in Europe, especially in Holland and in the United States.
기본적으로 유럽, 특히 네덜란드와 미국의 컴퓨팅 과학 접근 방식이 얼마나 다른지에 관한 거였죠.
In the US, here, we were not mathematical enough, and gee, in Holland, if you’re a full professor, you’re actually appointed by the Queen, and there are many other uh important distinctions made between the two cultures.
미국에서는 우리가 수학적이지 않다는 거였고, 네덜란드에서는 정교수가 되면 여왕이 임명하고, 두 문화 사이에 다른 중요한 차이들이 많았어요.
So, uhm, I wrote a rebuttal paper, just called On the fact that most of the software in the world is written on one side of the Atlantic.
그래서 나는 반박 논문을 썼어요. “세계 대부분의 소프트웨어가 대서양 한쪽에서 작성된다는 사실에 관하여”라는 제목으로요.
It was basically about that, computers form a new kind of math. You can’t judge them. They don’t really fit well in classical math, and people who tried to do that are basically indulging in a form of masturbation.—Maybe even realizing it.
기본적으로 컴퓨터는 새로운 종류의 수학을 형성한다는 거였어요. 판단할 수 없죠. 고전 수학과 잘 맞지 않고, 그렇게 하려는 사람들은 기본적으로 자위 행위에 빠져 있는 거예요. 어쩌면 스스로도 알고 있을지도요.
It was kind of a practical math, that was. The balance was between making structures that were supposed to be consistent of a much larger kind than classical math had ever come close to dreaming of attempting, and having to deal with the exact same problems that classical math of any size has to deal with, which is being able to be convincing about having covered all of the cases.
일종의 실용적 수학이었어요. 균형은 고전 수학이 꿈도 꾸지 못한 훨씬 큰 일관성 있는 구조를 만드는 것과, 어떤 크기의 고전 수학도 다루어야 하는 똑같은 문제—모든 경우를 다 다뤘다는 설득력을 가지는 것 사이였죠.
There’s a mathematician by the name of Euler, whose speculations about what might be true formed twenty large books, and most of them were true. Most of them were right. Almost all of his proofs were wrong, and many PhDs in mathematics in the last and this century have been formed by mathematicians going to Euler’s books, finding one of his proofs, showing it was a bad proof, and then guessing that his insight was probably correct, and finding a much more convincing proof. So debugging actually goes on in mathematics as well.
Euler라는 수학자가 있는데, 무엇이 참일 수 있는지에 대한 그의 추측이 20권의 큰 책을 만들었고, 대부분 참이었어요. 거의 모두 맞았죠. 그의 증명 거의 모두가 틀렸고, 지난 세기와 이번 세기의 많은 수학 박사들이 Euler의 책에서 그의 증명 하나를 찾아 그것이 나쁜 증명이라고 보여주고, 그의 통찰이 아마 맞을 거라고 추측한 뒤 더 설득력 있는 증명을 찾아내는 것으로 만들어졌어요. 그래서 디버깅은 수학에서도 일어나요.
I think the main thing about doing OOP work, or any kind of programming work, is that there has to be some exquisite blend between beauty and practicality. There’s no reason to sacrifice either one of those, and people who are willing to sacrifice either one of those, I don’t think really get what computing is all about.
OOP 작업이나 어떤 종류의 프로그래밍 작업에서 주요한 것은 아름다움과 실용성 사이의 절묘한 조화가 있어야 한다는 거예요. 어느 하나를 희생할 이유가 없고, 어느 하나라도 희생하려는 사람들은 컴퓨팅이 무엇인지 제대로 이해하지 못했다고 생각해요.
It’s like saying I have really great ideas for paintings, but I’m just gonna use a brush but no paint. So my ideas will be represented by the gestures I make over the paper—and don’t tell any 20th century artist that, or they might decide to make a videotape of them doing that and put it in a museum.
훌륭한 그림 아이디어가 있는데 붓만 쓰고 물감은 안 쓴다는 거와 같아요. 그래서 내 아이디어는 종이 위에서 하는 제스처로 표현될 거예요. 20세기 예술가에게 그 말 하지 마세요. 그들은 그걸 비디오로 찍어 박물관에 넣을지도 몰라요.
I had this problem figuring out what to talk about. It’s always difficult because technical people always seem to know so much, but it’s interesting, again, to look at what is actually being done in the world under the name of OOP.
무엇에 대해 말할지 고민하는 문제가 있었어요. 기술자들은 항상 너무 많이 아는 것 같아서 항상 어렵지만, OOP라는 이름으로 세상에서 실제로 무엇이 행해지고 있는지 보는 건 다시 흥미로워요.
I’ve been shown some very, very strange-looking pieces of code over the years by various people, including people in universities, that they have said is OOP code, and written in an OOP language—and actually, I made up the term object-oriented, and I can tell you I did not have C++ in mind.
수년 동안 대학 사람들을 포함한 다양한 사람들로부터 OOP 코드라고 하는 아주 아주 이상하게 생긴 코드 조각들을 보여줬어요. 그리고 실제로 object-oriented라는 용어를 내가 만들었는데, C++을 염두에 두지 않았다는 걸 말할 수 있어요.
An important thing here is—I have many of the same feelings about Smalltalk—and I’m not going to try and do Smalltalk in here, because I think there is one really important thing about Smalltalk, and some of the languages like it that we should pay really, really close attention to—but it has almost nothing to do with either the syntax or the accumulated superclass library.
여기서 중요한 건—Smalltalk에 대해서도 비슷한 감정을 많이 가지고 있다는 거예요. 여기서 Smalltalk를 하려는 건 아니에요. Smalltalk와 비슷한 언어들에 대해 정말 정말 주의 깊게 봐야 할 정말 중요한 한 가지가 있다고 생각하지만, 그것은 문법이나 축적된 superclass 라이브러리와 거의 관계없어요.
Both of these are taken as being the language, as though it was issued from some gods on Olympus. So I want to talk a little bit more about my personal reaction to OOP when I started thinking about it in the sixties, and instead of making it a historical talk, to try and think about whether these reactions and insights have any place today.
이 둘 다 언어로 받아들여지는데, 마치 올림푸스 신들로부터 내려온 것처럼요. 그래서 60년대에 OOP에 대해 생각하기 시작했을 때의 내 개인적 반응에 대해 조금 더 이야기하고, 역사 강연 대신 이러한 반응과 통찰이 오늘날 어떤 자리를 차지하는지 생각해 보려 해요.
In the sixties things were quite mechanical. There’s a sense of simple mechanism because computers were as large as this room.
60년대에는 사물이 상당히 기계적이었어요. 컴퓨터가 이 방만큼 컸기 때문에 단순한 메커니즘이라는 느낌이 있었죠.
The one that Ivan Sutherland did Sketchpad on was the size of this room. It was one of the last computers in the US large enough to have its own roof. It was the building it was in.
Ivan Sutherland가 Sketchpad를 만든 컴퓨터는 이 방 크기였어요. 미국에서 자체 지붕을 가질 만큼 큰 마지막 컴퓨터 중 하나였죠. 그 건물 자체가 컴퓨터였어요.
But the programs were quite small and they had a lot in common with their mathematical antecedents. One way of thinking about the semantics of math that was based on logic, is as interlocking gears.
하지만 프로그램은 상당히 작았고 수학적 선조와 많은 공통점이 있었어요. 논리에 기반한 수학 의미론을 생각하는 한 가지 방법은 맞물린 기어로 보는 거예요.
Everything kind of has to fit together, and if it does, and everything is compatible at the end, you get the final turning of the shaft that you want.
모든 것이 맞물려야 하고, 결국 모든 것이 호환되면 원하는 샤프트의 최종 회전을 얻어요.
An analogy to these programs of the sixties is a dog house. If you take any random boards, nail, and hammer; pound them together and you’ve got a structure that will stay up.
60년대 이러한 프로그램에 대한 비유는 개집이에요. 아무 판자, 못, 망치를 가져와서 함께 두드리면 버틸 구조가 생겨요.
You don’t have to know anything, except how to pound a nail to do that. Now, somebody could come along and look at this dog house and say, Wow! If we could just expand that by a factor of a hundred we could make ourselves a cathedral.
못을 두드리는 방법만 알면 아무것도 알 필요 없어요. 누군가 이 개집을 보고 와서 “와! 이걸 100배 확대하면 대성당을 만들 수 있겠네”라고 할 수 있죠.
It’s about three feet high. That would give us something thirty stories high, and that would be really impressive. We could get a lot of people in there.
약 3피트 높이예요. 그럼 30층 높이의 뭔가를 만들 수 있고 정말 인상적일 거예요. 많은 사람을 넣을 수 있죠.
The carpenters would set to work blowing this thing up by a factor of a hundred. Now, we all know, being engineers and scientists, that when you blow something up by a factor of a hundred, its mass goes up by a factor of a million, and its strength, which is mostly due to cross sections of things, only goes up by a factor of ten thousand.
목수들은 이걸 100배 확대하는 작업에 착수할 거예요. 우리 엔지니어와 과학자들은 100배 확대하면 질량은 백만 배 증가하고, 강도는 대부분 단면적 때문에 만 배만 증가한다는 걸 알아요.
When you blow something up by a factor of a hundred, it gets by a factor of hundred weaker in its ability, and in fact, what will happen to this dog house; it would just collapse into a pile of rubble.
100배 확대하면 능력이 100배 약해져요. 실제로 이 개집은 그냥 무너져 잔해 더미가 될 거예요.
Then there are two choices you can have when that happens. The most popular one is to say, Well, that was what we were trying to do all along. Put more garbage on it, plaster it over with limestone, and say, Yes, we were really trying to do pyramids, not gothic cathedrals.
그럴 때 두 가지 선택지가 있어요. 가장 인기 있는 건 “음, 그게 우리가 처음부터 하려던 거였어”라고 말하는 거예요. 더 많은 쓰레기를 올리고 석회로 회반죽을 바르고 “그래, 우리는 정말 피라미드를 하려던 거지 고딕 대성당이 아니야”라고 하죠.
That, in fact accounts for much of the structure of modern operating systems today.
그게 사실 오늘날 현대 운영 체제 구조의 많은 부분을 설명해줘요.
Or, you can come up with a new concept, which the people who started getting interested in complex structures many years ago did. They called it architecture.
또는 새로운 개념을 생각해낼 수 있어요. 복잡한 구조에 관심을 가진 사람들이 오래전에 한 거죠. 그들은 그것을 건축이라고 불렀어요.
Literally, the designing and building of successful arches. A non-obvious, a non-linear interaction between simple materials to give you non-obvious sinergies, and a fast multiplication of materials.
말 그대로 성공적인 아치의 설계와 건축이에요. 단순한 재료 사이의 명백하지 않은 비선형 상호작용으로 명백하지 않은 시너지를 주고 재료의 빠른 증식을 가져오죠.
It’s quite remarkable to people when I tell them that the amount of material in Chartres Cathedral, which is an enormous, physical structure, is less than the amount of material that was put into the Parthenon.
Chartres 대성당처럼 거대한 물리적 구조의 재료 양이 파르테논 신전에 들어간 재료 양보다 적다는 걸 말하면 사람들이 상당히 놀라워해요.
The reason is that it’s almost all air, and almost all glass. Everything is cunningly organized in a beautiful structure to make the whole have much more integrity than any of its parts.
이유는 거의 모두 공기이고 거의 모두 유리이기 때문이에요. 모든 것이 아름다운 구조로 교묘하게 조직되어 전체가 부분 하나하나보다 훨씬 더 큰 완전성을 가지게 해요.
That’s the other way you can go, and part of the message of OOP was, that, as complexity starts becoming more and more important, architecture’s always going to dominate material, and in fact, the sad fact, I think, about OOP, is that people didn’t get interested in architecture because of the beauty of it.
그게 다른 길이고 OOP 메시지의 일부는 복잡성이 점점 중요해지면서 건축이 항상 재료를 지배할 거라는 거예요. 사실 OOP에 대한 슬픈 사실은 사람들이 아름다움 때문에 건축에 관심을 가진 게 아니라는 거예요.
They’re only starting to get interested in architecture now, when the Internet is forcing everybody to do it. That’s pretty pathetic.
지금 인터넷이 모두를 강제하면서야 건축에 관심을 갖기 시작했어요. 꽤 한심하죠.
I’m going to use a metaphor for this talk which is drawn from a wonderful book called The Act of Creation by Arthur Koestler.
이 강연에서 사용할 메타포는 Arthur Koestler의 훌륭한 책 The Act of Creation에서 가져온 거예요.
Koestler was a novelist who became a cognitive scientist in his later years. One of the great books he wrote was about what might creativity be.—Learning.
Koestler은 소설가였는데 후년에 인지과학자가 됐어요. 그가 쓴 위대한 책 중 하나는 창의성이 무엇일 수 있는지에 관한 거였어요.—학습.
He realized that learning, of course, is an act of creation itself, because something happens in you that wasn’t there before.
그는 학습이 당연히 창조 행위 자체임을 깨달았어요. 전에 없던 무언가가 당신 안에 일어나기 때문이죠.
He used a metaphor of thoughts as ants crawling on a plane. In this case it’s a pink plane, and there’s a lot of things you can do on a pink plane.
그는 생각을 평면 위를 기어다니는 개미로 비유했어요. 여기서는 분홍 평면이고, 분홍 평면에서 할 수 있는 많은 일이 있어요.
You can have goals. You can choose directions. You can move along. But you’re basically in the pink context.
목표를 가질 수 있어요. 방향을 선택할 수 있어요. 움직일 수 있어요. 하지만 기본적으로 분홍 맥락 안에 있어요.
It means that progress, in a fixed context, is almost always a form of optimization, because if you’re actually coming up with something new, it wouldn’t have been part of the rules or the context for what the pink plane is all about.
고정된 맥락에서의 진보는 거의 항상 최적화 형태라는 뜻이에요. 실제로 새로운 것을 만들어낸다면 그것은 분홍 평면의 규칙이나 맥락의 일부가 아니기 때문이죠.
Creative acts, generally, are ones that don’t stay in the same context that they’re in.
창조적 행위는 일반적으로 자신이 있는 같은 맥락에 머무르지 않는 거예요.
He says, every once in a while, even though you have been taught carefully by parents and by school for many years, you have a blue idea.
그는 말해요, 가끔씩 부모와 학교에서 수년 동안 조심스럽게 가르침을 받았음에도 불구하고 파란 아이디어가 생긴다고요.
Maybe when you’re taking a shower. Maybe when you’re out jogging. Maybe when you’re resting in an unguarded moment, suddenly, that thing that you were puzzling about, wondering about, looking at, appears to you in a completely different light, as though it were something else.
아마 샤워할 때일 수도, 조깅할 때일 수도, 방심한 순간 쉬고 있을 때일 수도 있어요. 갑자기 고민하던, 궁금해하던, 바라보던 그 것이 완전히 다른 빛으로, 마치 다른 것처럼 나타나요.
Koestler said that the emotional reaction to this comes basically in three forms. If you’re telling a joke, it’s HA HA! If you’re doing science, it’s A HA!, and if you’re doing art it’s AHHH!
Koestler은 이에 대한 감정적 반응이 기본적으로 세 가지 형태로 온다고 했어요. 농담을 할 때는 HA HA! 과학을 할 때는 A HA! 예술을 할 때는 AHHH!
He says, because in each case, something very similar is happening. A joke takes you down the garden path, and suddenly reveals it’s about something else, and you get a very aggressive explosion.
각 경우에 매우 비슷한 일이 일어나기 때문이라고 해요. 농담은 당신을 정원 길로 데려갔다가 갑자기 다른 것에 관한 것임을 드러내고 매우 공격적인 폭발을 일으켜요.
Science has much of the same feeling to it, and often, when you see something in science, you start laughing because it was right there in front you, and it is a kind of a joke.
과학도 비슷한 느낌을 주고, 과학에서 무언가를 볼 때 종종 웃게 돼요. 바로 눈앞에 있었기 때문이고 일종의 농담이기 때문이죠.
Art is there to remind us—Great art is there to remind us that whatever context we think we’re in, there are other contexts.
예술은 우리에게 상기시키기 위해 있어요—위대한 예술은 우리가 어떤 맥락에 있다고 생각하든 다른 맥락이 있다는 걸 상기시켜줘요.
Art is always there to take us out of the context that we are in and make us aware of other contexts. This is a very simple—you can even call it a simple minded metaphor—but it will certainly serve for this talk today.
예술은 항상 우리가 있는 맥락에서 우리를 데려와 다른 맥락을 인식하게 해줘요. 이건 매우 단순한—단순하다고 부를 수도 있는—메타포지만 오늘 이 강연에는 확실히 도움이 될 거예요.
He also pointed out that you have to have something blue to have blue thoughts with. I think this is generally missed in people who specialize to the extent of anything else.
그는 또한 파란 생각을 하려면 파란 것이 있어야 한다고 지적했어요. 전문화가 극에 달한 사람들에게는 일반적으로 놓치는 부분이라고 생각해요.
When you specialize, you are basically putting yourself into a mental state where optimization is pretty much all you can do. You have to learn lots of different kinds of things in order to have the start of these other contexts.
전문화하면 기본적으로 최적화만 할 수 있는 정신 상태에 자신을 놓는 거예요. 다른 맥락의 시작을 가지려면 많은 다른 종류의 것을 배워야 해요.
So here’s a couple of knocks on the head I had over the years. I just want to tell them to you quickly.
그래서 수년 동안 내가 받은 몇 가지 깨달음이 있어요. 빨리 여러분께 말씀드릴게요.
This one I think you’ll find interesting because it is the earliest known form of what we call data abstraction. I was in the Air Force in 1961, and I saw it in 1961, and it probably goes back one year before.
이건 우리가 데이터 추상화라고 부르는 가장 초기 형태로 흥미로울 거예요. 1961년에 공군에 있었고 1961년에 봤는데 아마 1년 전으로 거슬러 올라갈 거예요.
Back then, they really didn’t have operating systems. Air training command had to send tapes of many kinds of records around from Air Force base to Air Force base.
그때는 정말 운영 체제가 없었어요. 공군 훈련 사령부는 공군 기지에서 기지로 다양한 종류의 레코드 테이프를 보내야 했어요.
There was a question on how can you deal with all of these things that used to be card images, because tape had come in, [there] were starting to be more and more complicated formats, and somebody—almost certainly an enlisted man, because officers didn’t program back then—came up with the following idea.
카드 이미지였던 것들을 어떻게 다룰지 문제였어요. 테이프가 도입되면서 점점 더 복잡한 포맷이 생기기 시작했죠. 누군가—거의 확실히 사병이었을 거예요. 그때 장교들은 프로그래밍 안 했으니까—다음 아이디어를 생각해냈어요.
This person said, on the third part of the record on this tape we’ll put all of the records of this particular type. On the second part—the middle part—we’ll put all of the procedures that know how to deal with the formats on this third part of the tape.
이 사람은 테이프 레코드의 세 번째 부분에 이 특정 유형의 모든 레코드를 넣자고 했어요. 두 번째 부분—중간 부분—에는 테이프 세 번째 부분의 포맷을 다루는 방법을 아는 모든 프로시저를 넣자고요.
In the first part we’ll put pointers into the procedures, and in fact, let’s make the first ten or so pointers standard, like reading and writing fields, and trying to print; let’s have a standard vocabulary for the first ten of these, and then we can have idiosyncratic ones later on.
첫 번째 부분에는 프로시저를 가리키는 포인터를 넣고, 사실 처음 10개 정도 포인터는 읽기, 쓰기 필드, 프린트 같은 표준으로 만들자. 처음 10개에 대해 표준 어휘를 만들고 나중에 특이한 것들을 가질 수 있게요.
All you had to do to read a tape back in 1961, was to read the front part of a record—one of these big records—into core storage, and start jumping indirect through the pointers, and the procedures were there.
1961년에 테이프를 읽으려면 레코드의 앞부분—이 큰 레코드 중 하나—을 코어 저장소로 읽고 포인터를 통해 간접적으로 점프하기 시작하면 프로시저가 거기 있었어요.
I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats.
그걸 인터넷에서 HTML로 해야 하는 것과 대비해보길 정말 바래요. 생각해보세요. 인터넷의 HTML은 브라우저가 그 포맷을 이해해야 한다는 전제를 해서 암흑기로 돌아갔어요.
This has to be one of the worst ideas since MS-DOS. This is really a shame. It’s maybe what happens when physicists decide to play with computers, I’m not sure.
MS-DOS 이후 최악의 아이디어 중 하나일 거예요. 정말 부끄러운 일이에요. 물리학자들이 컴퓨터를 가지고 놀기로 결정할 때 일어나는 일인지도 몰라요.
In fact, we can see what’s happened to the Internet now, is that it is gradually getting—There are two wars going on. There’s a set of browser wars which are 100 percent irrelevant.
사실 지금 인터넷에 일어난 걸 보면 점점—두 가지 전쟁이 진행 중이에요. 100% 무관한 브라우저 전쟁 세트가 있어요.
They’re basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here.
기본적으로 복잡한 시스템을 구축하는 방법을 이해하지 못함을 보여주려는 시도거나, 더 조잡하게 영토를 모으려는 시도예요. Microsoft는 여기서 후자 진영이라고 생각해요.
You don’t need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don’t need anything more complex than something like X Windows.
1961년에 공군 하사관이 알았던 대로 하면 브라우저가 필요 없어요. 그냥 읽어들이면 돼요. 필요한 모든 것을 함께 이동하게 하고 X Windows 같은 것보다 더 복잡한 건 필요 없어요.
Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable.
더 나으면 좋겠지만 기본적으로 거기 있는 모든 것의 모든 지식을 배포할 수 있게 하고 싶어요. 사실 사람들이 점점 더 복잡한 HTML 포맷을 발견하면서 인터넷은 그 방향으로 움직이기 시작하고 있어요. 더 다루기 힘들어지면서요.
This is one of these mistakes that has been recapitulated every generation. It’s just simply not the way to do it.
이건 매 세대마다 반복되는 실수 중 하나예요. 그냥 그렇게 하는 방식이 아니에요.
So here’s a great idea—and by the way, this kind of programming was done before there were higher level languages in the Air Force. This approach to things was forced out of the Air Force when they standardized on COBOL.
그래서 여기 위대한 아이디어가 있어요—참고로 이런 종류의 프로그래밍은 공군에서 고급 언어가 있기 전에 했어요. COBOL을 표준화하면서 이 접근 방식은 공군에서 밀려났어요.
Ivan Sutherland’s Sketchpad. I’ve usually shown a movie of what it was like. I won’t today. Immensely sophisticated. Almost staggering in its conception on what it was able to do. Very much an object-oriented system.
Ivan Sutherland의 Sketchpad예요. 보통 어떤 모습이었는지 영화로 보여줬지만 오늘은 안 할게요. 엄청나게 정교했어요. 무엇을 할 수 있었는지에 대한 개념이 거의 놀라울 정도였죠. 매우 객체 지향 시스템이었어요.
It had an actual notion of classes and sub-classes. It had a notion of polymorphism, even stronger than the air training command version. Next slide, please.
실제 클래스와 서브클래스 개념이 있었어요. 다형성 개념도 있었고 공군 훈련 버전보다 더 강력했어요. 다음 슬라이드 부탁합니다.
I had seen the idea three or four times, but it wasn’t till I had to figure out Simula—we thought it was supposed to be an ALGOL. It turned out this pile of tapes was the first Simula, and ALGOL that had been doctored by Case Western Reserve, and the inventors of Simula, Nygaard and Dahl in Norway, and distributed along with some incomprehensible documentation in 1966.
이 아이디어를 3~4번 봤지만 Simula를 이해해야 할 때까지는 아니었어요—ALGOL이라고 생각했죠. 그 테이프 더미가 첫 Simula였고 Case Western Reserve에서 수정한 ALGOL이었고, Simula 발명가 Nygaard와 Dahl in Norway가 1966년에 이해하기 힘든 문서와 함께 배포한 거였어요.
It was through trying to understand what Simula was that, finally—I’m not sure exactly why, it’s just—I think it’s maybe if you see a good idea that’s odd, four times, in four different costumes, it finally starts to make an impression, and here’s the choice you have when you’re faced with something new.
Simula가 무엇인지 이해하려고 노력하다가 마침내—정확히 왜인지는 모르겠지만—좋은 아이디어를 네 번, 네 가지 다른 옷차림으로 보면 마침내 인상을 주기 시작하는 것 같아요. 새로운 것에 직면했을 때의 선택지가 여기 있어요.
You can take this technological advance and you could decide this is a better way of doing the stuff I’m doing now, and I can use this to continue on the path that I’m going. That’s staying in the pink plane.
이 기술적 진보를 받아 지금 하는 일을 더 잘하는 방법이라고 결정하고 지금 가는 길을 계속할 수 있어요. 그건 분홍 평면에 머무르는 거예요.
Or, you can say this is not a better old thing, this is almost a new thing, and I wonder what that new thing is trying to be. If you do that, there’s a chance of actually, perhaps gaining some incredible leverage over simply optimizing something that can’t be optimized very much.
또는 이건 더 나은 옛것이 아니라 거의 새로운 것이라고 말하고 그 새로운 것이 무엇이 되려 하는지 궁금해할 수 있어요. 그렇게 하면 최적화할 수 없는 것을 단순히 최적화하는 것보다 놀라운 지렛대를 얻을 기회가 생겨요.
Simula came out of the world of data structures and procedures, and had much of that flavour, if you wanted to look at it that way. But it had a way of making relationships of the states of your computation with procedures, that was extremely helpful, and much better, and more general than what were called own variables in ALGOL 60.
Simula는 데이터 구조와 프로시저 세계에서 나왔고 그렇게 보면 그 맛이 많이 났어요. 하지만 계산 상태와 프로시저의 관계를 만드는 방식이 있었는데 ALGOL 60의 own variables보다 훨씬 도움이 되고 더 좋고 더 일반적이었어요.
That was one way to think of it. Then there’s this other question; if it was almost a new thing, what kind of a new thing was it? Well, one of my undergraduate majors was in molecular biology, and my particular interest was both in cell physiology and in embryology. Morphogenesis they call it today.
그게 한 가지 생각하는 방식이었어요. 또 다른 질문이 있어요. 거의 새로운 것이라면 어떤 종류의 새로운 것이었을까? 음, 내 학부 전공 중 하나는 분자생물학이었고 특히 세포 생리학과 발생학에 관심이 있었어요. 오늘날 형태형성이라고 부르는 거예요.
This book, Molecular Biology of the Gene, had just come out in 1965. Wonderful book. Still in print. It has gone through many, many editions. The only words that are common between this book and the one today are the articles, like “the” and “an”.
1965년에 나온 Molecular Biology of the Gene라는 책이에요. 훌륭한 책이죠. 아직 출판 중이고 많은 판을 거쳤어요. 이 책과 오늘날 책 사이에 공통된 단어는 “the”와 “an” 같은 관사뿐이에요.
Actually, the word gene, I think, is still in there, but it means something completely different now. But one of the things that Watson did in this book was to make an assay. The first assay of an entire living creature. That was the E. coli bacterium. Next slide, please.
사실 gene이라는 단어는 아직 있지만 지금은 완전히 다른 의미예요. 하지만 Watson이 이 책에서 한 것 중 하나는 assay(분석/시험)를 한 거예요. 전체 살아있는 생물의 첫 assay였죠. E. coli 박테리아였어요. 다음 슬라이드 부탁합니다.
Here’s the other big source. Certainly the greatest, single language along with Simula of the sixties, I think. One with as many profound or more profound insights—LISP.
여기 또 다른 큰 출처가 있어요. 60년대 Simula와 함께 가장 위대한 단일 언어라고 생각해요. Simula만큼이나 또는 더 심오한 통찰을 가진—LISP예요.
On page thirteen of this book that was published in 1962, there’s a half page of code which is the reflective model of LISP written in itself. All the important details of LISP semantics and the guidelines for how to make a LISP interpreter are in that half page.
1962년에 출판된 이 책 13페이지에 LISP 자신으로 작성된 반사 모델인 반 페이지 코드가 있어요. LISP 의미론의 모든 중요한 세부사항과 LISP 인터프리터를 만드는 지침이 그 반 페이지에 들어있어요.
It is this aspect—this meta-reflective aspect—that to me, is the saddest thing about what is happening with Java.
이 측면—이 메타-반사적 측면—이 Java에서 일어나는 일에 대해 나에게 가장 슬픈 일이에요.
When Java first happened I thought, Well, it’s legitimizing something that most people have not believed in for a long time, which is this byte-code approach of being multi-platform like we had at Xerox PARC.
Java가 처음 나왔을 때 나는 대부분의 사람들이 오랫동안 믿지 않았던 것을 정당화한다고 생각했어요. Xerox PARC에서 했던 것처럼 멀티플랫폼인 바이트코드 접근 방식이죠.
It’s not a new idea. It actually goes back into the sixties. But when I looked at Java, I thought, My goodness, how could they possibly—and of course, we know that the history was more about programming toasters, originally, than being on the Internet—but, my goodness, how do they hope to survive all of the changes, modifications, adaptations, and interoperability requirements without a meta-system.
새로운 아이디어가 아니에요. 실제로 60년대로 거슬러 올라가요. 하지만 Java를 봤을 때, 맙소사 어떻게 그럴 수 있나—물론 원래 역사는 인터넷보다는 토스터 프로그래밍에 관한 것이었지만—메타 시스템 없이 모든 변화, 수정, 적응, 상호운용성 요구를 어떻게 살아남길 바라는지.
Without even, for instance, being able to load new things in while you’re running. The fact that people adopted this as some great hope is probably the most distressing thing to me, personally, as I said, since MS-DOS.
예를 들어 실행 중에 새로운 것을 로드할 수도 없이요. 사람들이 이것을 위대한 희망으로 채택했다는 사실이 MS-DOS 이후 나에게 개인적으로 가장 괴로운 일이에요.
I mean, it represents a real failure of people to understand what the larger picture is, and is going to be. Next slide.
즉, 더 큰 그림이 무엇인지, 앞으로 무엇이 될지 이해하지 못한 사람들의 진짜 실패를 나타내요. 다음 슬라이드.
This notion of meta-programming. Lots of different ways of looking at it. One of them is that, any particular implementation is making pragmatic choices, and these pragmatic choices are likely not to be able to cover all of the cases, at the level of efficiency, and even at the level of richness required.
이 메타-프로그래밍 개념이에요. 보는 방식이 많이 달라요. 그중 하나는 어떤 특정 구현도 실용적 선택을 하고, 이러한 실용적 선택은 효율성 수준에서, 심지어 필요한 풍부함 수준에서도 모든 경우를 커버할 수 없을 가능성이 크다는 거예요.
Of course, this is standard OOP lore. This is why we encapsulate. We need to hide our messes. We need to have different ways of dealing with the same concepts in a way that does not distract the programmer.
물론 이는 표준 OOP 지식이에요. 그래서 캡슐화하는 거예요. 우리의 지저분한 부분을 숨겨야 해요. 프로그래머를 산만하게 하지 않으면서 같은 개념을 다루는 다른 방법을 가져야 해요.
But in fact, it is also applicable, as the LISP people found, and we at Xerox PARC found; you can also apply it to the building of the language itself.
하지만 실제로 LISP 사람들이 발견했고 Xerox PARC에서 우리가 발견한 대로 언어 자체 구축에도 적용할 수 있어요.
The more the language can see its own structures, the more liberated you can be from the tyranny of a single implementation.
언어가 자신의 구조를 더 많이 볼수록 단일 구현의 폭정에서 더 자유로워질 수 있어요.
I think this is one of the most critical things that very few people are worrying about in a practical form.
이게 실용적 형태로 매우 적은 사람들이 걱정하는 가장 중요한 것 중 하나라고 생각해요.
One of the reasons why this meta stuff is gonna be important, in such a way that nobody will be able to ignore it, is this whole question of, How do we really interoperate on the Internet five and ten years from now.
이 메타 stuff가 아무도 무시할 수 없을 정도로 중요해질 이유 중 하나는 앞으로 5년, 10년 후 인터넷에서 어떻게 진짜 상호운용할까 하는 전체 질문이에요.
I don’t believe Microsoft is going to be able to capture the Internet. I think it’s too big. I think there are too many people supplying ideas into it, and I think that people are going to be sophisticated enough to realize that an IBM or a Microsoft type solution is simply neither called for nor possible.
Microsoft가 인터넷을 장악할 수 있을 거라고 믿지 않아요. 너무 크다고 생각해요. 너무 많은 사람들이 아이디어를 공급하고 있고, IBM이나 Microsoft 타입 해결책은 요구되지도 가능하지도 않다는 걸 사람들이 충분히 세련되게 깨달을 거라고 생각해요.
What that means is that there’s going to be dozens and dozens—there almost already are—dozens and dozens of different object systems, all with very similar semantics, but with very different pragmatic details.
그게 의미하는 건 수십, 수십 개—거의 이미—수십 수십 개의 다른 객체 시스템이 있을 거라는 거예요. 모두 매우 비슷한 의미론을 가지지만 매우 다른 실용적 세부사항을 가집니다.
If you think about what a URL actually is, and you think of what an HTTP message actually is, and if you think of what an object actually is, and if you think of what an object oriented pointer actually is, I think it should be pretty clear that any object-oriented language can internalize its own local pointers to any object in the world, regardless of where it was made.
URL이 실제로 무엇인지, HTTP 메시지가 무엇인지, 객체가 무엇인지, 객체 지향 포인터가 무엇인지 생각해보면 어떤 객체 지향 언어든지 어디서 만들어졌든 세계의 어떤 객체에 대한 자체 로컬 포인터를 내부화할 수 있다는 게 꽤 분명할 거예요.
That’s the whole point of not being able to see inside. A semantic interoperability is possible almost immediately by simply taking that stance.
그게 내부를 볼 수 없다는 전체 요점이에요. 그 입장을 취하는 것만으로 의미론적 상호운용성이 거의 즉시 가능해요.
This is gonna change, really everything. Things like JavaBeans and CORBA are not gonna suffice, because at some point one is gonna have to start really discovering what objects think they can do.
이건 정말 모든 걸 바꿀 거예요. JavaBeans나 CORBA 같은 건 충분하지 않을 거예요. 언젠가 객체들이 무엇을 할 수 있다고 생각하는지 정말 발견하기 시작해야 하기 때문이죠.
This is going to lead to a universal interface language, which is not a programming language per se. It’s more like a prototyping language that allows an interchange of deep information about what objects think they can do.
이건 프로그래밍 언어 자체가 아닌 보편적 인터페이스 언어로 이어질 거예요. 객체들이 무엇을 할 수 있다고 생각하는지에 대한 깊은 정보 교환을 허용하는 프로토타이핑 언어에 더 가까워요.
It allows objects to make experiments with other objects in a safe way to see how they respond to various messages. This is going to be a critical thing to automate in the next ten years. Next slide.
객체들이 다른 객체들과 안전한 방식으로 실험을 해서 다양한 메시지에 어떻게 반응하는지 볼 수 있게 해줘요. 이는 앞으로 10년 동안 자동화해야 할 중요한 일이 될 거예요. 다음 슬라이드.
[The slide is showing the book cover: The Art of the Metaobject Protocol]
[슬라이드는 The Art of the Metaobject Protocol 책 표지를 보여줍니다]
So here’s a great book. How many people have read this book? When they wrote this book, I called them up and I said, This is the best book anybody has written in ten years, but why the hell did you write it in such a LISP centric, closed club centric way?
여기 위대한 책이 있어요. 이 책 읽은 사람 몇 명이나 되나요? 이 책을 쓸 때 내가 전화해서 “10년 동안 누구나 쓴 최고의 책이지만 왜 이렇게 LISP 중심, 폐쇄 클럽 중심으로 썼나?“라고 했어요.
This is a hard book for most people to read. If you don’t know the LISP culture, it’s very hard to read. If you don’t know how CLOS is done, it’s a very hard book to read, but this book has some of the most profound insights about, and the most practical insights about OOP, than anybody has done in the last many years.
대부분 사람에게 읽기 어려운 책이에요. LISP 문화를 모르면 매우 어렵게 읽혀요. CLOS가 어떻게 되는지 모르면 매우 어렵게 읽혀요. 하지만 이 책은 지난 여러 해 동안 누구보다 OOP에 대한 가장 심오하고 가장 실용적인 통찰을 가지고 있어요.
I really commend it to you. If there are any university professors here who would like to get the next Limoges balloon, I will give it to anybody who rewrites that book so that the general object-oriented community can understand it. It would be a great service to mankind.
정말 추천해요. 여기 대학 교수 중 Limoges balloon을 받고 싶은 분 있으면, 일반 객체 지향 커뮤니티가 이해할 수 있게 그 책을 다시 쓰는 사람에게 주겠어요. 인류에 큰 봉사가 될 거예요.
What happened in most of the world, starting in the seventies, was abstract data types, which is really staying with an assignment centered way of thinking about programming.
70년대부터 대부분 세계에서 일어난 것은 추상 데이터 타입이었어요. 이는 프로그래밍에 대한 할당 중심 사고방식에 정말 머무르는 거예요.
In fact, when I made this slide, C++ was just sort of a spec on the horizon. It was one of those things, like MS-DOS, that nobody took seriously, because who would ever fall for a joke like that.
사실 이 슬라이드를 만들 때 C++은 지평선上の 사양 정도였어요. MS-DOS처럼 아무도 진지하게 받아들이지 않은 것 중 하나였죠. 그런 농담에 누가 넘어갈까.
Actually, my favourite C++ story is, at Apple, there is this operating system, remarkably, coincidentally named Pink.
실제로 내가 가장 좋아하는 C++ 이야기는 Apple에서 놀랍게도 우연히 Pink라는 이름의 운영 체제예요.
It was so great! There are two interesting features of this operating system that they were working on. One was, it was always going to be done in two years.
정말 대단했어요! 그들이 작업하던 이 운영 체제의 두 가지 흥미로운 특징이 있어요. 하나는 항상 2년 안에 완성될 거라는 거였어요.
We have known some really great operating system designers over the years, and I do not know of any decent operating system that has ever been done in two years, even by people who had ten times the IQ of the pink people.
수년 동안 정말 위대한 운영 체제 디자이너들을 알았지만 pink 사람들 IQ의 10배를 가진 사람들조차 2년 안에 제대로 된 운영 체제를 만든 적이 없어요.
The other thing about it was, it was gonna be done in C++ for efficiency. Oh, let’s not do it in Smalltalk, that’s too slow! Let me tell you, there’s nothing more inefficient than spending ten years on an operating system that never works.
또 다른 건 효율성을 위해 C++로 할 거라는 거였어요. Smalltalk로 하지 말자, 너무 느려! 10년을 들여서 절대 작동하지 않는 운영 체제에 쓰는 것보다 더 비효율적인 건 없다고 말할게요.
Actually, the worst ones are the ones that appear to work.
실제로 최악은 작동하는 것처럼 보이는 것들이에요.
Let’s take our pink plane, and we can also use this McLuhan quote—my favourite McLuhan quote—“I don’t know who discovered water, but it wasn’t a fish.” He meant us as the fish, and he meant water as our belief structures—as our context.
우리 분홍 평면을 가져와서 McLuhan 인용도 쓸 수 있어요—내가 가장 좋아하는 McLuhan 인용—“물이 누가 발견했는지 모르지만 물고기는 아니었다.” 그는 우리를 물고기로, 물을 우리의 믿음 구조—우리 맥락으로 의미했어요.
If you had to pick one cause, of both particular difficulty in our field, and also a general difficulty in the human race, it’s taking single points of view and committing to them like they’re religions.
우리 분야의 특별한 어려움과 인류의 일반적 어려움의 한 원인을 꼽아야 한다면, 단일 관점을 취하고 그것을 종교처럼 헌신하는 거예요.
This happened with Smalltalk. There’s a wonderful quote by Schopenhauer, a German philosopher of the nineteenth century, who said, “Every idea goes through three stages. First, it is denounced as the work of madmen.”—This is what Swift called “A Confederacy of Dunces”—and then later, it’s remarked as being totally obvious the whole time, and then the last stage is when the original denouncers claim to have invented it.
Smalltalk에서도 일어났어요. 19세기 독일 철학자 Schopenhauer의 멋진 인용이 있어요. “모든 아이디어는 세 단계를 거친다. 첫째, 미친 사람들의 작품으로 비난받는다.”—Swift가 “Dunces의 연맹”이라고 부른 거예요—그리고 나중에 항상 완전히 명백했던 것으로 언급되고, 마지막 단계는 원래 비난자들이 그것을 자신이 발명했다고 주장할 때예요.
That’s when it gets in its religious stage. To me, the most distressing thing that happened to Smalltalk when it came out of Xerox PARC, was, for many respects and purposes it quit changing.
그때 종교 단계에 들어가요. 나에게 Xerox PARC에서 나온 Smalltalk에게 일어난 가장 괴로운 일은 많은 측면과 목적으로 변화하기를 멈춘 거예요.
I can tell you, at Xerox PARC there are four major versions—completely different versions of the language—over about a ten year period, and many dozens and dozens of significant releases within those different versions.
Xerox PARC에서 약 10년 동안 네 가지 주요 버전—완전히 다른 언어 버전—이 있었고 그 다른 버전 내에 수십 수십 개의 중요한 릴리스가 있었어요.
I think one of the things we liked the most about Smalltalk was not what it could do, but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building.
Smalltalk에서 우리가 가장 좋아했던 것 중 하나는 그것이 할 수 있는 게 아니라 시스템 구축에 대한 다음 아이디어 세트를 부트스트랩하는 좋은 수단이었다는 사실이에요.
That, for all intents and purposes—when Smalltalk went commercial—ceased. Even though there is a book—the famous blue book that Adele and Dave wrote, that had the actual code in it for making Smalltalk interpreters and starting this process oneself—almost nobody took advantage of this.
그건 Smalltalk가 상용화되면서 실질적으로 중단됐어요. Adele과 Dave가 쓴 유명한 blue book이 Smalltalk 인터프리터를 만들고 이 과정을 스스로 시작하는 실제 코드가 들어있음에도 거의 아무도 활용하지 않았어요.
Almost no university took advantage of it. Almost no commercial institution took advantage of it. What they missed was, to me, the deepest thing I would like to communicate with you today, and that is we don’t know how to design systems yet.
거의 어떤 대학도 활용하지 않았어요. 거의 어떤 상업 기관도 활용하지 않았어요. 그들이 놓친 건 오늘 여러분께 전달하고 싶은 가장 깊은 것이에요. 우리는 아직 시스템을 설계하는 방법을 모른다는 거예요.
Let’s not make what we don’t know into a religion, for God’s sake. What we need to do is to constantly think and think and think about what’s important. We have to have our systems let us get to the next levels of abstraction as we come to them.
우리가 모르는 것을 종교로 만들지 맙시다. 우리가 해야 할 것은 중요한 것이 무엇인지 계속 계속 계속 생각하는 거예요. 우리가 도달할 때 다음 추상화 수준으로 가게 시스템을 만들어야 해요.
The thing I am most proud of about Smalltalk, pretty much the only thing, from my standpoint, that I am proud of, is that it has been so good at getting rid of previous versions of itself, until it came out into this world.
Smalltalk에 대해 내가 가장 자랑스러워하는 것, 거의 유일하게 자랑스러워하는 건 이 세상에 나올 때까지 이전 버전 자신을 제거하는 데 아주 좋았다는 거예요.
One of the reasons we got involved in doing Smalltalk again, after, for me, it was sixteen years of not working on programming languages. A couple of years ago we started this project called Squeak, which is simply not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk, and when you fool around with Squeak, please, please, think of it from that standpoint.
프로그래밍 언어 작업을 16년 하지 않은 후 Smalltalk를 다시 하게 된 이유 중 하나예요. 몇 년 전 Squeak이라는 프로젝트를 시작했는데 단순히 세계에 무료 Smalltalk를 주는 시도가 아니라 Smalltalk보다 훨씬 나은 것을 위한 부트스트랩 메커니즘을 주는 시도예요. Squeak을 가지고 놀 때 그 관점에서 생각해주세요.
Think of how you can obsolete the damn thing by using its own mechanisms for getting the next version of itself. So look for the blue thoughts!
그 빌어먹을 것을 자신의 메커니즘으로 다음 버전을 얻어 구시대적으로 만드는 방법을 생각해보세요. 그래서 파란 생각을 찾으세요!
I was trying to think of how I could stop this talk—because I’ll go on and on—and I remembered a story.—I’m a pipe organist, and most pipe organists have a hero whose name is E. Power Biggs.
이 강연을 어떻게 끝낼까 생각하다가—계속할 테니까—이야기를 떠올렸어요. 나는 파이프 오르간 연주자고 대부분 파이프 오르간 연주자들은 E. Power Biggs라는 영웅이 있어요.
He kind of revived the interest in the pipe organ, especially as it was played in the seventeenth and eighteenth centuries, and had a tremendous influence on all of us organists.
그는 17~18세기 연주된 파이프 오르간에 대한 관심을 되살리고 우리 모든 오르간 연주자에게 엄청난 영향을 줬어요.
A good friend of mine was E. Power Biggs’ assistant for many years back in the forties and fifties. He’s in his eighties now. When we get him for dinner, we always get him to tell us E. Power Biggs stories.
내 좋은 친구가 40~50년대에 E. Power Biggs의 조수로 오랫동안 있었어요. 지금 80대예요. 저녁 식사에 그를 모시면 항상 E. Power Biggs 이야기를 해달라고 해요.
The organ E. Power Biggs had in those days for his broadcasts, was a dinky little organ, neither fish nor foul, in a small museum at Harvard, called the Busch-Reisinger Museum.
그 당시 E. Power Biggs가 방송에 사용한 오르간은 Harvard의 작은 박물관 Busch-Reisinger Museum에 있는 작고 애매한 오르간이었어요.
But in fact, all manner of music was played on it, and one day this assistant had to fill in for Biggs, and he asked Biggs, well what is the piece played, and he said, Well I had programmed Caesar Franck’s heroic piece—and if you know this piece, it is made for the largest organs that have ever been made.
하지만 실제로 모든 종류의 음악이 그 위에서 연주됐고 어느 날 이 조수가 Biggs를 대신해야 했어요. 그는 Biggs에게 어떤 곡이냐고 물었고 Biggs는 Caesar Franck의 영웅적 곡이라고 했어요—이 곡을 아신다면 지금까지 만들어진 가장 큰 오르간을 위해 만들어진 거예요.
The loudest organs that have ever been made, in the largest cathedrals that had ever been made, because it’s a nineteenth century symphonic type organ work, and Biggs was asking my friend to play this on this dinky, little organ.—He said, But how can I play this, on this? Biggs, he said, Just play it grand. Just play it grand.
지금까지 만들어진 가장 큰 오르간, 가장 큰 대성당에서 연주되는 가장 큰 소리의 오르간이에요. 19세기 교향곡 스타일 오르간 작품이기 때문이죠. Biggs는 내 친구에게 이 작은 오르간으로 이걸 연주하라고 했어요. 그는 “하지만 이걸 어떻게 이걸로 연주하나?“라고 했고 Biggs는 “그냥 웅장하게 연주해. 그냥 웅장하게 연주해”라고 했어요.
To stay with the future as it moves, is to always play your systems more grand than they seem to be right now. Thank you.
미래가 움직이는 대로 함께하려면 지금 보이는 것보다 항상 시스템을 더 웅장하게 연주하는 거예요. 감사합니다.