'Coders at Work'에 해당되는 글 5건

  1. 2010/02/03 Coders at Work를 읽고 - 3
  2. 2010/01/16 Coders at Work를 읽고 - 2
  3. 2009/12/21 Coders at Work를 읽고 - 1 (4)
  4. 2009/12/10 My Recent Tweets 20091207 (2)
  5. 2009/10/22 My Recent Tweets 20091021

Coders at Work를 읽고 - 3

2009/12/21 - [Book Review] - Coders at Work를 읽고 - 1
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에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


크리에이티브 커먼즈 라이선스
Creative Commons License

'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
Trackback 0 Comment 0

Coders at Work를 읽고 - 2

2009/12/21 - [Book Review] - Coders at Work를 읽고 - 1


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에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다. 


크리에이티브 커먼즈 라이선스
Creative Commons License

'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
Trackback 0 Comment 0

Coders at Work를 읽고 - 1

유명 프로그래머들과의 인터뷰를 엮은 책입니다. 인터넷의 여러 호평대로 흥미롭게 읽었습니다. 나름 프로그래밍 분야에서 일가를 이루 사람들의 생각을 들어보고 서로 비교해볼 수 있어 좋았습니다. 앞으로 몇 회에 걸쳐 인상 깊었던 문구를 중심으로 간단한 감상 글을 적어보겠습니다.
 
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에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.   


크리에이티브 커먼즈 라이선스
Creative Commons License

'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
Trackback 0 Comment 4

My Recent Tweets 20091207


프로그래밍programming

방법론methodology

그래픽스graphics

병렬성parallelism
  • RT SoftTalkBlog: Parallelising an imaging application - whitepaper - http://bit.ly/8dXwx1 #multicore #intel #parallelism #
    • 순차 수행으로 작성된 응용프로그램을 어떻게 병렬화할 수 있는지 보여주는 문서
  • RT bjoernknafla: /via JamesReinders: 48core research chip SinglechipCloudComputing:SCC http://bit.ly/7iufrL IntelLabs #parallelism #
    • 인텔에서 발표한 연구용 48코어 칩
  • RT dvyukov: Relacy Race Detector kicks $hit out of HotSpot http://bit.ly/4psH3a #parallelism #
    • Relacy Race Detector를 사용해 어떻게 레이스를 잡아내는지 보여주는 실례
  • The Microsoft Research Accelerator system provides simplified programming of GPUs via a high-level data... http://su.pr/1gAPQH #parallelism #
    • 마이크로소프트 연구소에서 내어놓은 GPU 기반 닷넷 플랫폼 데이터병렬 라이브러리
  • RT SoftTalkBlog: When multicore processors cause programs to run more slowly http://bit.ly/599k3b #parallel #programming #parallelism #
    • 포브스지에 실린 멀티코어 프로세서를 위한 프로그래밍에 대한 글

게임개발gamedev

기타etc



* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


크리에이티브 커먼즈 라이선스
Creative Commons License

'Tweets' 카테고리의 다른 글

My Recent Tweets 20100118  (0) 2010/01/19
My Recent Tweets 20100104  (0) 2010/01/05
My Recent Tweets 20091207  (2) 2009/12/10
My Recent Tweets 20091120  (0) 2009/11/24
My Recent Tweets 20091104  (0) 2009/11/06
My Recent Tweets 20091021  (0) 2009/10/22
Trackback 0 Comment 2

My Recent Tweets 20091021

프로그래밍programming

병렬성parallelism
  • RT programmingjoy: What is this thing you call "thread safe"? #programming http://bit.ly/2odln7 #parallelism #
    • 스레드안정성의 의미에 관한 고찰
  • RT bjoernknafla: Intel sponsored Gamasutra article by Ryan Shrout & Leigh Davis about thread programming for Nehale... http://bit.ly/29EhcL #
    • 인텔 CPU의 근래 변화와 관련 최적화 팁
  • RT SoftTalkBlog: Intel Ct Technology opens for beta applications. New tool to automate data parallelism. http://bit.ly/12arQy #parallelism #
    • 데이터 병렬화를 자동화해주는 인텔의 새로운 도구 Ct

개발방법론methodology

그래픽스graphics

기타etc.



* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


크리에이티브 커먼즈 라이선스
Creative Commons License

'Tweets' 카테고리의 다른 글

My Recent Tweets 20091120  (0) 2009/11/24
My Recent Tweets 20091104  (0) 2009/11/06
My Recent Tweets 20091021  (0) 2009/10/22
My Recent Tweets 20090928  (0) 2009/10/01
My Recent Tweets 20090909  (0) 2009/09/10
My Recent Tweets 20090826  (0) 2009/08/26
Trackback 0 Comment 0
top