What Is the Most Influential Programming Book? 624
First time accepted submitter AlexDomo writes "If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be? Since it was first posed back in 2008, this question has now become the second most popular question of all time on StackOverflow. The top 5 results are: Code Complete (2nd Edition), The Pragmatic Programmer: From Journeyman to Master, Structure and Interpretation of Computer Programs, The C Programming Language, and Introduction to Algorithms."
Deitel & Deitel (Score:4, Insightful)
'nuff said
Re: (Score:3, Interesting)
Charles Petzold.
Programming Windows, First Edition
http://www.charlespetzold.com/pw5/ProgWinEditions.html [charlespetzold.com]
Sad. But TRUE!
Re: (Score:2)
Re: (Score:3)
The first edition predates Win95 by... a lot. I remember reading it in 1988.
Petzold's problem is also its strength: It teaches the Windows API extremely well, but requires that you already be a good programmer with good taste, otherwise all the API isn't all you'll learn. You'll also learn a lot of bad habits.
C++ version (Score:2)
That would be my #1 choice. I've read most of the CS classics, and they're good. But I really *got* programming after reading Deitel's C++ textbook from cover-to-cover attempting at least half the exercises.
Petzold's Programming Windows comes second place.
Followed by Knuth's 2nd installation.
No (Score:5, Insightful)
Honestly, those are terrible books. If nothing else the signal-to-noise ratio is extremely disproportionate. I mean there are nuggets of good information in the books, but a 1100+ page language tutorial is unnecessary. It would be a stretch to call the series programming books -- let alone "influential" programming books.
Re:No Indeed good sir (Score:5, Insightful)
Agreed, a little known book for C++ from the ground up. Is an extremely well organized book "Starting Out With C++" by Gaddis. Dietel and Dietel C++ is manageable but its a thicket of information that makes it tough for some (I have gone through Deitel C++ and Dietel Java). There are a thousand books on C++ and probably a thousand squared number of paths to learning C++. Whatever your C++ journey, have fun!
The C classic is wonderful The C Programming Language Brian Kernighan and Dennis Ritchie.
Knuth is computer philosophy. Makes your soul shine. Treat it like philosophy, read it at leisure and think hard about every word on every page.
Bah! Pretenders! (Score:5, Informative)
Everyone knows it: Knuth's "The Art of Computer Programming"
Now get off my lawn!
Re: (Score:2)
Damn straight. You beat me to it.
Re: (Score:2)
Got the first three volumes as a HS graduation present from my parents. Don't use it as much as I should, but that's because I'm not a programmer anymore.
Re:Bah! Pretenders! (Score:5, Insightful)
The only CS book where 99% of the people touting it have never read it!
Re:Bah! Pretenders! (Score:4, Interesting)
"Classic: a book which people praise, but don't read." - Mark Twain
I guess he meant it with regards to classic literature. It seems extendable to classics in other art fields, and classics in technical fields too I suppose
Re: (Score:3)
If you already can program Knuth is surely worth reading. But if you are a beginner, then simply don't.
I really would not fancy a guy who is applying for a job and his example code consists of 30 lines where every variable just named with one letter. Even if he points out: oh but that is how Knuth does it ;D
BBC Micro User Guide (Score:5, Funny)
And yet, for others of us, it was our starting book back in the 80's.
More realistically I think for my generation in the UK, this [kaserver5.org] was our starting book. But in mitigation, expecting six year olds to read Knuth might have been a bit much!
Re: (Score:2, Interesting)
TAOCP is only useful for college students who want to look smart in the eyes of their clueless classmates.
In reality, it's terrible from a didactic standpoint. MIX is an impractical and verbose language, and an overall horrible way to explain algorithms to any audience. TAOCP is only interesting for the exercises, which most people will ignore for being too difficult to be solved during a casual read.
The only reason this book makes Top N lists is because people are intimidated by it, and peer pressure preve
Re: (Score:3)
This does not make *any* sense, unless Knuth was trying to troll generations of students who were too insecure to admit they couldn't understand MIX.
So Knuth is kinda like the L. Ron Hubbard of Computer Science?
Re:Bah! Pretenders! (Score:5, Insightful)
Re:Bah! Pretenders! (Score:4, Insightful)
Re:Bah! Pretenders! (Score:4, Informative)
You're totally wrong about goto statements [kerneltrap.org].
The C programming language (Score:4, Insightful)
Re: (Score:2)
First edition, K&R. None of this ANSI standard stuff.
http://en.wikipedia.org/wiki/The_C_Programming_Language [wikipedia.org]
Re: (Score:3)
Some of us keep both the Old Testament & the New Testament on our desks
Re: (Score:2)
I prefer to think of them as the King James and New International Version. Sometimes, though, you have to go back to the original TeX manuscripts and do your own rendering.
The One Book All Coders Should Read (Score:5, Insightful)
Is Fred Brook's "The Mythical Man-Month".
Re: (Score:3)
I thought about this one as well but I decided not to post because TMMM is really about program management, not programming, per se. Still, it is a fabulous book that every engineer and manager should read, study, and practice.
It is about programming (Score:2)
I thought about this one as well but I decided not to post because TMMM is really about program management, not programming, per se.
It's about programming in the sense that it helps you recognize when you are entering a project that will spiral down, so you can avoid emotional attachment or get out if possible.
And from the other angle if many developers have read it they can help steer the project away from that course early.
Re: (Score:3, Insightful)
The biggest problem with MMM is that software developers and architects are the only people who read it. Managers, especially "non technical" project managers have never heard of it, and won't bother to read it and they are the ones who would benefit from it the most.
Re: (Score:2)
I've read it. It was also in the top 10 in the full article.
Re:The One Book All Coders Should Read (Score:4, Insightful)
Gang of Four (Score:2)
Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software [wikipedia.org].
There's also this ruby-flavored version, and since I've been on a ruby kick for quite some time now, I devoured it within a couple of days. It's called Design Patterns in Ruby [designpatternsinruby.com].
Hope somebody hasn't heard of these, they'll get a damn good read (or, two, if you take on both). Although for the majority of Slashdot, I'd be really surprised if this recommendation doesn't come from a million people. The original GoF made
Re: (Score:2)
Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software [wikipedia.org].
I was going to mention Design Patterns too, but you beat me to it. I second the vote. Along with The C Programming Language and Advanced Programming in the UNIX Environment one of the best programming books I've ever read.
Re: (Score:2)
Re:Gang of Four (Score:5, Insightful)
Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software [wikipedia.org].
That book may be considered a classic but is one of the poorest presentations of material I've ever seen to recommend to a beginner. It works better as a reference but even then thinking in those terms has a tendency to make you over engineer every damn thing unless you actively apply the KISS principle. A lot of the patterns covered are best shown to newbies with concrete examples rather than in generic theoretical form.
Re: (Score:3)
That book may be considered a classic but is one of the poorest presentations of material I've ever seen to recommend to a beginner. It works better as a reference but even then thinking in those terms has a tendency to make you over engineer every damn thing unless you actively apply the KISS principle. A lot of the patterns covered are best shown to newbies with concrete examples rather than in generic theoretical form.
That's why I always recommend Head First Design Patterns [amazon.co.uk] (O'Reilly) to everyone. It has a great practical approach to teaching patterns, e.g. by starting with real world bad code, showing what's wrong with it, and then refactoring to a design pattern.
Re:Gang of Four (Score:5, Interesting)
The Gang of Four's book may be the most influential programming book, but it's probably done more harm than good. The patterns it describes fall into two categories: so painfully obvious that any programmer with more than a couple of months of experience should have invented them independently, or so obscure that you'll probably never find a real use for them. Unfortunately, once people have read it, they end up designing insanely overcomplicated systems that abuse patterns to death.
If you really want to understand design patterns, read some of Christopher Alexander's work, not the third-rate derivatives.
Re:Gang of Four (Score:4, Insightful)
I agree that most seasoned programmers have already used most of the design patterns themselves. The value of the book is to give names to those patterns, to aid in communicating design and intent within a team of programmers. The very act of labeling gives these things a concrete boundary instead of just nebulous knowledge mixed in inside programmers' heads. The boundaries established also allow analyzing the scope and robustness of the patterns in isolation.
Re: (Score:2)
At least the C++ community saw it for the bullshit that it is. While they went somewhat template-crazy at times, at least they managed to avoid the sheer stupidity of "design patterns", for the most part. That's probably why most real software today is written in C++.
Ouch. So you're one of those then eh. I love how you say the C++ community saw it for the bullshit that it was, but then leave out the part where there have been hundreds of books published that relate the GoF patterns to C++. But then, I guess the Java community probably wrote those books too.
Software Tools by Kernighan and Plauger, 1976 (Score:2)
The correct order (Score:5, Interesting)
The correct order should be:
I am sure that The Art of Computer Programming Volume 5 [stanford.edu] by D.Knuth will be next on the list. I have seriously been counting the years to the estimated 2020.
I only regret that Gerry Sussman hasn't written more books and hasn't recorded more talks. I will buy everything he writes and I will listen to everything he says. Please, Gerry! If you read this then please drop everything you do and just start talking to the camera. I have watched your every talk and lecture that I could possibly find on the Internet many times - from the 1986 lectures at MIT to your lecture on mechanical watches. I seriously believe that everything you say should be recorded for future generations. I don't know anyone else who can talk about anything at all and I listen breathlessly like I was hypnotized. I'm sure that many people here could say the same. Let this be an open letter to Gerald Jay Sussman: Please write more books and please record more lectures for the sake of the future of computer science. And thank you for your outstanding contribution that you have made so far. It is something that has shaped literally generations of passionate enthusiasts of programming. Thank you.
Re: (Score:3)
It's a good list but I feel like you shouldn't have operating system design over TAOCP, most programmers are operating at a level of abstraction these days over the base operating system in a way that makes that knowledge less valuable.
Re: (Score:3)
For instance, the Pragmatic Programmer has some interesting topic, and has been promoted to death, but I found The Practice of Programming to be much more instructive. It might be because of Brian Kernighan, or my belief that Addison-Wesley puts out the most rigorous computer books(O'Reilly is quick and dirty), but I found it a much more compelling read.
Code Co
Most influential on me... (Score:5, Interesting)
John von Neumann: Theory of self-reproducing automata, 1966
Learning Perl (Score:2)
Re: (Score:2)
The Art of Unix Programming (Score:3, Insightful)
http://catb.org/~esr/writings/taoup/ [catb.org]
Re: (Score:2)
A better one is The UNIX-HATERS Handbook (http://simson.net/ref/ugh.pdf). Until you realize how terrible[1] Unix is, any program you write is suspect.
[1]: Yes, like most folks here, I use Unix-like systems almost exclusively. Donald A Norman sums it up well in the Foreward: "A horrible system, except that all the other commercial offerings are even worse."
Re: (Score:3)
Code Complete (Score:3)
This went a long way towards making me better at programming larger, non-academic-assignment programs.
IPC in UNIX: The Nooks and Crannies (Score:2)
The value of book largely depends on your skills at the time... "Code Complete" was pretty good, but you need to be already an adept programmer to see the value of its advice.
I really wish I had read "Interprocess Communications in UNIX: The Nooks and Crannies (2nd Edition)" earlier. It's not the thickest book but it is the most information dense one I own. In today's environment of multicore and SMT CPUs, any programmer should have a deep understanding of IPC. An excellent partner to a good C book.
K&R C (Score:5, Insightful)
The C Programming Language [wikipedia.org] by Kernighan and Ritchie (popularly known as "K&R") is certainly, objectively (puns intended), and probably demonstrably, the most influential programming book. It was a strong, probably primary, influence on every one of the titles suggested in this story. Indeed, it is something like the "ur-text [wikipedia.org]" of modern programming - the vast majority of all programming, since it was first published in 1978. It has influenced programs, programmers and programming books. The influence dependency tree of programming books revolves around K&R.
I say this despite (or perhaps as demonstrated by) the K&R block brace style, which I abhor. It saves a line to destroy column coherence. And despite popularizing the unitary "var++" (eg. in for() loops), rather than the semantically more consistent "++var". And a hundred other quirks Kernighan and Ritchie infected into programming (and programming books, and thereby programmers). The persistence of which is just part of the ample proof of K&R's paramount influence.
Re: (Score:2)
Re: (Score:3)
for (i = 0; i++; i 10)
is semantically the same as
for (i = 0; ++i; i 10)
period.
This has what K&R has brought us. Of course, the reason for this preference is that PDP-11 had postincrement addressing mode as well as pre-decrement. So you'll see more --foo than foo-- in old time code. For simple ints like the above, of course it doesn't matter one wit. But for looks like:
while (*src++ = *dst++) ;
you get much better code on a pdp-11 than the nearly similar:
*src = *dst;
while (*++src = *++dst);
because t
Re: (Score:3)
See, this is why C sucks and is wonderful at the same time.
There is no '=' missing. The assignment belongs in the conditional, and actually is the reason why it works.
In C, the value of an assignment statement is the value being assigned, so this expression copies the value at one location to another location (per the pointers src and dest) and increments both pointers. If the value is null (indicating th
Re: (Score:3, Funny)
Oh my god, I will go and hide for the rest of the month. I blame it all on python, lack of sleep and Fukushima. I have not used C for a year or two and now this happens. Damn. I must have caught this thinking-in-python disease.
Re: (Score:3)
"while (*src++ = *dst++) ;" is also missing an "=".
It has exactly as many "=" as it needs.
It's a way to code strcpy().
Re:K&R C (Score:4, Interesting)
Oh, and don't forget the abomination:
...and its mutant offspring...
IIRC, K later recanted and said that permissiveness (allowing "pointer to" to shack up with the symbol rather than type) was the biggest single mistake they made in the C syntax.
Re: (Score:2)
Re: (Score:2)
In spoken conversation, did they speak as succinctly as they wrote C? Or did they say articles and occasional runon sentences :)?
Did you ever hear them defend their braces style? Why not
foo()
{
bar();
}
? And why semicolons instead of periods? If only I had a time machine...
Re: (Score:3)
And why semicolons instead of periods?
I'd rather have neither; Python and Go got it right.
Re:K&R C (Score:4, Insightful)
I'd like the multiple weeks of my life back that python has cost me because of their whitespace as braces style when coworkers decided to mix tabs and spaces. Python's decision would be fine *if* they had decided that we must use exactly 1 tab, or exactly 4 spaces, or any other choice. Allowing arbitrary amounts/types of whitespace along with giving it semantic meaning was the biggest mistake in the history of programming languages, and renders the result unusable.
Re: (Score:3)
Again, even in 2.X it was a matter of running python with -t or -tt. You just needed to RTFM.
Re: (Score:3)
Use your imagination. You know what columns are, and what coherence is. And what K&R does to columns when you use braces their way, saving a line.
Or are you a compiler?
Re: (Score:3)
I know better than K&R (did). Of course, I have the benefit of over 30 years programming after their book was published, starting only a year prior; they had only a decade or less experience when they published, among a vastly smaller society of peers to argue with.
I won't like any language that requires a text editor more complex than notepad to generate readable code. Certainly not one that requires a post-processing indenter.
Demon Haunted World, Carl Sagan (Score:5, Interesting)
...so you can spot the BS and hysterical religion when some idiot consultant comes up with their new XXX driven development or Agile methodology, or tries to replace on perfectly good framework, set of design patterns or tools with a new one that promises to be the best thing since sliced bread.
But seriously I think it's important to start kids young. My first books were on Apple IIe BASIC. In those days BASIC was what a lot of kids had access to. I saw LOGO later. I wouldn't change that. I'd change the books and systems I tried to use as a teenager and young adult though - MFC and Windows coding was such a waste of time given where my career went. And I never got far.
Agree with the previous AC about Mythical Man Month. Love the classic idea of a manager who needs a baby to meet a 1 month deadline throwing 9 women at the problem instead of one woman for 9 months. But I think you can get the gist without reading a whole book about it.
K&R is iconic, but not a good beginner's book at all, and while it does cover some things in great depth it does leave plenty out and is well dated now. Worth reading, but not first. It's good for understanding how the guts of the machine work but as C has been in decline for some time some of today's new coders will likely never use it.
I've never actually read Code Complete, but it sounds like a good introduction to a lot of ideas if you've not done a degree.
Re: (Score:2)
The gist of MMM is not anywhere near what you say. Even if we just wanted to cover that single chapter, the points is not just that you can't add more people to speed up a process, but that adding more people to a late project make the project go even later.
And still you'd be missing at least two chapters that are at least equally as important:
-There Is No Silver Bullet
-Plan To Throw One Away
Which are what makes Brook's little green book timeless, despite how badly some other chapters have aged. This is why
If I could turn back time (Score:2)
If I could go back in time that far, I wouldn't be worried about telling myself to read some book, I would tell myself to buy MSFT stock in 1981, and Apple stock in 1983, and sell short in October '87 etc
K&R (Score:2)
K&R (Score:2)
K&R as far as long-lasting impact. But my sentimental favorite? Doug Cooper's "Oh! Pascal!" I still have a copy of it.
Z-80 Assembly manual (Score:3)
The most influential programming book I owned was the first one I owned: The Z-80 Assembly manual. That got me started on real programming. The TRS-80 may not have been a great machine compared to what we have now, but it was a great bare-bones-metal learning tool.
It's one not on the list (Score:3)
Re: (Score:3)
Hmm? Almost all the stories are about stupid stuff that happens because some genius thought they would be better off if they modified the laws.
IBM System/360 Principles of Operation (Score:3)
The book that started it all.
Re: (Score:2)
Re: (Score:2)
the Most Influential Programming Book? (Score:5, Funny)
Dianetics.
Re: (Score:3)
How about the bible? *ducks* :)
C64 related books (Score:2)
Namely, the C64 Programmer's Reference Guide, and more importantly, Machine Language for the C64 [...] by Jim Butterfield.
Oh! I know! I know! (Score:2)
For me it was: Choose your Own Adventure books (Score:5, Interesting)
How To Win Friends And Influence People - Carnagie (Score:4, Insightful)
In terms of success, people skills are more useful than programming skills.
Also in this regard... (Score:4, Informative)
http://www.amazon.com/Dating-Design-Patterns-Solveig-Haugland/dp/0974312002/ref=sr_1_1?ie=UTF8&qid=1315193378&sr=8-1 [amazon.com]
_Dating_ Design Patterns.
The UNIX Programming Environment (Score:2)
UNIX and Unix 4ever
Any high school geometry textbook (Score:2)
Design Patterns (Score:3)
For me it is the Design Patterns by the so-called Gang of Four.
http://en.wikipedia.org/wiki/Design_Patterns [wikipedia.org]
It may seem odd (Score:5, Interesting)
Knaster, "How to Write Macintosh Software" (Score:5, Interesting)
No, not very influential outside the Mac community, not all that influential within it. But the as posed here in Slashdot, "if you could go back in time," this is the one, and not because of what it had to say about the Mac, but because it is the only book I've ever read that truly accepts the idea of debugging. Every other book carries the implied notion that you should concentrate on writing bug-free software, and that a good programmer really ought to be able to do it.
About half of the book was devoted to debugging, and it is my personal surmise that the book was originally entitled "How to Debug Macintosh Software" and that the publishers made him change it. Some might charge that the way Mac software was at the time--A5 worlds, very little RAM to spare, and somewhat finicky memory management--writing Mac software intrinsically required more debugging than other environments. It doesn't matter.
What matters was that this is the only book I read that honestly and truly embraced debugging as a fundamental and legitimate part of the software development process.
Pleasantly Free of Trendy Process Related Titles (Score:3, Insightful)
It's nice to see the almost complete absence of any titles reflecting current "flavor of the month" development techniques. About the closest it gets is "Design Patterns", which I've not got the highest opinion of (for reasons I'll explain in a footnote) but which at least codified some common best practices in a way that they could be taught, rather than learned by trial and error.
Always been a bit bemused by "Code Complete". Read it (well, the first edition), enjoyed it, and thought it contained a lot of good stuff, but at the time I was perplexed by it being a Microsoft Press book. Seemed kinda like the Pope penning the definitive case for atheism.
Somewhat comforted to see The Dragon Book in there, even if it is in its newer edition. Think I've still got that one around. That, and the Hennessy and Patterson book "Computer Architecture: A Quantitative Approach". My edition's horribly out of date, but so am I..
(*) Big problem with design patterns is that there's a tendency to take them as Holy Scripture of some sort, and/or to unnecessarily squeeze algorithms into a given design pattern. However, the problem there doesn't really lie with the book, but with the reader (or the teacher of the course, I guess). "Design Patterns" strikes me as something that should be read after a decent level of programming ability has been reached and not before - there's a level of expertise required to know when using a pattern that'll make maintenance of the software a joy for all who touch the code, and when to just wing it. Too many people immediately jump in and conclude that they must use a Visitor pattern on each Decorator, except where there's a Mediator involved, in which case it's necessary to employ the Churning Curds and The Knot Of Fame, before finally employing The Clinging Creeper to either a Flyweight object for the Proxy, or an Abstract Singleton. Then they code it, and you end up with an exponential number of classes, several mutually inclusive interfaces, and a system so flexible that you have to embed a dedicated parser to make any use of it beyond initiating a single object.
No Assembler? (Score:4, Interesting)
No ASM programming?
Enjoy being useless when you need to work at the bare-metal level.
Also, enjoy being dog-ass slow and having boated code.
For a perfect example of why ASM rocks, see MenuetOS.
Starting Forth (Score:3, Insightful)
Starting Forth by Leo Brodie -- especially the "under the hood" chapter. Runner-up for me is the PostScript Language Tutorial and Cookbook. These books gave me whole news way of thinking about programming, which doesn't happen very often.
Norton, Duntemann, & Eckel (Score:3)
The books that first grounded me in the hard and software of computing were "Peter Norton's Guide to Programming the IBM PC", Jeff Duntemann's "Complete Turbo Pascal" and , and Bruce Eckel's "Using C++" and "Thinking in C++".
Each of these books are paragons of clear writing and thought, conveying much more than the rudiments of their topic -- the years of experience and practical perspective of each of the authors.
I began my software career reading these books (ca. 1985), eventually completing a formal MS in CS. Yet sometimes your greatest influences arise not from ivory towers but from the school of hard knocks.
The problem (Score:3)
The problem with choosing some of these books is that they won't make as much sense until you've had some programming experience.
On a tangent but most important (Score:3, Interesting)
Algorithms+DataStructures=Programs; Wirth (Score:3)
Algorithms + Data Structures = Programs by Niklaus Wirth
I read this book back in the late 1970's. (I was still in High School where we had time-shared access to a PDP/11-70 running RSTS/E. Programming was in Basic-Plus. To put this in perspective, this was the same time frame as the TRS-80, TI 99/4A, and Commodore PET!) Our SysOp at SPHS saw my voracious appetite for all things computing and STRONGLY encouraged me to get and read this book. (Thanks Mike!) But enough with the background!
This book made an indelible impression on me. It introduced different approaches to tackle problems (algorithms) and different ways of organizing the information I had available (data structures). But, most importantly, it encouraged me to iterate between the Data and the Code to find a reasonably optimal synthesis of the two.
Prior to this, my experience with data structures had been limited to "scalars" (integers, floating point, and some character strings) and multi-dimensional arrays. It was a real eye-opener to be exposed to structured records as well as linked lists and trees!
Similarly, my coding experience was limited to combinations of the usual control structures of sequences, conditional statements, looping, and subroutines/functions. Did I ever struggle trying to understand recursion!
Then, toss in a generous helping of structured programming and step-wise refinement. This single work completely transformed my perspective on programming, its challenges, and its promises... I was hooked for good!
Amazon Link [amazon.com]. Prentice-Hall 1975; ISBN 0-13-022418-9; 366 pages, 102 figures.
I later had the good fortune to read a number of the other books recommended here, K&R, TAOCP, Mythical Man Month, and I'd highly recommend those, as well. Nevertheless, I read Wirth's A+DS=P first, and it's made a world of difference in my life.
One underrated book... (Score:4, Informative)
For anyone doing OS and BIOS level programming on the PC in the DOS days (and not writing games), the "Peter Norton Programmer's Guide to the IBM PC & PS/2" was a great book for understanding BIOS and DOS calls.
Peter Norton was one of the visionaries of the IBM PC software days and the DOS versions of the Norton Utilities were a godsend for things like repairing a damaged floppy disk or doing low-level hex editing.
It wasnt until Norton sold his company to Symantec that the Norton product line became the piece of junk it is today.
Books? (Score:3)
I'm only a casual programmer - I've been doing it for the last 20+ years, I've used it in my career, there are schools still running on my code, and I've written any tool that I needed and couldn't find a decent utility for elsewhere. I don't consider it a serious pursuit for myself and write more games and one-off utilities than I do serious projects.
Listed in order, this is every physical "programming" book I've ever read in those 20+ years:
- ZX Spectrum BASIC manual
- INPUT series (from Marshal Cavendish)
- O'Reilly Java in a Nutshell (probably 2nd/3rd edition, I can't remember)
- O'Reilly Physics for Game Developers
- OpenGL Superbible, 4th edition
The first one got me programming all on its own. The second helped immensely and allowed me to get a rough grasp of things that I couldn't quite understand at that age. It also taught me how to break the problems down and generate code rather than just showing me how their code worked.
After those, I was writing games, utilities, network management tools, I removed the CD protection on my copies of Desert Strike using only MS DOS debug (but never distributed the code which was already out there anyway), contributing to open-source projects (everything from games to single-floppy-linux-distros), and basically able to write anything I needed given enough time and enthusiasm. Hell, I taught my own sixth-form (Year 12/13) classmates for two years because I understood programming better than my teachers.
Then, YEARS later, I read the Java book (because I was starting uni and they made a Java course compulsory and I just wanted a quick reference and that book was cheap - I never attended those programming lectures for two years after I'd got the hang of Java syntax in the first week, and passed them with flying colours - that was my first introduction to OO, even).
Again, YEARS after graduating, I read the physics one and didn't do a damn thing about it because I thought it was horrible, Windows- and even compiler-specific and physics was the only subject that I ever really "failed" (i.e. did terribly on, or actually failed) despite everyone telling me that I'd be good at it because I was good at maths. I binned it after a single reading - I knew exactly what it was trying to teach me but in terms of actually walking away knowing something, it was worthless.
And this year I read the OpenGL book because I thought I'd finally see what all the fuss was about (gaming for me is 2D - it's what I was brought up on, it's easier to program and do the art, and it's much less demanding and never really goes out of fashion - and I wanted to use OpenGL acceleration on my 2D games). That, admittedly, is one of the best "programming" books that I've ever read except they have a tendency to butcher previous versions for each iteration in order to keep it "up-to-date".
Now, I have a Maths & CS degree, I've run my own business in and worked in IT since graduating. I'm responsible for school systems and quite a bit of my own code makes that possible.
I've been exposed to Knuth, etc. but if you asked me what book I've give my younger-self, it would have to be the first two and the OpenGL one.
To me, learning programming isn't about the memorisation of coroutine techniques, but about the ability to formulate a problem into code and have the computer solve it. I don't think books can really teach that and I only use books, references and guides in order to learn the *syntax* of a language, or to learn about a particular technique (e.g. the matrix-operations that OpenGL performs are a wonderful insight into how something quite removed (conceptually) from computing can be formulated in a way which fits into a computing technique really well).
Until you actually sit and do it on a computer for a project you need yourself, you're just nodding along going "This is cool" with no knowledge of how practical is it to apply to a project (I've seen no end of people start a ten-line utility by writing flow-charts and a
I would never have read books like that... (Score:3)
Personally I started with "Inside ATARI Basic" by Bill Carris. It was a very fun read and was definitely aimed at kids and beginner adults. Unfortunately my walk through the book came to a screeching halt when trying to understand what FOR and NEXT did. The book explained that FOR and NEXT are like the two parts of an Oreo cookie, and the code in between them was like the cream in the middle. Mmmmm, Oreo cookies. Yum! But what does it actually do? No explanation at all. At that point I gave up on BASIC and moved to LOGO. It was only 5 years later that it was explained to me that FOR-NEXT was a loop structure, which is what broke the barriers for me and allowed me to move from BASIC to Assembly, then (much later on) on to Java, C and C++.
But I digress. My main point here is that nobody starts programming by reading Knuth cover to cover and then digging in, and that most of the "must read" and influential books on the subject make no sense to the beginner.
3 Books ... (Score:3)
I guess I learned the principles of programming from "Algorithms and Data Structures" by Niklaus Wirth.
I read "The Design and Evolution of C++" by Bjarne Stroustrup later, and buy understanding his design constraints and decissions he made I could forgive him for lot of the shit that I considerd a cluster fuck up in C++.
Most influenced I perhaps was by "Design Patterns. Elements of Reusable Object-Oriented Software" Erich Gamma, Richard Helm, Ralph E. Johnson and John Matthew Vlissides (+ 2005, R.I.P.)
I found it amazing to "name" larger "structures" in programming / design and/or architecture. I basically knew all those patterns because I was involved in oo framework development and research. But having some guys just grabbing them out of existing code, displaying them and giving them a name was very stunning for me.
Also the original edition of that book was excellent printed with sidenotes on the margines and graphical overviews in the inside of the book covers.
I guess I have roughly 50 computer science books ... which reminds me to get: "XUnit Test Patterns" by Gerard Meszaros, see: http://xunitpatterns.com/ [xunitpatterns.com] This is an excellent book about Software Testing.
Re: (Score:2)
More influential is CJ Date's [wikipedia.org] An Introduction to Database Systems. Many C and other structured programs have used numerical recipes or inspiration from NRiC, but all database systems written or revised since 1977 are directly (and indirectly) influenced by aItDS.
Though the most influential programming book overall [slashdot.org] is K&R.
Re: (Score:2)
My top 2: Numerical recipes in 'C', ...
Yep, that's an excellent example of how NOT to write numerical computations.
Re: (Score:2)