131–140 of 156 posts
K&R's _C Programming Language_, because my father saw me start to write Schrodinger's equation in BASIC and said I should take a look. Stroustrup's _The C++ Programming Language_, twice in a row, because I didn't want to be left out for not having taken Computer Science. Butelhof's _Programming with Posix Threads_, because another book referenced its explanation of why Win32 threading had a bug because it could not,…
These had high I-want-to-read-itosity, I thought:
Abelson and diSessa, Turtle Geometry
Abelson and Sussman, Structure and Interpretation of Computer Programs
Aho and Weinberger and Kernighan, The AWK Programming Language
Andrew Appel, Compiling With Continuations
Jon Bentley, More Programming Pearls
Jon Bentley, Programming Pearls
Leo Brodie, Thinking FORTH
W. H. Burge, Recursive Programming Techniques
Carriero and Gelernter, How to Write Parallel Programs
A. K. Dewdney, The New Turing Omnibus
Edsger Dijkstra, A Discipline of Programming
Richard Feynman, The Feynman Lectures on Computation
Friedman and Felleisen, The Little Schemer
Friedman and Wand and Haynes, Essentials of Programming Languages [1st edition]
James F. Gimpel, Algorithms in Snobol4
Paul Graham, On Lisp
Philip Greenspun, Philip and Alex's Guide to Web Publishing
Grune and Jacobs, Parsing Techniques: A Practical Guide
Daniel Hillis, The Connection Machine
Kernighan and Pike, The Practice of Programming
Kernighan and Pike, The Unix Programming Environment
Kernighan and Plauger, Software Tools in Pascal
Donald Knuth, Literate Programming
Glenn Krasner (editor), Smalltalk-80: Bits of History, Words of Advice
Susan Lammers, Programmers at Work
Wm Leler, Constraint Programming Languages
Liskov and Guttag, Abstraction and Specification in Program Development
Peter Norvig, Paradigms of Artificial Intelligence Programming
Chris Okasaki, Purely Functional Data Structures
Richard O'Keefe, The Craft of Prolog
P. J. Plauger, Programming on Purpose I. (and II and III)
P. J. Plauger, The Standard C Library
Jef Raskin, The Humane Interface
Stuart Russell and Peter Norvig, Artificial Intelligence: A Modern Approach
Toby Segaran, Programming Collective Intelligence
Toffoli and Margolus, Cellular Automata Machines
Niklaus Wirth, Project Oberon: The Design of an Operating System and Compiler
Witten, Moffat, & Bell, Managing Gigabytes
(mostly from my old list at http://wry.me/~darius/personal/books.html)Programming books are rarely page turners. I cannot think of one book to add to the (currently empty) list here. I find most programming books to be boring and discursive. Far too many fall into a pattern not too far removed from romance novels where, inevitably, the alpha male hero beds the heroine by chapter three. And if software engineering is considered programming, many of those books seem to be anchored in the…
> I find most programming books to be boring and discursive. I was of the same opinion until I read "Programming Pearls" by Jon bentley. The way it opens up a problem statement, thereby making you think is truly fascinating. If you haven't read it, please do.
His 1982 book, Writing Efficient Programs, and the 1981 precursor, Writing Efficient Code, ought to be read by every C programmer. Sadly, they are now out of print and hard to find. Writing Efficient Programs is a breezy tour of the tricks of the trade, but it is a serious list of hints (some subtle, some not) for making efficient programs.
I tend to get too distracted to give many books the cover-to-cover treatment. Some great ones that made the cut were: 1) Metaprogramming Ruby. 2) The Art of Rails. 3) Ruby Design Patterns 4) Services-Oriented Architecture in Ruby These stick out for me. Even if the last one in the list felt a little "rushed to production", it still covered important topics you won't find anywhere else. Plus I find when a book has typ…
> Plus I find when a book has typos (either in the text or in the code), that just makes me engage with it a little bit more. Really? I wasted almost an hour double-checking my code due to a typo in an algorithm in _Programming Collective Intelligence_ (pg. 35, should end in "return num/den", not "return 1.0-num/den".) That's just sloppy. I added it to the errata page ( http://oreilly.com/catalog/errataunconfirmed.cs…
Reposting a dead post which should not have been dead, from abecedarius: These had high I-want-to-read-itosity, I thought: Abelson and diSessa, Turtle Geometry Abelson and Sussman, Structure and Interpretation of Computer Programs Aho and Weinberger and Kernighan, The AWK Programming Language Andrew Appel, Compiling With Continuations Jon Bentley, More Programming Pearls Jon Bentley, Programming Pearls Leo Brodie, Th…
Skipping stuff commented on elsewhere:
While _The New Turing Omnibus_ is probably nothing too surprising to people here (at least not the subset that also hangs out on LtU, etc.), it's got a lot of approachable 2-5 page summaries of many major topics in CS.
_The Craft of Prolog_ is quite good, though perhaps of less interest to non-Prologers. _The Art of Prolog_ is essential, however. It's an SICP-caliber book, focused entirely on declarative programming, constraint programming, DSLs, etc.
_Compiling with Continuations_ rocks. It's an ML treatment of CPS-as-an-IR, like Steele's _RABBIT_ and Krantz et al.'s _Orbit_.
Earlier quoted context omitted.
I laughed out loud at the attribution asterisks in _The Art of the Interpreter_. Excellent to see humor in an academic paper.
I always crack up at GLS's joke whenever I see the word "fellow". There is something like "Gerry Susman is a research fellow at MIT. Guy Steele is a jolly good fellow".
Earlier quoted context omitted.
> Plus I find when a book has typos (either in the text or in the code), that just makes me engage with it a little bit more. Really? I wasted almost an hour double-checking my code due to a typo in an algorithm in _Programming Collective Intelligence_ (pg. 35, should end in "return num/den", not "return 1.0-num/den".) That's just sloppy. I added it to the errata page ( http://oreilly.com/catalog/errataunconfirmed.cs…
Some typos are okay, but in some cases there obviously can be too many.
I don't understand your "makes me engage with it a little bit more" reaction, though. I really don't. Could you explain?
"Coders at Work" is very well written and flows like a good novel. You must be a real hardcore hacker to enjoy it, though :) [Edit: I've actually posted a short review of it after I finished reading it - http://eli.thegreenplace.net/2010/01/09/book-review-coders-a... ]
I finished reading this today, really enjoyable book, very insightful and often thought provoking - it's nice to hear topics from people who have differing perspectives. Not sure what you mean by hardcore hacker though, unless you mean....most of the programmers in the book come from an era where assembly code and primitive machines were the only tools they had?
I found the part about L. Peter Deutsch (mostly) giving up programming for music particularly interesting.
At first I didn't think I had any, so I did a quick scan of my bookshelves: _Anatomy of LISP_. I also did SiCP cover to cover in a few months when it first came out. _SmallTalk 80: Bits of History, Words of Advice_. Fantastic stuff; reading about making those early 80s processors run ST efficiently is like watching early rocketry. _The Unix Programming Environment_. This should date me. _Threaded Interpretive Languag…
Have you read Lisp in Small Pieces? How does Anatomy of Lisp compare? I have TUPE too (and I was born in '82).
Earlier quoted context omitted.
Have you read Lisp in Small Pieces? How does Anatomy of Lisp compare? I have TUPE too (and I was born in '82).
AoL is better written -- I found both his prose and his code style more inviting -- but much more dated than LiSP. That I liked it better has more to do with not already knowing most of it, the way I did with LiSP. If you can pick it up cheaply, do, at least for history and entertainment.