'Book Review'에 해당되는 글 45건
- 2010/02/03 Coders at Work를 읽고 - 3
- 2010/01/16 Coders at Work를 읽고 - 2
- 2009/12/21 Coders at Work를 읽고 - 1 (4)
- 2009/09/17 프로그래밍 언어의 창시자들
- 2009/07/31 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4)
- 2009/07/13 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘
- 2009/06/01 번역으로 살펴보는 우리말
- 2009/04/12 The Productive Programmer (10)
- 2009/04/09 긍정과 부정, 3:1의 임계점을 향해 (6)
- 2009/02/28 그리스인 조르바 (4)
- Coders at Work를 읽고 - 3
Tweet
- Book Review
- 2010/02/03 07:32
- Coders at Work, Peter Norvig, Simon Peyton Jones
-
2009/12/21 - [Book Review] - Coders at Work를 읽고 - 1
2010/01/16 - [Book Review] - Coders at Work를 읽고 - 2
흥미로운 결과네요. 인터뷰 중 한군데에서 거의 낙제할 뻔하고도 입사한 친구들이 나중에 보면 대성했다는 통계.
2010/01/16 - [Book Review] - Coders at Work를 읽고 - 2
Simon Peyton Jones 함수형 언어 전문가. Haskell 언어의 핵심 공헌자
He said, "Just start something, no matter how humble." ... It turned out to be a very significant piece of advice. p. 249
I think my default is not to write something very general to begin with. So I try to make my programs as beautiful as I can but not necessarily as general as I can. p. 266
지나친 일반화와 부족한 일반화 사이의 균형 잡기에 관한 그의 견해.
STM is not going to save the world on its own. Concurrency, and parallel programming generally, is many-faceted beast and I don't think it will be slain by a single bullet. I'm a diversifist when it comes to concurrency. p. 271
Software Transactional Memory에 관한 견해. 아직도 연구 단계(Haskell 이외엔 본격 구현된 언어가 없음)인 STM가 만병통치약은 아님을 강조.
A sequential implementation of a double-ended queue is a first-year undergraduate programming problem. For a concurrent implementation with a lock per node, it's a research paper problem. That is too big a step. It's absurd for something to be so hard. With transactional memory it's an undergraduate problem again. p. 275
병렬 일고리즘의 구현이 얼마나 어려운지, 그나마 TM를 쓰면 난이도를 제어가능한 수준으로 낮출 수 있음을 역설.
As soon as you can do it, you stretch to the point where you can't do it anymore. I suppose I don't really see it as, is it this or is it that? There will always be a strong crafty element. I think, just because we'll stretch our ambition. In the case of engineering structures, there are physical limits on how far you can stretch. Nobody's going to build a bridge that traverses the Atlantic any time soon. And that really might fall down if you build it. But that's not the reason people won't build it - it's just because it'd be too expensive. Whereas nowadays, with software, once you can build bridges over the Channel pretty quickly and cheaply, well then, that becomes a done deal and we now think that's pretty cheap so we'll now try the Atlantic. And now it falls apart again. p. 280-281
소프트웨어가 완전한 공학이 될 수 없고 공예의 요소를 지닐 수밖에 없는 이유에 대한 통찰력 있는 설명.
The most depressing thing about life as a programmer, I think, is if you're faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That's depressing. p. 286
왠지 많이 공감가는...
Peter Norvig 골수 해커. 현재 구글 연구 디렉터
There's some saying in German about the perfect being the enemy of the good; I forget exactly where it comes from - every practical engineer has to learn that lesson. p. 306
역시 일반화의 추구와 실용성 사이의 균형에 대한 유사한 견해.
Seibel: You told me once that when Guido van Rossum came here he had to get checked out on Python and Ken Thompson had to get checked out on C, to make sure they could meet very explicit coding standards. p. 309
구글에 입사한 각 언어의 창시자들조차도 해당 언어에 대한 구글의 코딩 규범을 잘 따르는지 검수 받아야 했다는... ㅎㅎ 어쨌든 무서운 구글의 맨파워.
Sometimes I feel guilty about that. Is that a failure on my part? I didn't understand what the bug was. I didn't find the bug. I just dropped a bomb on the house and blew up all the bugs and built a new house. In some sense, the bug eluded me. But if it becomes the right solution, maybe it's OK. You've done it faster than you would have by finding it. p. 315
이해하기 어려운 코드에 버그가 있으면, 때론 그냥 처음부터 다시 짜는게 버그를 찾아 고치는 것보다 빠를 수 있다는... 해커다운 의견.
If you found that the programmers in the big corner offices were more productive, is that because you reward the good programmers with the offices, or is it because the offices makes them better? You can't really come to a conclusion. p. 316
생산성 측정의 어려움을 보여주는 일례라 생각합니다.
One of the interesting things we found, when trying to predict how well somebody we've hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of interviews, that was a really good indicator of success. p. 322
* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| Coders at Work를 읽고 - 3 (0) | 2010/02/03 |
|---|---|
| Coders at Work를 읽고 - 2 (0) | 2010/01/16 |
| Coders at Work를 읽고 - 1 (4) | 2009/12/21 |
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
- Coders at Work를 읽고 - 2
Tweet
- Book Review
- 2010/01/16 06:43
- Coders at Work, Joe Armstrong, Joshua Bloch
-
2009/12/21 - [Book Review] - Coders at Work를 읽고 - 1
Joshua Bloch 선 마이크로시스템즈에서 자바 작업. 현재 구글의 수석 자바 아키텍트
Joshua Bloch 선 마이크로시스템즈에서 자바 작업. 현재 구글의 수석 자바 아키텍트
Another is Elements of Style, which isn't even a programming book. You should read it for two reasons: The first is that a large part of every software engineer's job is writing prose. If you can't write precise, coherent, readable specs, nobody is going to be able to use your stuff. So anything that improves your prose style is good. The second reason is that most of the ideas in that book are also applicable to programs. p. 171역시 글쓰기의 중요성을 강조하는군요.
But when you choose a language, you're choosing more than a set of technical trade-offs - you're choosing a community. It's like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that's not the most important thing. It's who hangs out there and what they talk about. p. 174프로그래밍 언어의 선택이 단순히 기술적인 결정이 아니라는거죠. 단골 술집에의 비유가 참신하네요.
James Gosling once said to me, discussing the birth of Java, "Occasionally you get to hit the reset button. That's one of the most marvelous things that can happen. " Usually, you have to maintain compatibility with stuff that's decade old; rarely, you don't, and it's great when that happens. But unfortunately, as you can see with Java, it only takes you a decade until you're the problem. p. 191ㅎㅎ 새로 시작하는 것은 참 좋죠. 흔치 않은 기회고요. 하지만 가는 세월 앞에 새로웠던 코드가 리거시legacy 코드가 되는 것은 막을 길이 없는거겠죠... 꾸준한 리팩토링과 유지보수로 늦출 수는 있겠으나 엔트로피는 증가하게 마련.
But I think a big sin in our area, in engineering, is doing stuff just because it's neat, because it's good engineering, whatever. If you're not solving real problems for real users - in this case, Java programmers - then you shouldn't add the feature. p. 195
이 책을 관통하는 핵심 질문 중 하나인 프로그래머는 과연 공학자인가 과학자인가 예술가인가 장인인가 하는 문제와도 연관되는 내용. 게임 프로그래밍에서는 특히나 명심해야할 부분이겠는데... 역시 말처럼 지키기 쉽지만은 않은 명제입니다.
There's a brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: "One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." p. 196
아주 단순하게 만들여 '결함이 확실히 없도록' 하거나 아주 복잡하게 만들어 '확실한 결함이 없도록' 하거나...
But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages. p. 203
지능은 스칼라가 아닌 벡터값이다!
Joe Armstrong 얼랭Erlang 언어와 그 대표적 응용프로그램 프레임웍인 Open Telecom Platform의 창시자
I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. p. 213
서서히 개체지향이 프로그래밍의 핵심 조류에서 밀려나는 느낌을 여러 곳에서 받습니다. 멀티코어 및 매니코어manycore의 필연적 대두가 그 주요 원인 중 하나입니다. 바나나를 원했는데, 나오는건 바나나를 든 고릴라와 정글의 온갖 것이다라... 왠지 마음에 와 닿습니다.
One that's tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won't occur. If you've got a long variable like personName and you've got personNames with an "s" on the end, that's a list of person names, that will be something that my eye wil tend to read what I thought it should have been. And so I'd have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I'd written. p. 220
personName이란 변수가 있고 사람 이름 목록에 해당하는 변수가 필요하다면, personNames 보다는 listOfPeople을 택하겠다는 의견. 작명이 프로그래밍에서도 참 어렵고 중요한 문제입니다. 영어를 잘해야 하는 또 하나의 이유.
What we learned later was, it wasn't all that easy to discover new stuff. And it's incredibly difficult to get people to use new and better stuff. p. 220
새로운 것을 발견하고 만들어내기도 어렵지만, 새로운 것을 사람들이 받아들이게 하는 것은 훨씬 더 어렵다...
Things you don't do are difficult and things you've done are easy. So you don't even try. And I think that's a mistake. p. 223
심감독의 유명한 말이 생각나네요...;
Good to thrash your ideas out in front of the crowd. You're put in a position of explaining your ideas which, for me, moves them from one part of my brain to another part. Often when you explain things then you understand them better. p. 228
자신의 아이디어를 남에게 설명하는 과정에서, 생각이 정리되는 느낌, 다들 경험해 보셨죠?
The code shows me what it does. It doesn't show me what it's supposed to do. I think the code is the answer to a problem. If you don't have the spec or you don't have any documentation, you have to guess what the problem is from your answer. You might guess wrong. I want to be told what the problem is. p.231-232
코드는 문제에 대한 답이다. 문서나 명세가 없다면 답에서 문제를 추측해낼 수밖에 없다. 문서화의 필요성에 대한 명쾌한 설명!
And Hamming said, "I always spend a day a week learning a new stuff. That means I spend 20 percent more of my time than my colleagues learning new stuff. Now 20 percent at compound interest means that after four and a half years I will know twice as much as them. And because of compound interest, this 20 percent extra, one day a week, after five years I will know three times as much," or whatever the figures are. p. 234
매일 조금씩의 학습에 대한 투자가 나중에는 복리로 크게 불어난다는 이야기. 제가 사람을 뽑을 때 가장 중요하게 보는 부분 중 하나입니다. 얼마나 학습 열의가 있느냐 하는 것이죠.
* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| Coders at Work를 읽고 - 3 (0) | 2010/02/03 |
|---|---|
| Coders at Work를 읽고 - 2 (0) | 2010/01/16 |
| Coders at Work를 읽고 - 1 (4) | 2009/12/21 |
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
- Coders at Work를 읽고 - 1
Tweet
- Book Review
- 2009/12/21 06:07
- Brad Fitzpatrick, Brendan Eich, Coders at Work, Douglas Crockford, Jamie Zawinski
-
유명 프로그래머들과의 인터뷰를 엮은 책입니다. 인터넷의 여러 호평대로 흥미롭게 읽었습니다. 나름 프로그래밍 분야에서 일가를 이루 사람들의 생각을 들어보고 서로 비교해볼 수 있어 좋았습니다. 앞으로 몇 회에 걸쳐 인상 깊었던 문구를 중심으로 간단한 감상 글을 적어보겠습니다.
Jamie Zawinski : 리스프 해커, 초기 넷스케이프 개발자, 나이트클럽 주인I think one thing that's really important is to not be afraid of your ignorance. If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb - it just means you don't know it yet. p. 40
매우 자명하지만 잊기 쉬운 마음가짐입니다.
Brad Fitzpatrick : LiveJournal 만든이. 현재 구글 재직 중
I see people that are really smart - I would say they're good programmers - but say they noly know Java. The way they think about solving things is always within the space they know. They don't think end-to-end as much. I think it's really important to know the whole stack even if you don't operate within the whole stack. p. 65
요즘에도 프로그래머가 어셈플리 등의 저수준 지식을 가져야 하는가에 대한 그의 대답. 컴퓨터가 복잡해지면서 레이어 위에 레이어가 쌓인 오늘날에 참 따르기 힘든 말입니다만, 그러기에 더욱 중요한 조언이 아닌가 합니다.
But a lot of times lately, if there's something weird going on, I'm like, "OK, that function is too big; let's break that up into smaller parts and unit-test each one of them separately to figure out where my assumptions are wrong, rather than just stickling in random printlns." p. 79
많은 프로그래머들이 print 문을 여전히 가장 애용하는 디버깅 툴로 꼽더군요; 소스레벨 심볼릭 디버거가 등장한지 그리 오래지 않았고, 여전히 지원이 안되는 환경도 많으니 그러겠지요... 어쨌든 저 잘게 쪼갤 수 있을 때까지 쪼갠다가 제 코딩에서도 지향점이 되고 있습니다.
Optimization is fun because it's not necessary. p.80
흥미로운 관점입니다. ^^
I don't feel like I'm competing with anyone right now and I don't really care if other people are better because I feel like there are tons of people who are better already. I figure we are always in the middle anyway, so I'm happy to stay in the middle. p. 89
이 정도를 이룬 사람으로서 매우 겸손한 자세... (특히나 상당히 젊은 친구임을 감안하면 참 인물이다 싶군요.)
Douglas Crockford : 야후에 재직 중인 자바스크립트 아키텍트. JSON 만든이
Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct. So I think it's probably not good code and they probably made the wrong trade-offs if the code turned out to be in the state that it's not easily readable. p. 107
코드의 가독성을 매우 중시. 많은 인터뷰 대상자들의 공통점이었습니다. 코드의 유지보수에는 결국 사람이 필요하고, 유지보수자(시간이 흐른 뒤의 원작자를 포함하여)가 소스를 얼마나 명확하고 쉽게 이해할 수 있는가가 비용에 직결되겠죠.
So I would actually rather see people start as English majors than as math majors to get into programming. p. 124
수학도 수학이지만 자신의 모국어를 어느 정도 알고 활용할 수 있는가 이 분야에서도 매우 중요하다는 지적. 결국은 코딩도 커뮤니케이션이기에...
Brendan Eich : 자바스크립트 만든이. 현재 모질라의 CTO
So a blue-collar language like Java shouldn't have a crazy generic system because blue-collar people can't figure out what the hell the syntax means with covariant, contravariant type constraints. p. 147
자바를 '블루칼라' 언어로 보는군요. ㅎ 그런 경향이 전혀 없지는 않지만, 그래도 '성급한 일반화의 오류'라 해야겠죠? ^^
Larry Wall is right. Laziness should be a virtue. So that's why I prefer automation. p. 151
과연 게으른 개발자가 나은가하는 질문이 많이 재기되는데요... 저도 정답은 모르겠습니다. 게으른 면이 있어야 똑같은 일을 반복하게 되면 자동화를 시도하게 된다인데... 저도 사실 이 부분이 약한 편이어서, 그 동안 여러 면에서 자동화를 도입하려고 많이 노력했습니다. 결국은 균형과 조화의 문제라고 봅니다.
I have this big allergy to ivory-tower design and design patterns. Peter Norvig, when he was at Harlequin, he did this paper about how design patterns are really just flaws in your programming language. Get a better programming language. He's absolutely right. Worshipping patterns and thinking about, "Oh, I'll use the X pattern." p. 155
디자인 패턴은 결국 프로그래밍 언어의 결함을 보완하기 위한 시도. 따라서 패턴을 맹신하기 보다는 더 나은 언어를 선택해라 입니다. 문제는 완벽한 언어는 어디에도 없다는 거겠죠. 하지만 무엇이 되었든 맹신하는 것은 좋지 않습니다.
That's always a challenge because a programmers have to be optimists. We're supposed to be paranoid, neurotic, Woody Allen types who are always worried about things, but really you wouldn't get anywhere in programming if you were truly paranoid. p. 164
다소 결벽증이 있어야 세심함을 요구하는 코딩을 잘 할 수 있다, 하지만 결벽증만으로는 앞으로 나아갈 수 없다, 따라서 프로그래머는 기본적으로 낙관적이어야 한다... 코딩에서의 딜레마를 절묘하게 표현한 듯.
I am not JavaScript. In the early days, it was such a rush job and it was buggy and then there was some Usenet post Jamie Zawinski forwarded me. He said, "They're calling your baby ugly." I have real kids now; I don't have to worry about that. p. 166
ㅋㅋ 우문현답입니다. 이번 회는 여기까지입니다.
* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| Coders at Work를 읽고 - 3 (0) | 2010/02/03 |
|---|---|
| Coders at Work를 읽고 - 2 (0) | 2010/01/16 |
| Coders at Work를 읽고 - 1 (4) | 2009/12/21 |
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
- 프로그래밍 언어의 창시자들
Tweet
- Book Review
- 2009/09/17 05:58
- masterminds of programming, Programming, Programming Languages, 프로그래밍, 프로그래밍 언어
-
다음과 같은 여러 프로그래밍 언어를 만든이들과의 인터뷰를 엮은 책입니다.
- C++
- Python
- APL
- Forth
- Basic
- Awk
- Lua
- Haskell
- ML
- SQL
- Objective-C
- JAVA
- C#
- UML
- Perl
- Postscript
- Eiffel
더 나은 프로그래머가 되려면?
... Don't add functionality that you think will be useful some time in the future: adding it now may prevent you from adding a much better feature later on, when it's really needed. ... - Luiz Henrique de Figueiredo, Lua, p. 166
프로그래머 한 명이 종이 반 상자 정도의 코드를 관리할 수 있다고 말한 적이 있다던데...
... It's amazing how helpful that one little fact turns out to be. 100,000 lines of code is a box of printout. It cost $3 million to develop. It takes two people to maintain it. The number of test cases to fully test that box of code is another two or three boxes of code. - Tom Love, Objective-C, p. 251
언어의 발명, 추가 개발, 수용의 과정에서 얻은 교훈이 있다면?
Microsoft Word was written by eight programmers, while the wooden variety involved thousands, none of whom could appreciate the full complexity of harvesting lumber, mining graphite, smelting metals, making lacquer, growing rapeseed for oil, etc. The complexity was there in the pencil, but hidden from user. - Brad Cox, Objective-C, p. 263, 나무 연필에 숨어있는 복잡성을 디지털 연필에 해당하는 워드 소프트웨어와 비교하며
왜 컴퓨터 과학은 진짜 과학이 아닌가?
Each time you encounter a new piece of software, you encounter something completely new and unique. How can you have a science where everything is unique? ... - Brad Cox, Objective-C, p. 275
자원봉사자들한테는 일을 강요할 수 없다. 강요하더라도 먹히지 않는다.
... So as the saying goes, if you can't fix it, feature it. Larry Wall, Perl, p. 393
명세와 구현의 구분이 중요한가?
... One of the characteristics of software is that any software element you look at is the specification of something that is more concrete and the implementation of something that is more abstract. ... - Bertrand Meyer, Eiffel, p. 422
작고 탄탄한 핵심(예를 들면, 람다 수식)에서 시작하여 언어를 구축해나가는 방식에 대해 어찌 생각하는가?
... The difficulty of programming is twofold: the scientific difficulty and the engineering difficulty. ... - Bertrand Meyer, Eiffel, p. 430
공부하면 할수록 내가 모르던 게 많았음을 새삼 느낍니다...
 Mountain Lion Safety by ekai    |
* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| Coders at Work를 읽고 - 2 (0) | 2010/01/16 |
|---|---|
| Coders at Work를 읽고 - 1 (4) | 2009/12/21 |
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
- 글쓰기 공작소 - 나도 글 잘 쓰고 싶다
Tweet
- Book Review
- 2009/07/31 05:53
- 글쓰기, 글쓰기 공작소, 글쓰기공작소, 사생글, 이만교
-
프로그래머 중에도 맛깔나게 글을 쓰는 친구들이 많습니다. 언어적 감수성과 거리가 먼 저도 그런 글을 보면 잘 쓰고 싶어집니다. 그래서 이 책도 점 찍어 두었다가 기회가 되어 Y 온라인 서점에서 해외 주문하였습니다. 유명 작가 이만교 씨가 글쓰기 강좌를 진행하면서 느끼고 고민한 바를 정리한 책입니다.
나대로 요약
- 글쓰기는 기본적으로 의사소통. 일상 대화에서는 소통에서 언어가 차지하는 비중이 20%뿐이지만 글쓰기에서는 글로만 가능하므로 언어 감각이 매우 중요하다.
- 그리하여 글쓰기언어(출판언어)는 일상언어와 달라야 한다.
- 상투적 다수언어가 아닌 참신하면서도 공감가는 창작언어로 써야 한다.
- 배우가 극중인물을 연기하듯, 작가는 주인공 및 화자가 되어 글을 풀어갈 수 있어야 한다.
- 지금, 여기에서의 글쓰기
2009년 2월 7일 새벽 6시 11분 현재 내 마음이 행복한 글 공부에 미쳐 있다면, 세월이 아무리 흘러도, 2009년 2월 7일 새벽 6시 11분 현재의 내 마음은 행복한 글 공부에 미쳐 있었다는 사실을 결코 아무도 부인하지 못할 것이다. - p. 381
실천합시다!
- 독서하면서 씨앗 문장들을 모아두자. 위키에 정리하면 좋을듯.
- 사생글(사람이나 사건, 사물을 눈앞에서 보면서 그림 그리듯이 쓰는 글)로 연습하자.
 I am just by *Zara |
* 이 포스트는 blogkorea [블코채널 : 책 읽는 사람들] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| Coders at Work를 읽고 - 1 (4) | 2009/12/21 |
|---|---|
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
| The Productive Programmer (10) | 2009/04/12 |
- 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘
Tweet
- Book Review
- 2009/07/13 04:16
- C++, concept, Elements of Programming, iterator, STL, 알고리즘
-
책 제목과 C++을 만든 이인 Bjarne Stroustrup의 추천 글귀에 끌려 이북으로 구입하였습니다.
일단 총평은 다음과 같습니다.
- 굉장히 신선한 접근이다.
- C++ 기준으로 설명하니 좋다.
- 신선한 만큼 개념 잡기가 쉽지 않다; (생소한 용어와 상당히 추상적 수학적 개념 대거 등장)
- 제대로 이해하려면 최소 한번 더 읽어봐야 할듯
- 그럼에도 건질만한 건 있었다...
* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
'Book Review' 카테고리의 다른 글
| 프로그래밍 언어의 창시자들 (0) | 2009/09/17 |
|---|---|
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
| The Productive Programmer (10) | 2009/04/12 |
| 긍정과 부정, 3:1의 임계점을 향해 (6) | 2009/04/09 |
- 번역으로 살펴보는 우리말
Tweet
- Book Review
- 2009/06/01 19:58
- translation, 번역, 번역의탄생, 우리말, 한글
-
이번 출장 때 사서 읽은 책입니다.
저도 개발 관련 서적을 두 권 번역해본 경험이 있습니다. 지금 생각해보면 너무 부족한 것이라 이야기하기도 부끄럽습니다. 어쨌든 그때 그리고 그 이후에도 느낀 것이지만, 번역이란 것이 참 어려운 것이더군요. 그리고 영어도 영어지만 국어 실력이 많이 필요한 작업임을 알게 되었습니다.
저도 개발 관련 서적을 두 권 번역해본 경험이 있습니다. 지금 생각해보면 너무 부족한 것이라 이야기하기도 부끄럽습니다. 어쨌든 그때 그리고 그 이후에도 느낀 것이지만, 번역이란 것이 참 어려운 것이더군요. 그리고 영어도 영어지만 국어 실력이 많이 필요한 작업임을 알게 되었습니다.
그런 맥락에서 본 책도 진작에 눈의 띄어 출장 간 김에 사서 보았습니다. 결론은 대만족입니다. 저자의 고민과 수고만큼이나 배울 것이 많았습니다. 직역이냐 의역이냐(저자는 각각 '들이밀기'와 '길들이기'로 표현하고 있습니다만)의 갈림길에서 저자는 의역을 택하고 있습니다. 현재 국내 번역이나 한글의 실정이 지나치게 '들이밀기'의 영향을 많이 받아 균형을 잃었다고 판단한 까닭입니다.
알게 된 것들
- 영어와 달리 한국어는 주어를 생략하는 경우가 많다
- The rough rock has abraded my skin.
- 거친 바위에 살갗이 벗겨졌다.
- 사물이 주어로 오는 영어 타동사 문장을 사람이 주어로 오는 자동사 문장으로 바꾸면 과도한 사동문을 피할 수 있다
- The intoxication of the crowds made Hitler feel like a god.
- 군중이 열광하니까 히틀러는 신이라도 된 듯한 느낌이었다.
- 영어는 추상에 강한데 반해, 한국어는 구체성에 강하며 부사에 그 비결이 있다
- He sat nodding in front of the fire.
- 그는 난로 앞에서 꾸벅꾸벅 졸았다.
- 영어 형용사는 한국어 부사로 옮긴다
- I searched the entire palace.
- 궁궐을 샅샅이 뒤졌다.
- 한국어의 특징인 풍부한 어미를 잘 활용하면 간결하게 번역할 수 있다.
- They say they have no money.
- 돈들이 없대.
- 번역 시 군살은 뺄수록 아름답다
- She found her husband stabbed to death.
- 남편은 칼에 찔려 죽어 있었다.
- 뒤집으면 자연스럽다
- Please memorize this dialogue before you come back.
- 이 대화는 다 외워서 오세요.
- 토박이말을 잘 활용하자
- 영일사전 등을 베낀 것이 아닌 우리 삶이 담긴 사전이 필요하다
번역이나 우리말 배우기에 관심이 있는 분이라면 강추드립니다.
'Book Review' 카테고리의 다른 글
| 글쓰기 공작소 - 나도 글 잘 쓰고 싶다 (4) | 2009/07/31 |
|---|---|
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
| The Productive Programmer (10) | 2009/04/12 |
| 긍정과 부정, 3:1의 임계점을 향해 (6) | 2009/04/09 |
| 그리스인 조르바 (4) | 2009/02/28 |
- The Productive Programmer
Tweet
- Book Review
- 2009/04/12 07:28
- Demeter, Domain Specific Language, dry, Fluent Interface, Neal Ford, The Productive Programmer, ThoughtWorks, YAGNI
-
오픈 소스 CI(Continuous Integration) 솔루션인 CruiseControl의 개발사로 유명한 ThoughtWorks의 Neal Ford가 지은 책입니다.
생산적인 프로그래머가 되기 위한 지은이 나름대로의 노하우 및 철학을 펼쳐보입니다.
나대로 요약
알게 된 것들
몇몇 생각할거리를 던져준 괜찮은 책이었습니다.
생산적인 프로그래머가 되기 위한 지은이 나름대로의 노하우 및 철학을 펼쳐보입니다.
나대로 요약
- 명령행을 잘 쓰자
- 자신이 쓰는 도구를 잘 익히자
- 자동화를 생활화하자
- DRY
- 정적 코드 분석을 잘 이용하자
- YAGNI
- The Law of Demeter
알게 된 것들
- Fluent Interfaces
- 게임개발도 DSL(Domain-specific Language)을 활용한 메타프로그래밍으로 흘러갈까요?
- 화난 원숭이(angry monkey)는 되지 말자
몇몇 생각할거리를 던져준 괜찮은 책이었습니다.
'Book Review' 카테고리의 다른 글
| 수학적 엄밀함으로 살펴보는 C++ 타입과 알고리즘 (0) | 2009/07/13 |
|---|---|
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
| The Productive Programmer (10) | 2009/04/12 |
| 긍정과 부정, 3:1의 임계점을 향해 (6) | 2009/04/09 |
| 그리스인 조르바 (4) | 2009/02/28 |
| 오른쪽 두뇌로 그림그리기 (8) | 2009/02/21 |
- 긍정과 부정, 3:1의 임계점을 향해
Tweet
- Book Review
- 2009/04/09 19:52
- Barbara Fredrickson, happiness, positivity, positivity ratio, 긍정, 행복
-
트위터에서 제가 따라다니는 한 친구의 블로그에 혹해 오디오북으로 구입한 녀석입니다. "Positivity: Groundbreaking Research Reveals How to Embrace the Hidden Strength of Positive Emotions, Overcome Negativity, and Thrive"라는 긴 제목의 책입니다.
제가 파악한 책의 핵심
- 긍정 대 부정의 비율이 3:1을 넘어서야 자신의 꿈을 펼치는 행복한 삶을 살 수 있다.
- 대부분의 평범한 사람들은 2:1 수준에 머물러 있다.
- 그래서 많은 사람들이 자신은 긍정적인 편인데도 제대로 일이 안풀린다고 불평하며, 긍정성이 별 도움이 안된다고 생각한다.
- 이러한 임계점의 존재는 실험과 수학적 이론 양쪽으로 근거가 있다.
- 부정적인 순간도 필요하다. 항상 하하거릴 수만은 없다.
- 대체로 11:1이 현실적 한계다. 이 이상 넘어가면 미친사람 소리 듣는다;
- 사람의 긍정성의 50%는 유전자에 의해 결정된다. 하지만 나머지 50%는 자기하기 나름이다... (저의 이전글에서도 비슷한 언급이 있습니다.)
- 긍정성은 성공의 결과가 아니라 원인이다.
감상 및 할일
- 저의 비율은 형편없이 낮았습니다;; 테스트는 여기서 가능.
- 나는 긍정성 증대가 시급히 요구된다.
- 책이 긍정성 증대를 위한 방법들이 제시되지만... 잘 모르겠다.
- 기대치를 낮추고, 다른 사람들 기분보다는 내 기분 먼저 챙기고, 더 즐겨야 한다...
어쨌든 긍정성의 3:1 티핑 포인트라는 제시가 흥미로운 책이었습니다.
'Book Review' 카테고리의 다른 글
| 번역으로 살펴보는 우리말 (0) | 2009/06/01 |
|---|---|
| The Productive Programmer (10) | 2009/04/12 |
| 긍정과 부정, 3:1의 임계점을 향해 (6) | 2009/04/09 |
| 그리스인 조르바 (4) | 2009/02/28 |
| 오른쪽 두뇌로 그림그리기 (8) | 2009/02/21 |
| 학습의 학습 (0) | 2009/01/14 |
- 그리스인 조르바
Tweet
- Book Review
- 2009/02/28 13:41
- Zorba, Zorba The Greek, 그리스인 조르바, 니코스 카잔차키스, 조르바, 카잔차키스
-
 | 그리스인 조르바 -  니코스 카잔차키스 지음/열린책들
|
'Book Review' 카테고리의 다른 글
| The Productive Programmer (10) | 2009/04/12 |
|---|---|
| 긍정과 부정, 3:1의 임계점을 향해 (6) | 2009/04/09 |
| 그리스인 조르바 (4) | 2009/02/28 |
| 오른쪽 두뇌로 그림그리기 (8) | 2009/02/21 |
| 학습의 학습 (0) | 2009/01/14 |
| 프로그래밍과 보이스카웃 규칙 (0) | 2008/12/19 |
Recent comment