hn-classics/_stories/2009/4861323.md

423 lines
22 KiB
Markdown
Raw Normal View History

2018-02-23 18:19:40 +00:00
[Source](http://blog.fogus.me/2009/03/11/seven-books/ "Permalink to fogus: (Building) The 7 Books of a Highly Effective Programmer")
# fogus: (Building) The 7 Books of a Highly Effective Programmer
![][1]
[read][2]
![][3]
[read][4] or [learn more][5]
# [Send More Paramedics][6]
λ λ λ
[Fogus'][7] [Thoughts][8] on life, [programming][9], and [thinking][10]
![][11]
❤ [c][12] [clj][13] [erl][14] [factor][15] [frink][16] [hs][17] [js][18] [org][19] [pure][20] [rkt][21] [qi][22] ❤
Follow me on Twitter... ![][23] or RSS... ![][24]
Run this blog in [mobile][25]
[2018][26] [2017][27] [2016][28] [2015][29] [2014][30] [2013][31] [2012][32] [2011][33] [2010][34] [2009][35] [2008][36] [2007][37] [2006][38] [2005][39] [2004][40] [2003][41] [2002][42]
### [(Building) The 7 Books of a Highly Effective Programmer][43]
Mar 11, 2009
Like many programmers, Im always on the lookout for the perfect programming book. Over the years I have tried to [enumerate][44] a [few][45] key [examples][46], however after reading them all I am still left wanting. However, I recently came across a couple interesting blog posts [1][47] that motivated me that the only way to find the set of perfect books for programmers was to build them myself.
The process is simple:
1. Define the set of topics
2. Find the PDFs comprising the aggregate essays for each topic
3. Create a table of contents, forward, and write or steal a summary of each essay
4. Merge everything together
5. Go to [Lulu.com][48] and print a book [2][49]
6. Read the books
7. ???
8. Become a better programmer (i.e. profit)
> YOU, and NO ONE ELSE, is responsible for your career. — [Uncle Bob Martin][50]
# The Topics
After thinking about the possible topics that would be beneficial to my own enrichment (and to the programmer in general), I hit on the following seven:
1. Core
Things that every programmer should know and read about; taken mostly from [the list compiled by Michael Feathers][51] with some of my own additions.
2. The Lambda Papers
Including the original [Lambda Papers][52] and relevant essays pertaining to them and their topics.
3. Functional Programming
Topics concerning functional programming in general including, but not limited to: state, immutability, lambda calculus, purity, recursion, pattern matching, laziness, type systems, closure, anonymous functions, and currying.
4. Language Development
One way to learn more about developing new programming languages is to learn how other programming languages were created. This book would be similar to the previous two books except with a slant toward the more practical aspects of language development.
5. Object-oriented Design
While I am learning more and more [the virtues of functional programming][53], I still think that object-oriented programming has just as an important role as ever in software design and development.
6. Software Development Management
While my own brief foray into software development manager can only be described as a failure, I believe that the right person implementing the right management techniques can be as valuable as the greatest programmer that youve ever met.
7. Operating Systems Development
From web-based, to monolithic, to exo-kernel, to micro-kernels, there is a lot to be learned from the field of operating system development and their relationships to the underlying hardware; as long as I do not constrain myself to the [Von Neumann architechture][54].
8. Interviews and Anecdotes
What better way to become a better software developer and designer than to read about the art from the masters.
And that is it. I think that after crunching through the seven books outlined above, I should, at least minimally, be smarter than I was this time last year. Im always looking for suggestions and comments about my outline above. I do not want these books to be _my_ vision of the best, but instead I want them to be _the best_ available. In addition, I will likely discover new essays, code snippets, and interviews after books are created, so I will likely create an 8th or even 9th book to cover those.
To end this post, I present the table of contents and summary section [3][55] to Book 0: Core:
## Foreword
THE ORIGINS OF PATTERN THEORY THE FUTURE OF THE THEORY, AND THE GENERATION OF A LIVING WORLD Christopher Alexander
## Essays
1. On the Criteria to Be Used in Decomposing Systems Into Modules David Parnas
2. A Note On Distributed Computing Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
3. The Next 700 Programming Languages P. J. Landin
4. Can Programming Be Liberated from the von Neumann Style? John Backus
5. Reflections on Trusting Trust Ken Thompson
6. Lisp: Good News, Bad News, How to Win Big Richard Gabriel
7. An Experimental Evaluation of the Assumption of Independence in Multiversion Programming John Knight and Nancy Leveson
8. Arguments and Results James Noble
9. A Laboratory For Teaching Object-Oriented Thinking Kent Beck, Ward Cunningham
10. Programming as an Experience: the inspiration for Self David Ungar, Randall B. Smith
11. Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same Henry G. Baker
12. The Universal Design Pattern Steve Yegge
13. A Universal Modular Actor Formalism for Artificial Intelligence Carl Hewitt, Peter Bishop, Richard Steige
14. The Humble Programmer Edsger W. Dijkstra
15. Notes on Programming in C Robert Pike
16. Go To Statement Considered Harmful Edsger W. Dijkstra
17. Callbacks in C++ Using Template Functors Rich Hickey
18. What Every Computer Scientist Should Know About Floating-Point Arithmetic David Goldberg
19. Duffs Device Tom Duff
20. MATREX Data Collection and Analysis: Linking Simulation Results to Military Analyst Requirements Michael Fogus, Dave Prochnow, Kuan Penn, Howard Borum
**On the Criteria to Be Used in Decomposing Systems Into Modules Parnas**
This is a very old paper, but it is more than a classic. In in it, Parnas introduces a forerunner to the Single Responsibility Principle. He introduces the idea that we should use modularity to hide design decisions things which could change. People still don't consider this as often as they should.
Another thing I really like in the paper is his comment on the KWIC system which he used as an example. He mentioned that it would take a good programmer a week or two to code. Today, it would take practically no time at all. Thumbs up for improved skills and better tools. We have made progress.
**A Note On Distributed Computing Waldo, Wyant, Wollrath, Kendall**
Abstraction is great but it can only go so far. In this paper, the authors lay to rest what was once a pervasive myth that we could design a distributed system and make distribution transparent. Ever wonder why you had to implement specific interfaces to do remoting in Java? This is why.
In the aftermath it might seem hard to believe that people thought this was possible. I think we can we partially thank this paper for that.
**The Next 700 Programming Languages Landin**
Most of us have spent a lot of time working in traditional programming languages, but functional programming languages are slowly seeing an uptick and many OO languages are gaining functional features. This paper (which reads like a tutorial) makes an argument for an expression-oriented style of programming. It also lays the foundation for lazy evaluation.
One of the other neat things about this paper, from a historical point of view, is that there is a discussion section at the end in which there a number of questions and comments about whether making indentation significant in a language is a good idea. I was thrown to see people asking whether or not this would be a problem for functions which span over several pages(!).
**Can Programming Be Liberated from the von Neumann Style? Backus**
John Backus is known for a number of achievements in computer science. He received the ACM Turing Award for his work on Fortran. This paper, which he presented at the award ceremony was rather shocking at the time because it said, in essence, "we got it wrong." Backus took the opportunity to make a plea for pure functional programming. His arguments were convincing and they helped to set a research agenda which is just now starting to make some waves in the mainstream.
**Reflections on Trusting Trust Thompson**
I once heard that when this paper was presented, people in attendance rushed back to de-compile their C compilers and look for, er, problems. This paper unveiled a hard problem at the heart of computer security. If you've spent any time at all thinking about security, you need to read it.
**Lisp: Good News, Bad News, How to Win Big Gabriel**
This paper is a bit atypical in this list. It's aimed at the Lisp community and it comes off as a bit of a lament. But, hidden deep within it is the Gabriel's description of the 'Worse is Better' philosophy an idea with profound implications for the acceptance and spread of technology.
**An Experimental Evaluation of the Assumption of Independence in Multiversion Programming John Knight and Nancy Leveson**
Behind this dry title lies something very interesting. I first heard about this paper from Ralph Johnson in a newsgroup discussion about program correctness. It turns out that one of the avenues that engineers in other disciplines take to make their products stronger redundancy doesn't really work in software. Multi-version programming was the idea that you could decrease faults in critical systems by handing the spec to several teams, having them develop the software independently, and then having the systems run in parallel. A monitoring process verifies their results and if there is any discrepancy it picks the most common result. Sounds like it should work, right? Well..
**Arguments and Results Noble**
I think that all of the other papers in this list are rather well known in some circles. This one isn't, or if it is, I just haven't found that circle yet. What I like about this paper is that it takes something which we deal with every day the set of arguments and results of functions and it works them through a series of variations which just don't occur to many people. The fact is, every function that you work with has a number of possible directions if could evolve in. Not all of them are appropriate, but if you know the possible directions, you're richer for it.
**A Laboratory For Teaching Object-Oriented Thinking Beck, Cunningham**
There are an incredible number of papers about there about object orientation. The thing which makes this one great is its directness. OO went through a number of stages. It was once fresh and novel, then it was ornate, and then it became matter-of-fact. This paper hits upon key ideas which many people don't talk about much any more: anthropomorphism and dropping the top/down perspective. It also shows you how you can design with index cards. It may not sound cool but it is incredibly effective.
**Programming as an Experience: the inspiration for Self Ungar, Smith**
How many people know about the Self Project? Not enough in my opinion. Self was an attempt to take two ideas in computing and push them as far as humanly possible. The first was minimalism: the Self programming language was thoroughly in the Lisp and Smalltalk vein everything was defined in terms of the smallest number of primitives possible. The other idea was direct manipulation the idea that the object metaphor could be pushed all the way in the user interface the programmer and user sit with a mouse in a sea of directly clickable objects and use them for everything. If they could've gotten away with dropping the keyboard, I think they would've.
The amount of technology which the Self project threw off is terrifying also. Self broke ground in dynamic language optimization and VM design. Chances are, your VM uses technology it pioneered. It's also one of the more perverse ironies that the most widely distributed programming language today (JavaScript) is a prototype-based programming language which borrowed ideas from the hyper-research-y Self.
**Equal Rights for Functional Objects or, The More Things Change, The More They Are the Same Baker**
Baker describes the egal predicate which is used to recursively compare functionally persistent objects.
**The Universal Design Pattern Yegge**
Yegge describes the Universal Design Pattern which, in a nutshell, mirrors the classical Properties Design Pattern with an added pointer to the parent object. Yegge describes methods of providing an inheritance mechanism similar to prototypal inheritance.
**A Universal Modular Actor Formalism for Artificial Intelligence Hewitt**
With the recent emergence of the Erlang programming languages Actor-based event model, the ideas created by Hewitt, et al. become increasingly important. The Actor model has been the guiding motivation for many important programming languages, including, but not limited to, Scheme and the aforementioned Erlang.
**The Humble Programmer Edsger W. Dijkstra**
In a nutshell, most of programming design is done in an attempt to compensate for our lack of intelligence. Those programmers who are at the bottom of the competency pyramid refuse to recognize this fact are doomed to remain subpar. The way to enlightenment and improvement is by recognizing our limitations and proceeding with a level of humility.
**Notes on Programming in C Pike**
Pikes Notes on Programming in C provides approaches to design and implementation applicable to every project, be they C or not.
**Go To Statement Considered Harmful Dijkstra**
The classic text denouncing the goto construct is largely moot today, but it is an essential read for the thoughts on structured programming by a true master.
**Callbacks in C++ Using Template Functors Rich Hickey**
The inclusion of this paper is questionable considering the groundbreaking essays surrounding it. However, it is an interesting (and rare) read from a thoughtful programmer currently making waves.
**What Every Computer Scientist Should Know About Floating-Point Arithmetic Goldberg**
This essay would not be included if the number of programs fraught with rounding errors was less than 10,000 per year. Programmers still do not understand floating point arithmetic (myself included; which I hope this will remedy).
**Duffs Device Duff**
Duffs Device is often held up as an example of the quintessential programming pearl. Combining a concise and clear implementation of a common programming problem with a deep understanding of the programming language (C), Duffs Device still has a lot to teach us.
**MATREX Data Collection and Analysis: Linking Simulation Results to Military Analyst Requirements Fogus**
My goal in this series is personal enrichment. Therefore, I would like to include one of my own essays as a way to offer a stark contrast between my own output and those of the true visionaries. My goal is not to offer my own essay as standing firm with those that come before it, but instead as an humbling afterward. Through the recognition of my shortcomings I hope to become a smarter designer and developer of software systems.
-m
* * *
1. The first was by [Michael Feathers entitled 10 Papers Every Programmer Should Read (At Least Twice)][51]) and the second by [Emmet Connolly entitled Instapaper (analogue edition)][56]. ↩
2. I have no idea what the copyright implications of this are, so I will be priting out only my own private copy and not making them available publically; but with a little bit of work you too can do the same. ↩
3. The summaries for #1-10 are taken verbatim from [Michael Feathers][51]. Please visit his site for the excellent commentary attached to the original post. ↩
### 16 Comments, [Comment][57] or [Ping][58]
1. [Gabriel Claramunt][59]
Youre missing one fundamental essay about the nature of software development: Frederick P. Brookss “No silver bullet”
[Jul 20th, 2009][60]
2. [fogus][61]
Gabriel,
Thank you for the comment, I will undoubtably put that essay in book #5. Software Development Management.
-m
[Jul 20th, 2009][62]
3. Eduardo
How about some books on algorithms? I think spending some time studying data structures and algorithms is one of the best investments a programmer can make.
[Dec 2nd, 2012][63]
4. [Dave Paola][64]
MIght I suggest “On Designing and Deploying Internet-Scale Services” by James Hamilton? <http://static.usenix.org/event/lisa07/tech/full_papers/hamilton/hamilton_html/>
[Dec 2nd, 2012][65]
5. Dave
What about “What every programmer should know about memory”
[Dec 2nd, 2012][66]
6. [Will Sargent][67]
Falsehoods programmers believe about names.
<http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/>
[Dec 2nd, 2012][68]
7. Markus Pfundstein
Hey Man. Thanks for sharing this! Keep going!
[Dec 3rd, 2012][69]
8. [Alan Shaw][70]
Putting my copy of Book 0 together now. Cant wait to hold it in my hands! Ive read some of these papers before but this is brilliant!
[Dec 3rd, 2012][71]
9. Chaim
Any progress on the other 6 books?
[Dec 3rd, 2012][72]
10. [fogus][61]
@Eduardo
I think a deeper study of algorithms and data structures would be a nice addition. Although Ive found the best sources to be books rather than papers, but Im willing to take suggestions if you have any.
[Dec 3rd, 2012][73]
11. [fogus][61]
@Chaim
Why yes. Maybe Ill write a follow-up one day. :-)
[Dec 3rd, 2012][74]
12. [fogus][61]
@Paola
Thank you for the link. Ive not read that but look forward to doing so soon.
[Dec 3rd, 2012][75]
13. Armen
any thoughts as to what a good list would be to a complete beginner?
[Dec 3rd, 2012][76]
14. [Alan Shaw][70]
The only one of these papers Ive been unable to find online is yours!
[Dec 3rd, 2012][77]
15. [fogus][78]
BTW, I **do not** recommend **my** paper. Instead, I recommend a paper or some writing of your own to use as a comparison, inspiration and perhaps as a healthy dose of humility compared to the writings surrounding it.
[Dec 3rd, 2012][79]
16. [Java Geek][80]
One of my favorite book on programming, pragmatic programmer echoed most of these ideas.
[Dec 8th, 2012][81]
### Reply to “(Building) The 7 Books of a Highly Effective Programmer”
Name (required)
Mail (required)
Website
Copyright © 2002 - 2011 by [Fogus][61] ([license information][82])
[_read about my policy on affiliate links][83]_
Theme heavily influenced by [Ryan Tomayko][84]
[ | [Log in][85] | [top][86]]
[1]: http://fogus.me/fpjs.jpg
[2]: http://www.amazon.com/Functional-JavaScript-Introducing-Programming-Underscore-js/dp/1449360726/?tag=fogus-20
[3]: http://fogus.me/joc.jpg
[4]: http://www.joyofclojure.com/buy
[5]: http://www.joyofclojure.com/
[6]: http://blog.fogus.me/
[7]: http://fogus.me/me/
[8]: http://fogus.me/static/
[9]: http://fogus.me/fun
[10]: http://blog.fogus.me/linkage/
[11]: http://fogus.me/images/addy.png
[12]: https://github.com/search?q=username%3Afogus+language%3Ac
[13]: https://github.com/search?q=username%3Afogus+language%3Aclojure
[14]: https://github.com/search?q=username%3Afogus+language%3Aerlang
[15]: http://factorcode.org
[16]: http://futureboy.us/frinkdocs/
[17]: https://github.com/search?q=username%3Afogus+language%3Ahaskell
[18]: https://github.com/search?q=username%3Afogus+language%3Ajavascript
[19]: http://orgmode.org/worg/org-contrib/babel/
[20]: http://code.google.com/p/pure-lang/
[21]: http://racket-lang.org/
[22]: http://shenlanguage.org
[23]: http://images.fogus.me/blog/twitter.png
[24]: http://images.fogus.me/blog/rss.png
[25]: http://blog.fogus.me/index.php?wptheme=Carrington+Mobile
[26]: http://blog.fogus.me/2018/
[27]: http://blog.fogus.me/2017/
[28]: http://blog.fogus.me/2016/
[29]: http://blog.fogus.me/2015/
[30]: http://blog.fogus.me/2014/
[31]: http://blog.fogus.me/2013/
[32]: http://blog.fogus.me/2012/
[33]: http://blog.fogus.me/2011/
[34]: http://blog.fogus.me/2010/
[35]: http://blog.fogus.me/2009/
[36]: http://blog.fogus.me/2008/
[37]: http://blog.fogus.me/2007/
[38]: http://blog.fogus.me/2006/
[39]: http://blog.fogus.me/2005/
[40]: http://blog.fogus.me/2004/
[41]: http://blog.fogus.me/2003/
[42]: http://blog.fogus.me/2002/
[43]: http://blog.fogus.me/2009/03/11/seven-books/ "(Building) The 7 Books of a Highly Effective Programmer"
[44]: http://blog.fogus.me/2004/07/08/242/
[45]: http://blog.fogus.me/2005/03/28/essential-unix-programming-books/
[46]: http://blog.fogus.me/2004/04/04/195/
[47]: http://blog.fogus.me#fn%3Amotivation
[48]: http://lulu.com
[49]: http://blog.fogus.me#fn%3Acopyright
[50]: http://blog.objectmentor.com/articles/2009/02/27/whiners-that-fail
[51]: http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-programmer-should-read-at-least-twice
[52]: http://library.readscheme.org/page1.html
[53]: http://blog.fogus.me/tag/clojure,scala,haskell,lisp,onlisp/
[54]: http://en.wikipedia.org/wiki/Von_Neumann_architecture
[55]: http://blog.fogus.me#fn%3Asummaries
[56]: http://blog.thoughtwax.com/2009/03/instapaper-analogue-edition
[57]: http://blog.fogus.me#respond "Leave a comment"
[58]: http://blog.fogus.me/2009/03/11/seven-books/trackback/
[59]: http://gabrielsw.blogspot.com
[60]: http://blog.fogus.me#comment-9393 "Comment Permalink"
[61]: http://fogus.me
[62]: http://blog.fogus.me#comment-9395 "Comment Permalink"
[63]: http://blog.fogus.me#comment-88667 "Comment Permalink"
[64]: http://davezor.net
[65]: http://blog.fogus.me#comment-88676 "Comment Permalink"
[66]: http://blog.fogus.me#comment-88700 "Comment Permalink"
[67]: https://tersesystems.com
[68]: http://blog.fogus.me#comment-88731 "Comment Permalink"
[69]: http://blog.fogus.me#comment-88866 "Comment Permalink"
[70]: http://nodename.com
[71]: http://blog.fogus.me#comment-88875 "Comment Permalink"
[72]: http://blog.fogus.me#comment-88881 "Comment Permalink"
[73]: http://blog.fogus.me#comment-88975 "Comment Permalink"
[74]: http://blog.fogus.me#comment-88976 "Comment Permalink"
[75]: http://blog.fogus.me#comment-88979 "Comment Permalink"
[76]: http://blog.fogus.me#comment-89013 "Comment Permalink"
[77]: http://blog.fogus.me#comment-89127 "Comment Permalink"
[78]: http://www.fogus.me
[79]: http://blog.fogus.me#comment-89141 "Comment Permalink"
[80]: http://java67.blogspot.ca
[81]: http://blog.fogus.me#comment-90986 "Comment Permalink"
[82]: http://creativecommons.org/licenses/by-sa/2.5/
[83]: http://blog.fogus.me/about/mo-money/
[84]: http://tomayko.com
[85]: http://blog.fogus.me/wp-login.php
[86]: http://blog.fogus.me#top "Return to the top"