- 出版社: Apress; 1st ed. (2009年9月16日)
- 平装: 632页
- 语种： 英语
- ISBN: 1430219483
- 条形码: 9781430219484
- 商品尺寸: 15.2 x 3.6 x 22.9 cm
- 商品重量: 857 g
- ASIN: 1430219483
- 用户评分: 分享我的评价
- 亚马逊热销商品排名: 图书商品里排第1,199,368名 (查看图书商品销售排行榜)
Coders at Work: Reflections on the Craft of Programming (英语) 平装 – 2009年9月16日
买满 ￥199.00 立减 ￥10.00: 满足条件自动优惠
Peter Seibel is a serious developer of long standing. In the early days of the Web, he hacked Perl for Mother Jones and Organic Online. He participated in the Java revolution as an early employee at WebLogic which, after its acquisition by BEA, became the cornerstone of the latter's rapid growth in the J2EE sphere. He has also taught Java programming at UC Berkeley Extension. He is the author of Practical Common LISP from Apress.
- Jamie Zawinski
- Brad Fitzpatrick
- Douglas Crockford
- Brendan Eich
- Joshua Bloch
- Joe Armstrong
- Simon Peyton Jones
- Peter Norvig
- Guy Steele
- Dan Ingalls
- L Peter Deutsch
- Ken Thompson
- Fran Allen
- Bernie Cosell
- Donald Knuth
Though weighty, there are numerous great sound bites throughout. Jamie Zawinski, "one of the prime movers behind [...], the organization that took the Netscape browser open source", is quoted as saying "I hope I don't sound like I'm saying, 'Testing is for chumps.' It's not. It's a matter of priorities. Are you trying to write good software or are you trying to be done by next week? You can't do both. One of the jokes we made at Netscape a lot was, 'We're absolutely 100 percent committed to quality. We're going to ship the highest-quality product we can on March 31st." Seibel poses the following question to Douglas Crockford, inventor of JSON: "In one of your talks you quoted Exodus 23:10 and 11: 'And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still' and suggested that every seventh sprint should be spent cleaning up code. What is the right time frame for that?" To which Crockford replies: "Six cycles - whatever the cycle is between when you ship something. If you're on a monthly delivery cycle then I think every half year you should skip a cycle and just spend time cleaning the code up."
Joshua Bloch, Chief Java Architect at Google at the time this book was written, comments that "there's this problem, which is, programming is so much of an intellectual meritocracy and often these people are the smartest people in the organization; therefore they figure they should be allowed to make all the decisions. 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. What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills - all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good engineer."
Summarized as the "mother" of Smalltalk (the counterpart to Alan Kay, the "father" of Smalltalk), Dan Ingalls comments that "people should learn to think clearly and to question. And to me it's very basic. If you grow up in a family where when the cupboard door doesn't close right, somebody opens it up and looks at the hinge and sees that a screw is loose and therefore it's hanging this way vs. if they say, 'Oh, the door doesn't work right; call somebody' - there's a difference there. To me you don't need any involvement with computers to have that experience of what you see isn't right, what do you do? Inquire. Look. And then if you see the problem, how do you fix it? To me it's so basic and human and comes so much from parent to child. Computers are certainly a medium for doing that. But they're just computers. There's a lot of that that will transfer, but to me it's really big and basic and human, so it's not like we're going to enlighten the world just by teaching them computers."
At least one reviewer has complained that this title didn't "detail" how these programmers worked and how they approached programming. I must thoroughly disagree. The opinions of these people on common points of disagreement from type systems to tools and coding styles to debugging methods was explored. If you are hoping that you will be able to watch the subjects solve a complex problem or go through a typical day's work than you are in the wrong place. This isn't a screencast or a tutorial. On the other hand, there are a wide variety of opinions on display from experts in different areas of the field across different generations on numerous contentious issues.
This book is filled with words worth chewing on. On the first read, the interviews of Crockford, Deutsch, Eich, and Peyton-Jones stuck out to me in particular. In subsequent readings I expect that set to be different. All of the interviewees did agree on the importance of one thing, reading and writing code. For a beginner, this book is likely to point out some pitfalls that otherwise would've been missed and suggests valuable sources of intuition and insight. Perhaps most importantly, it may help popularize some knowledge of the history of our field. As Knuth laments, "The idea that people knew a thing or two in the '70s is strange to a lot of young programmers." There is some valuable distilled experience and wisdom here. At the very least, the book should help you hash over your own opinions on the issues discussed.
And questions about live topics of today: What do you really think about C++? Shouldn't we be proving our programs correct? Should code be documented? What is Joe's law of debugging? Who has NOT read "Worse is Better"? Some of the answers might surprise and enlighten you.
I found it impossible to put this book down. It might affect your productivity for a couple of days, but I think you will think about programming a little differently.
I strongly recommend this book for programmers and people who have programmers in their life.
After reading this book I found myself wanting to learn more about systems programming and while I probably will always work in application programming, I now have a new found respect for the hard work that these scientists and hackers have put throughout their life-long careers.
This book is a must read for any passionate programmer who is interested about the history and the early developments made in the software industry, developments that made today's technologies possible!
The diversity of approaches, mindset, attitude, and execution of each of the coders interviewed is a welcome change from the onslaught of the "best practices" mindset which has become increasingly popular in recent years. Even more amazing is the levels of success that they have achieved in spite of (or perhaps, because of) their differences.
While some would find the repetition of questions or extended stories regarding the history of each coder yawn-inducing, I found it to be a refreshing break from the standard computer book fare. If you want to learn about a specific language, platform, or development process, you will want to buy a different book; it covers these topics in only the broadest sense.
My only gripes are minor: first, there are a surprising amount of typos. Second, the book tends to drag when Seibel does more of the talking than the interviewee. Thankfully, this doesn't happen often.
Ultimately, it is a good collection of opinions and war stories which will broaden your perspective towards code and people who write it.