Slashdot Mirror
What Is the Most Influential Programming Book?
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."
'nuff said
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
Sam Publishing's Teach Yourself C++ In 21 days was a teenage "favorite" of mine.
Everyone knows it: Knuth's "The Art of Computer Programming"
Now get off my lawn!
Bent, folded, spindled, and mutilated.
by k and r
Is Fred Brook's "The Mythical Man-Month".
Great book on design patterns, Design Patterns: Elements of Reusable Object-Oriented Software.
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.
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 it around quite a bit.
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
This book shows how to build software tools to bootstrap from a crummy environment (FORTRAN on IBM 370) to a much more productive environment. Stop whining, get coding, build tools. Expounds on tool pipelines based on Unix pipes. .
The correct order should be:
I am sure that The Art of Computer Programming Volume 5 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.
Karma: Positive (probably because of superiour intellect)
John von Neumann: Theory of self-reproducing automata, 1966
There you are, staring at me again.
Great starter book for non-cs types.
http://catb.org/~esr/writings/taoup/
...a stunned silence fell upon the hall.
This went a long way towards making me better at programming larger, non-academic-assignment programs.
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.
The C Programming Language 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" 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.
--
make install -not war
...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.
These posts express my own personal views, not those of my employer
The Design and Evolution of C++ by Bjarne Stroustrup
http://www.amazon.com/Design-Evolution-C-Bjarne-Stroustrup/dp/0201543303
This is the book that turned me into a grown up in the world of computer languages. It is the book that brought unparalleled insight and wisdom into every other computer language book, discussion about computer languages, or actual real world use of computer languages since reading.
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
More influential is CJ Date's 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 is K&R.
--
make install -not war
Next question?
K&R as far as long-lasting impact. But my sentimental favorite? Doug Cooper's "Oh! Pascal!" I still have a copy of it.
"Here's what's happening. You're starting to drive like your Dad..." - Red Green
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.
I do not fail; I succeed at finding out what does not work.
It's "I, Robot" from Isaac Asimov. How many read that book early on and thought "I can do better than those three rules"...
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
The book that started it all.
You kidding? You don't even need to go that far back to rake in dough on stocks.
Wish I was paying attention to things when Google came around..
vos nescitis quicquam, nec cogitatis quia expedit nobis ut unus moriatur homo pro populo et non tota gens pereat.
My top 2: Numerical recipes in 'C', ...
Yep, that's an excellent example of how NOT to write numerical computations.
Strange. 10 years ago I used to get my news from slashdot first. Now, not so much anymore. This list is pretty exhaustive and has more backing than I expect you'd find anywhere else, including here: http://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read
Dianetics.
I have mod points and I am not afraid to use them.
Namely, the C64 Programmer's Reference Guide, and more importantly, Machine Language for the C64 [...] by Jim Butterfield.
Damn straight. You beat me to it.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
The one you read? As opposed to hollow out to keep a flask of scotch in it?
Mostly random stuff.
I never read any programming book that has helped me significantly. But I remember copying code from magazines on a TI-99 before I knew how to do multiplication. I just copied the code one line at a time, and it either ran or didn't. The best thing I could do was print rockets. I didn't understand anything until I was 12 and got the IF-THEN statement. Once I had that, I was able to write branching games similar to my Choose your Own Adventure Books. After that the world was wide open.
God spoke to me
In terms of success, people skills are more useful than programming skills.
Words to men, as air to birds.
If you haven't read this you're missing out. It's the "why" that you won't find in a mere programming book. They all focus on the "how". It really opened my eyes, and I give a copy to every person that interns with me to read. http://www.amazon.com/UNIX-Philosophy-Mike-Gancarz/dp/1555581234
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.
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.
The only CS book where 99% of the people touting it have never read it!
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.
You'll have that sometimes...
Comment removed based on user account deletion
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 prevents them from treating it like the mess that it is.
UNIX and Unix 4ever
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Seriously, doing proofs taught me more about logic and algorithm and problem solving than anything else. But yeah, also K&R.
In terms of success, people skills are more useful than programming skills.
I completely agree with you. It's nice to see someone contribute to this discussion who is so clever and intelligent.
Clever, intelligent, and handsome -if I might say so.
For me it is the Design Patterns by the so-called Gang of Four.
http://en.wikipedia.org/wiki/Design_Patterns
My first computer was a Commodore 64 and I learned programming and general computer use on that, and most stuff was either Basic or Machine Language on that. When I got an XT and wanted to learn programming, I looked at both Turbo C and Turbo Basic in the local Radio Shack store (they were side by side on the shelf and exactly the same price, as I recall) and bought Turbo Basic because I figured I knew a bit more about Basic and it would be easier to get started doing things.
In hindsight I should have bought and learned Turbo C instead. I got to be pretty darn good with Basic programming and wrote some cool stuff with Turbo Basic (including some "shareware" that made a pretty decent buck for a while), but some years later I discovered two things:
1. C wasn't very hard to learn; in fact it took me less time to "get started" with C than it did when I started learning Basic programming on the XT.
2. I could do some cool stuff with Basic but similar stuff could be done more easily and directly with C. In other words, stuff that required a lot of "bending" in Basic could just be done in C without much fuss at all.
So in hindsight, I wish I had read the Turbo C Reference Manual when I first got my XT.
If you're a zombie and you know it, bite your friend!
I would say you would have to have 3 separate categories for this particular award:
1. Best computer science/algorithms book
Here I like MITs Introduction to Algorithms book and of course, Dr. Knuths tomes
2. Best programming(as in turning algorithms and ideas into computer code) book:
I am partial to Peter Van Der Lindens work, but thats just me.
3. Best book about computing in the "real world"
My vote goes to Mythical Man Month.
Monstar L
MIX was intentionally problematic to avoid dependencies on platform assumptions that might not be portable -- a questionable tactic, but it was intentional. For the rest, it's a valuable reference (I've used it since college), but not really didactic.
Quidnam Latine loqui modo coepi?
No different from any other slashdot poll.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
I don't remember any of the book titles, but I do remember borrowing many BASIC books from the local library, entering all the sample code into GWBASIC and then playing around with it to see what I could make it do. I suppose if I'd never found those books I probably would never have gotten into computer programming.
After that there weren't really any books; when I moved onto Pascal I learnt from some tutorials I found on a BBS, then I learnt C from internet guides and Java from university. Who reads books anymore when all the information you really need to learn this stuff is on the internet, easily locatable via Google?
the first 'programming books' that i read were "family and home office computing magazine", typing shit into a ti-99/4a.
then there were the kids programming books with simple ass little projects.
later on, there was Babbage's , and the giant purple MSDOS book by Microsoft that nobody remembers
then the Turbo Pascal 7.0 manual, with its introduction to object oriented programming.
these grown up "classic" books are just a bunch of egg head bullshit. especially Knuth, the hipster's guide to fucking up software (TeX being the fixed gear cycling of the computer world)
Influential: Having influence. Nuff said.
the 'gang of four' is a phrase coined during the Culutral Revolution of the 60s in China, a horrifically brutal period in which millions of people died, filled with mass starvation, torture, rape, murder, anarchy, mob violence, chaos, destruction, and other things.
then some fucktard computer dick comes along and writes a book about some obscure software engineering bullshit. what do they title it? "Gang of Four". oh thats FUCKING HILARIOUS
what is their next book titled, "Himmler and Heydrich"? I've got an idea! Lets write a garbage collector and call it the "Holodomor"! How fucking tongue in cheek!
to the authors. i got a tiny fact wrong. they got an entire history of a nation of people wrong.
the soulless amorality of the computer science 'community' beggars belief sometimes.
I would definitely say that Code Complete has been one of the most helpful and insightful books that I've read about programming. Reading through it never gets old.
I loved the first edition of this book. This was one of the best introductions to object-oriented programming and Eiffel programming language. Written by Bertrand Meyer.
...richie - It is a good day to code.
Addison Wesley 1976.
It showed the Unix Philosophy to a larger audience than Version 6 could reach at the time.
Best programming book ever if you want to go for pragmatic influence rather than computer science.
It also came with the ability to get the code. While the code is now dated, the philosophy is still leading edge. And lots of us played with that code.
Ah the memories! Fortran was still ubiquitous. It made Fortran usable. Kind of makes me want to go dig up RATFOR and do something...
Perhaps I was lucky, but I did read the top three books I'd recommend as I was starting my first job:
1. Advanced Programming in the UNIX Environment, W. Richard Stevens. This was influential in teaching me what clean functional programming interfaces look like, and hopefully the code I've developed since then has lived up to that ideal.
2. Network Programming in the UNIX Environment, W. Richard Stevens. Much the same as the first title, but in some ways illustrating programming interfaces that tackle more complex/flexible situations.
3. Writing Solid Code. Steve Maguire. Fifteen years later I still daily use a few of the ideas presented in the title. However it also served to show me the ugliness of some programming conventions (e.g. Hungarian Notation and StudlyCaps()) and led me to avoid those practices in my own code when I have a choice (i.e. when not having to conform to the style of existing code).
Cyrano de Maniac
It may seem odd but I would say Godel Escher Bach. I can't really think of any other book that I would consider worth while reading at the start of my carear. (I am actually thinking of before my college education.)
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.
"How to Do Nothing," kids activities, back in print!
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.
You missed the boat if you havent read any Richard Stevens. ANY decent bit of *nix network code has benefited from "UNIX Network Programming", it geek-e-ly changed my life.
My wife still hates it when I bring that book to bed.
Me too, seeing how easy BASIC was got me interested in writing programs, then from there I wanted to learn more. So the book from high school computers, Hands on BASIC with a PET by Pelkham, while no where near a definitive guide was greatly influential That and David Ahl's BASIC Computer Games compilation books.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
Please login before trolling.
Perhaps I'm trolling, perhaps I'm not.
As someone interested in algorithms, and the sorts of things in Knuth (complexity, number theoretic things, etc.) I have to agree. It's a huge mess that no one is willing to criticize and fewer people read. You're better off starting with a book by Herb Wilf, Dexter Kozen or any of a dozen other well written books. Note that this also goes for Knuth's Discrete Math book.
Good choice.
.. and also "Pitfalls of Object Oriented Development" by Bruce Webster.
The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
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.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Seriously that book is loaded. I mean loaded with 10k lines of code! Very detailed oriented if you ever want to dig deep and try some excersizes as well as skip some.
Too bad my ex has my Dietel and Dietel how to program C++ and Java books. Nothing online compares to the detail of these books
http://saveie6.com/
Oh, you said programming... well, database design is important too.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
I was just having this conversation with some colleagues the other day. Without a doubt, Code Complete tops the list for me, though admittedly I have not read it cover to cover, nor do understand or even implement everything in it. But it's great.
Also:
TAOCP - I'm one of the few programmers out there who will sacrifice my ego and admit there is a lot of it I don't understand completely. But it really is a timeless and valuable book.
Code Complete - Can be applied to programming in many different languages and offers a fresh way of looking at problems.
The Mythical Man Month - Ok, so not as technical but amazingly accurate in discussing software projects and how they progress in real life.
Object Oriented Thought Process (Matt Weisfeld) - This isnt as well known, but was my first introduction to true OOP programming, and offers a clear, concise explanation of it.
K&R - A little dated, but the concepts are still great. Not exactly a beginner book and focused on C, but could be applied to just about any language to make you solve problems better.
Newer Stuff
Anything Deitel - These books are expensive but incredibly detailed and packed with great information.
Head First Design Patterns - I already had a good understanding of them previous to reading the book, but had I read it first I would have much smarter, much earlier.
Seriously, how many other professions have such books? Teach yourself brain surgery, teach yourself plumbing, teach yourself law... No ours is the only profession in which someone can think themselves an expert in a few weeks time. The good thing is many people can improve their lives by studying one of these books and switching jobs. The bad thing is this may be part of why CS graduates have been declining.
I agree with your view on Design Patterns completely, but never really saw it put into words like that. For a giant project that's going to evolve and have lots of people working on it over time, it only makes sense to use patterns and practices based on others who have solved that same problem. However the tendency to over complicate more simple projects to fit in with a set of patterns can end up being counterproductive and a huge waste of time. Sometimes an application really is so simple that just breaking something into a couple of classes and documenting it good is all you'll ever need to do with it.
Apparently its the only book sold
Heh.
For someone seriously interested in programming and CS in general, this is a book(s) that has few equals.
Yes, it takes careful reading, more than a bit of math and the exercises are sometimes more than difficult.
So its tough, sometimes absurdly so, but it also covers so much and so well. Those intimidated by it are often poseurs - claiming to be serious computer types, but lacking in understanding and ability.
I'm an old geezer (I've been programming for 50+ years, starting with the UNIVAC I), but by far the most thought-provoking and "educational" book for me has been Bentley's Programming Pearls -- I currently have a copy in my bedroom along with the 3 volumes of Knuth!
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.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Unlocked a gold mine for me.
http://www.amazon.com/Advanced-Assembly-Language-Programming-Allen/dp/1565290372
Join the Slashcott! Feb 10 thru Feb 17!
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.
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.
Some of the concepts are dated as the concepts of objects have superceded the types of non-object or pre-object modules in Myers' world. But the power of this book is not algorithms, not on using goto or not using goto statement, not on the merits of any particular programming language. It is that if you are to code anything but the most trivial computer program, you are going to have to figure out how to divide it into managable pieces and then have the pieces work together.
The problem with choosing some of these books is that they won't make as much sense until you've had some programming experience.
Coder's Stone: The programming language quick ref for iPad
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 was our starting book. But in mitigation, expecting six year olds to read Knuth might have been a bit much!
The first programming book I ever read was "The Complete Idiot's Guide to QBASIC." It was great for me when I was 8 years old, taught me what the word "pizzazz" meant and to this date, remains the only book on programming I have read to completion (and I'm a recent honours grad.)
Was William B. Jones's "Assembly Language for the IBM PC family"
While I don't do assembly at all professionally, after reading through this one it made me wish the author had written stuff on some other languages too.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
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.
After years of programming I have to say the most influential book for me by far is "The Design of Everyday Things" by Donald Norman. In the end, you're designing a tool for someone... whether it's a end user or an api. The days of control-alt-delete are over... or at least they should be. Thinking about the user interface (whether it's mechanical, gui, api,or sdk) should not be something the programmer slaps on after the functionality is completed.
That's definitely a problem with people reading it when they're not yet at an architectural level to understand it. You aren't supposed to look at a problem and ask "What patterns can I use?". You're supposed to come up with a solution to a problem, realize that it's forming a pattern, and use that to both describe the solution to others and to identify potential strengths and weaknesses of your solution.
Unfortunately too many people without much architecture ability read it and try to apply it to a problem rather than to their solution, leading to a lot of pain. Also leading to my least favorite interview question "What's your favorite design pattern?". The only correct response- "The one that solves my problem".
I still have more fans than freaks. WTF is wrong with you people?
If you wanna go with most reads in a bookstore coffee shop you really must include something like "Learn Java in 21 days". MILLIONS must have read that baby back in the day.
Cwm, fjord-bank glyphs vext quiz
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. 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.
Code Complete is the only programming book I read (almost) cover to cover after I was already working as a developer. Truly the bible of programming (as opposed to the bible of X programming language). As a largely self-taught programmer (does 1st year Fortran and Pascal count as a CS education?) it neatly captured most of the lessons I had painfully learnt over a 10 year period. Once I read it, I thought "why the hell isn't this force-fed to every CS student?".
Apart from that, K&R's C book was one I kept going back to as I was only an occasional C programmer. Lean but information dense.
It's funny. You talk like you know what you're talking about, but you clearly don't. -- MagikSlinger: C++ programmer for 20 years, and Java programmer for 10 years.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Drink some Sanka buddy.
not even sure it's available anymore; but that, and maybe the 16-bit DOS art of assembly.
I'm surprised no one has mentioned "A FORTRAN Coloring Book." Yes, it's a real book: http://www.seas.gwu.edu/~kaufman1/FortranColoringBook/ColoringBkCover.html
I would call it influential due to the imitators it had in the end-user publishing field. There were many friendly computer books with cutsy images, but A FORTRAN Coloring Book was the first.
"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
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
and underlying code, I would say Sam's Teach Yourself C++ in 24 Hours.
Actually, that was a really good systems programming book, in style and content during the Win95 era.
Windows 3.x actually. The Win95 version was a fairly straight derivative of the original and was a bit lacking due to that. It did go from 16-bit to 32-bit and it was expanded for the newer APIs to a degree but it did not stand out as it once did.
Jeffrey Richter's Advanced Windows was the stand out systems programming book for 32-bit Windows.
I wonder if he meant that sentiment and phrasing in part as a reference to Winston Churchill's "It has been said that democracy is the worst form of government except all the others that have been tried."...
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
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.
Aho and Ullman's classic Principles of Compiler Design and the followup they did with Sethi Compilers: Principles Techniques and Tools
My wife bought me a first printing as gift one year.
Required reading for internet skeptics
http://www.amazon.com/Dating-Design-Patterns-Solveig-Haugland/dp/0974312002/ref=sr_1_1?ie=UTF8&qid=1315193378&sr=8-1
_Dating_ Design Patterns.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
Commodore 64 Programmers Reference Guide
Oh, come on. The mantra about goto always being evil is bullocks. Spaghetti programming is bad, but when you use a goto to avoid complexity, it's not to be shunned.
Everybody says that goto is bad, but very few of those who say it can give a rational explanation of why. In short, they're fanbois.
Or, put it another way, try to make a CPU without branching, only subroutines...
Principles of Operating Systems by Sacha Krakowiak.
Because it is important to understand the general principles of operating systems (parallel activities, synchronization, resource allocation, memory management...) when programming.
Slashdot, fix the reply notifications... You won't get away with it...
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?
Design Patterns: Elements of Reusable Object-Oriented Software by the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides).
Not that there were any main-stream OO languages available when I started programming (mumble) years ago, nor was it written for another decade or more, but...
Go permanent? In your dreams and my worst nightmares.
linked anyway to this page, I'd love to see a story titled What Is/Was the Most Influential Operating System?
Slashdot, fix the reply notifications... You won't get away with it...
Effective Java, by Josh Bloch.
I started with Pascal, so the most influential book for me is Walter Savitch's "Turbo Pascal: An Introduction to the Art and Science of Programming."
It's the best book on learning to program that i've ever read and it's still the yardstick by which i compare other entry-level programming books. It's very clear, detailed, informative, and sensible. The fun quotes in every section are an added bonus.
Ever looked at the assembly produced by a for loop? It uses jmp calls. jmp is the exact same thing as goto. If your professor is telling you that gotos are bad, they're either not very good professor or you're in a 100 level CS course where they don't want to confuse you too much.
Goto is bad because of the bad code it enables - even though fundamentally, assembler is all about goto (jmp, etc). A useful technique that enables code to be hacked to death and made unmaintainable deserves to lie in its shallow grave.
Man who leaps off cliff jumps to conclusion.
I wish I had discovered design patterns earlier in my career.
Beside that, maybe "Enjoying the Good Life: How to Pick a Career in Anything Other than Software Development So You'll Still Have Your Hair by 35". ;)
Truckin like the Doo-Dah man...
on x86, you'll see a compare instruction, then usually a conditional jump. Often JLE (jump near if less than or equal to)
There are other works specific to certain languages, which rise and decline in importance with the popularity of these languages. The fundamentals of how to program are hard to learn better than from this.
Of course, the question asked about the most influential work, not the best one, so this answer is more idealistic than anything. If it were more influential, we would have better programmers, and possibly less arguments about this or that language being better.
Somebody knows what they are talking about. I suspect an excellent education at MIT.
You don't understand why goto is considered bad: it allows for disordered structure and program flow (aka "spaghetti code.").
Of course you can do gotos in assembly - many languages have goto and they have to run on the hardware, but that's not the point.
In assembly, you have to enforce the code structure yourself. In higher-level languages, the compiler enforces it for you. The language "keeps track" of gotos needed for conditionals and loops so that you don't have to. Structured programming saves work and avoids mistakes.
I would have to go with any one of the many recent books on financial programming. No, I am not recommending financial programming as a field, I am just pointing out that all those graphs of historical stock prices would have been very useful 20 years ago :-)
Kiddie!:-) Numerical Recipes should be in FORTRAN, the language of scientists and engineers!
I just don't see Linus including the latter. :-)
Numerical Recipes has problems, such as changing coefficients from the standard form in order to meet specified accuracy in the fewest terms, and not telling the reader about it. There's lots of stuff for people who need "good enough" results that work most of the time, but there are lots of pitfalls to catch the unwary.
Contribute to civilization: ari.aynrand.org/donate
Many older books have now dated, but two that I would recommend are "Classics in Software Engineering" (edited I think by Ed Yourdon), giving a great perspective on how to approach programming and programming style; and "The psychology of Computer Programming" by Gerry Weinberg, an approach to thought processes, both individual and group, involved in software development. I have no idea if they are still in print, but they served me well for many years
Visual Basic for Gumby/Gumbies?
If you're programming in assembly, goto is all you've got. If you're using higher level languages there are other options, usually far more appropriate than a goto.
Those flow control in higher level languages may all compile into jumps, but they shield you from doing stupid things with JMP you shouldn't be doing in ASM either.
The statement of "goto is bad" isn't about the assembly language where there are no other choices, it's about using it in languages where there are other choices.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
An introduction to Database systems, C. S. Date
Algorithms, Sedgewick
The dragon book.
Some of those books are freely available as Creative Commons downloads and yet the Web master offers commissioned links to Amazon to by the books (and he does NOT offer links to the free downloads). Some of these freely available books are sold for well over 100 dollars on Amazon.
If you want to make a patent troll like Amazon rich, then go ahead and buy these books. Otherwise download them from the authors Web site or pick them up from the Pirate Bay.
Wikipedia can be your guide for the Creative Commons books.
That's why I can't take the Agile Manifesto seriously. Any group that thinks a semantical term used and misued by many a fanatical political grouping (see where I'm going here) as a substitue for reasoned and nuanced thinking (there is no silver bullet) deserves serious scorn and derision.
You're totally wrong about goto statements.
Also, in the assembly you do not get to name the variables. You just get a chunk of the heap, and it just adds an offset to it.
You professor should teach you that instead to declare a bunch of variables (which may lead to syntax error), you must just declare one byte array and use it as a memory space, manually calculating the offset of each variables.
If your professor is telling you that you should use named variables, they're either not very good professor or you're in a 100 level CS course where they don't want to confuse you too much.
...
Why did you stop at the gotos? There are so many things that high level languages do not do *right* (i.e., as assembly code).
Why can't
... that's the one that will be of most influence on me :)
'The unexamined life is not worth living' - Socrates
Even if it's somehow outdated (and no longer in print), every single program we write today is highly influenced by "Structured Programming" by Edsger Wybe Dijkstra, C. A. R. Hoare and Ole-Johan Dahl. Before this book, programs used to be a mess of spaghetti code and the familiar constructs like if-then-else or while loops did not exist.
The one that changed everything for me was the smaller of two books that came with Blitz Basic 2 (for my Amiga). It was a cross between a reference manual and a guide to programming, and from it I learned to write code. 20 years later, I'm still coding, full-time now, and I still love it.
The problem back then (for me at least) was that compilers, SDKs and reference manuals cost a fortune. I earned £4 a week delivering newspapers, so I couldn't afford £300 for a C compiler and £200 for the Commodore SDK. Once you outgrew the included basic, it was quite hard to know where to go next.
But I'm not suggesting that's a classic by any stretch, it's just a book that had a profound impact on me. As for classics that might have been overlooked so far in this discussion, how about Game Programming Gems? Over the years I'm quite sure that they've made a pretty sound impact on the world of games programming. My favourite books (which are mentioned above, but aren't technical guides per se) are Mythical Man Month and Peopleware. Peopleware in particular taught me that good programming is as much about people as it is about syntax. I also liked Extreme Programming by Beck.
In Fortran GOTO is essential and JMP in assembly is effectively a GOTO (or vice versa). Just because it doesn't look pretty doesn't mean somebody attempting to cover the entire field should ignore it.
Not nearly as popular as "Harry Potter and the art of computer programming".
The name is very likely to be a joke, a band name or something that sounded cool at the time.
For instance I am not really an old database program or an Aston Martin car.
Couldn't agree more. TAOCP seems more like a book aimed at telling you how clever Knuth is than a book aimed at teaching. The idea of starting with a low-level programming language and building high-level constructs on top of it is great, but the execution of TAOCP is very poor. Part of the reason for this is that Knuth is a great theoretician and a terrible programmer. TeX should show you that TAOCP is not a book about programming - who, in the '70s, would invent a new programming language in which structured programming is impossible? Only Knuth. It combines the worst aspects of Lisp and an assembly language.
I am TheRaven on Soylent News
Bullshit. I have a PhD in computer science, and I wouldn't recommend TAOCP to anyone. Sure, it covers the material, but it covers it amazingly badly. Knuth manages to take simple concepts and make them incomprehensible. Read pretty much any textbook on theoretical computer science other than TAOCP and you'll learn a lot more.
I am TheRaven on Soylent News
My first book on programming was the CPC 464 programming handbook, which only explained all Basic commands. Later I learned Z80 assembler and Commodore Basic. Then I learned Pascal with a Turbo Pascal handbook from the library. That book told me to use pointers for dynamic memory usage. And I learned about paging. And then I learned a little bit of C with K&Rs book.
However, the biggest boost (approx. 200% at least) in improving programming skills came from my first semester in computer science. We had a lecture called Programming with 2 2 hour lectures a week and 2 hour exercise course. We learned about all known programming pattern and how to use them in different languages. Our professor was a big Scheme fan, so most of his examples where in Scheme. But functional programming was very influential for me. It changed my way to code in Pascal and C.
Ah yes and I learned to use libraries. ;-) Something you do not, when you are on a DOS machine.
The statement of "goto is bad" isn't about the assembly language where there are no other choices, it's about using it in languages where there are other choices.
The original statement was 'Go To Statement Considered Harmful'. The essay - which really kick-started the structured programming revolution - was not about using goto, it was about providing it in the language at all. If you're using C, for example, then you don't have a go-to statement in the original sense. You have a very limited version that only allows flow control within a function scope. The go-to statements that Djikstra was complaining about were ones that made things like variable scoping impossible. They allowed jumping anywhere inside a program, without a return mechanism. This made reasoning about the code insanely hard. If you learned to program after the '70s, then you've probably never used a language (other than an assembly language) where this kind of thing was possible. The closest that we have now is setjmp()/longjmp().
I am TheRaven on Soylent News
Really? Tanenbaum is pretty specialised - certainly worth reading, but not sure it's in the most influential. The MINIX book is way too heavy on source code and light on general theory, although Modern Operating Systems is a lot better. If you want something with the detail of the MINIX book, read either Amit Singh's OS X book (which also has a lot of detail about processor architecture) or one of Kirk McCusick's BSD books.
The Knuth series teaches algorithms, but does it badly. It's also light on the general theory. If you want to understand the theoretical side, start with Church and Turing, take a side track into Gödel, and then visit Dijkstra. Skip Knuth entirely. If you want something more in the practical side, read some of Alan Kay and Dan Ingalls' papers from PARC.
I am TheRaven on Soylent News
Indeed. When you are the bast hacker of all, but you are not able to understand other people, you cannot bring all your genius on the road. This is like a car (I hate car analogies) with a really fat engine but without wheels. Even though best systems are developed in teams. Therefore people skills are very important. Therefore we had a course in soft skills at university. ;-)
Blew my mind away. Any randomly selected page was useful.
"Doing what i can, with what i have." ~ Burt Gummer
Even the 6502 had JSR and RTS.
Not sure why my brain insists on remembering thirty year old stuff like that, and yet I forget where my keys are.
Mod parent up.
Algorithms + Data Structures = Programs
http://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-Computation/dp/0130224189
Slightly more practical than the Knuth books (though replacing MIX with Pascal doesn't increase the opportunities for cut-and-paste coding).
And as an added bonus, no mention of the dreaded words "design pattern" in the entire text.
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 wouldn't want to use the D & D books to learn a new language on the job and not all of D & D books were great, but when I was in school they made very good TEXTBOOKS. They were academic in scope, taught concepts beyond the language and covered concepts completely. Best of all I could understand them. I couldn't understand K&R's as a raw beginner programmer.
I think for me, it has to be the Commodore 64 Users Manual. Why? Because that's what taught me BASIC, and the phrase in that manual, something like "don't worry, you can't break the computer, unless you're an elephant".
Runner up in close second, a series of kids "detective" adventure type books in which they used little BASIC programs to help them solve the "crime". That taught me to think of the computer as a tool that could help me solve problems, if I just gave it the right instructions.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
The best It book I had (a russian programmer stole it).
Its coverage on bounded non determinacy was inspired for its day.
I don't know about a particular book, but I would ( and have ) push Python on any beginner programmer. The first language learned and the first lessons dictate habits that last a career.
Python is built to teach good habits and it is a practical language at the same time.
C for dummies was the book that my girlfriend taught C from and programming in general. With its friendly writing it helps alleviate the learning curve for a noob programmer. I think it's the book I'd recommend to anyone starting programming - and to me too. Unfortunately, I was born too early for this book, and started programming with ZX Spectrum Basic and assembly language. Which is cool too, but by far not as cool as C :)
The biggest problem with the question posed by this article is that even if I had a time machine and could meet myself when I started programming, I'd have a hard time selling "The C Programming Language" to my 5 year old self. Seriously, most of us started programming as kids, and we did it for fun. Reading long books is no fun, and CS theory is seriously no fun at all.
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.
very influential programming book...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Many of these algorithms were at the time being explained for the first time. The Knuth version of the algorithm is extremely important for people writing libraries and still quite influential. As far as MIX and verbose, any assembler is going to be verbose.
Sort of. There are 3 levels of anti-gotoism
1) Arbitrary jumps. Which in practice are like function calls with no return mechanism. And you are right that stack based has replaced this. A pure plus for everyone.
2) Violations of one entrance / one exit. Things like "last" statement in loops or "if x then return" etc... inside loops. These are still used
3) Complex flow. Things like event driven programming make complex flow more common than it ever way in the goto hayday. I'm not sure there is a choice but...
Although mine didn't have exactly the same cover:
http://www.amazon.com/Programming-6502-Rodnay-Zaks/dp/0895880466
A fantastically to-the-point and useful book. In -84, -85.
Or whatever year it was, I don't remember. To me it felt like opening a treasure chest.
Baboons are cute.
JSR and JMP aren't interchangeable (atleast not on a 6502). They handle the registers and stack differently. On a typical CPU, you can't do flow control like if/while/switch from higher-level languages without jumping.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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/ This is an excellent book about Software Testing.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
A lot of the books mentioned are fairly specific to C, C++, Java, etc... but I like to get down to the basics of programming logic, application design, and "KISS". Joyce Farrell's Programming Logic and Design does exactly that and forces you to think how you can improve the optimization of your algorithms through careful planning. I can honestly say I have written better code (and documentation) as a result of reading the book and practicing its philosophy. I also think Joyce's Java Programming text was a lot more comprehensible than the Deitel How to Program Java text.
Nuff said
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You seem to fail to graps the difference between an low level assembly JMP instruction and GOTOs in high level languages. Your complete posting makes no sense. Why don't you read the relevant Essay or look at some old Fortran or Basic code to get at least a remote idea about what you are bragging? Hint: http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Well, Knuth would hardly need to supply any example code if he applies for a job, so it kinda makes sense. ~
But if you're disciplined and only use the goto to build structures, you'll have code you can actually maintain.
A Discipline of Programming by E.W. Dijkstra (1976)
The first book that got me thinking deeply about computing, not as a collection of hacks and tricks, but as something to be done properly. It's not a programming manual as such, but it's chock-full of advice-by-example, illustrating some of the really good bits of design in the Beeb, how the various subsystems interacted with each other, how to make best use of extremely limited memory without sacrificing design -- and the value of writing something well, which could allow it to be used in ways you never thought of.
I've read many great books since then, of course -- K&R, Knuth, Sedgewick, Programming Pearls, Effective Java, Programming in Scala, and more -- but the Advanced User Guide has probably had the most influence on me and how I think about computers. It also has the most annotations and other scribblings all over it!
Ceterum censeo subscriptionem esse delendam.
The most important programming book for me was Mapping the Commodore 64 by Shelon Leemon. I learned how a computer really worked under the hood. It made working with pointers later much easier. But most of all, it helped stoke the fire.
--I'm so big, my sig has its own sig.
-- See?
Can you name a reason why GOTO statements are a bad thing? You sound like someone who heard it from their APCS teacher, did not pay attention to the reason why, and now repeats it religiously. "All the other books" must not include compilers textbooks or textbooks on machine architecture.
Palm trees and 8
A useful technique that enables code to be hacked to death and made unmaintainable deserves to lie in its shallow grave.
So do you only program in SKI or BKCW? Just about any useful programming language is going to have features that allow you to hack your code to death...
Palm trees and 8
For me it was Gilman and Rose's A Programming Language. (APL), developed by Dr Kenneth Iverson. He opened my mind to thinking of solutions to problems in a different way. Sadly, APL has dwindled to almost nothing, and is probably only used by Actuaries and some aficionados. Dr Iverson's son and his peers developed J as an alternative. Once you think of the solution by not thinking of the underlying programming language, progress in thinking can be made.
Leslie Satenstein Montreal Quebec Canada
To be fair, I have turned to Knuth for reference on a few occasions when I needed a very detailed explanation of an algorithm and the background and reasoning behind that algorithm. The way I see it, TAOCP is something that should be used as a reference, for those cases where you need a lot of detail.
Palm trees and 8
MIX was intentionally problematic to avoid dependencies on platform assumptions that might not be portable
A side-side-project that I want to work on some day is to write a "companion" for TAOCP, which presents the algorithms in Scheme or Haskell (or some similar language). I understand Knuth's point about getting to the machine level and really understanding what the machine is doing, but presenting the algorithms in a high level language would be useful for the vast majority of people who own his books.
Palm trees and 8
It might be the Basic manuals that came with the Sinclair ZX81 or the TRS-80 or the Commodore 64
when I was learning c++, i had a copy of stroustrup, and got nowhere with it. Then I printed out the entire c++ FAQ and read it on various bus trips. It actually explains it like an FAQ should. Then I went back to stroustrup and was able to understand it.
I wrote my first program at the age of six, and I still can't work out how this website works.
Concepts, Techniques, and Models of Computer Programming. They call it the new SICP book. I only read the first 50 pages, but it's quite intresting read. It covers parallel programming, constraint programming, and old lispy topics as well, like program transformation.
http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262220695
I have nothing against the 2nd ed. K&R, it's just that only the 1st ed. was available in the early 80's. It was the best programming book I had read at the time. Both books are great in that they are small.
Programming the Z80 and Programming the 6502 (both from Zaks) are probably the best assembly language programming books I have read because they focus on processor internals and how computers work. Understanding assembly can make you a better C coder. And who doesn't love inline assembly? :-)
Hacker's Delight is a great read. You can perform a lot of magic by shifting bits around. This book is often cited as the "lost TAOCS book".
I prefer Concrete Mathematics over TAOCS as far as Knuth books go.
Published in 1984 The UNIX Programming Environment by Brian W. Kernighan and Rob Pike - http://en.wikipedia.org/wiki/The_Unix_Programming_Environment . The book remains interesting, useful and relevant even now after more than 27 years. It remains a 'must read' for anyone who uses UNIX like systems. Compare this with most of the 'Programming Books' now, which goes out of date within a few months after publishing.
For instance I am not really an old database program or an Aston Martin car.
Prove it!
jesus thats fucked
Back in the day, I found Illustrating Pascal, ISBN 0/521/33695/3 by D.Alcock to be very useful. ref: http://www.amazon.co.uk/gp/reader/0521336953/ref=sib_dp_pt#reader-link It helped me make the jump from programming as a hobby, in various forms of BASIC, to proper programming languages.
Ever tried to maintain that assembly code? That's why jmp/goto is bad.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Well many things in it go over my head, but I have used it for random number generator related work, and sorting and searching was also helpful. I certainly didn't go through it while trying to do every exercise.
Je me souviens.
My sincerest apologies for my grievous error.
The author's surname is Carnegie
There, feel better now?
Words to men, as air to birds.
Doug was in my Chinese-1 class at Stanford in 1976. I think he was chilling out at his Stanford Prof Dad's house after just finishing his physics PhD and working on his book. I think Doug was exploring the Whorf-Sapir-Heinlein hypothesis that language influences how you think. Chinese was the most radically different language from English you could readily study at the time. I was interested in Chinese philosophical classics in the original (a level I never reached).
Anyways, Doug gave me this clever little vignettes he was writing that reminded me of the mathematical puzzles in Scientific America because I was one of the few techies in the Chinese class. I never guess these would win the Pulizer non-fiction prize and become a computer classic.
Ken suggested that small, bottom up skunkworks are more productive than massive managed software projects. This certainly changed how we did things over a decade ago. The compromise between the two methodolgies is Agile.
That's not a "When you first started programming" book though. That's a "When you've been programming for 1-2 years" book.
It's pretty much essential then though. Along with Fowler's Refactoring, and The Pragmatic Programmer, all of which add far more value when encountered a year or two into a programming career.
Or a programmer that writes software, not algorithms.
I don't care which sort routine is most optimal. I merely need a 'good enough' one that I can pull out of the standard language libraries and use.
Let the computer scientists model, design and provide reference implementations for new algorithms. The rest of us will turn them into useful software.
Maybe if you work at Google, or a market trading company, or one of those other roles that comprises a thousandth of one percent of programming jobs where that shit actually matters then it's useful. The rest of us just need to know when to use an array in preference to a linked list and focus instead on functionality, interface and the several hundred constraints we're dealing with that are more important than a marginal improvement in efficiency.
That's why I can't take the Agile Manifesto seriously. Any group that thinks a semantical term used and misued by many a fanatical political grouping (see where I'm going here) as a substitue for reasoned and nuanced thinking (there is no silver bullet) deserves serious scorn and derision.
A "manifesto" is when a number of people think alike, condense their thinking into a short text and publish it hoping to swing even more people. What's wrong with that, exactly: thinking alike, writing it down, or telling people about it?
How I wish I had mod points for "Insightful".
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
No, that doesn't follow. There are uncountable other ways to make code unmaintainable.
Not a book, but a must read for anyone working with computers.
Reprinted from columns in Communications of the ACM by Jon Bentley.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
The Joy of C, 3rd Edition by Lawrence H. Miller and Alexander E. Quilici (Jan 16, 1997)
most fixed gear cycling is hipsters who are following a fashion trend. the courier profession is dying, and track competitions are highly specialized racing events that used 'fixed gear' because of their arcane rule system (which also, by the way, bans recumbents).
yup. just about like TeX users.
The Fortran Coloring Book, with the program listings in Creative Computing and 101 Basic Games tied for a close second...
Ken
This was the one.
As a student I learnt C using K&R's classic in 1989, the year after it came out. Then later in a job, I used Deitel and Deitel to pick up both C++ and Java ... great books, but K&R and D & D are totally different in approach.
I get your point and I largely agree with it, but perhaps you should take a closer look at the code listing in Knuth's books...
That's abstraction over language though; the things in Knuth's books are often directly usable in modern applications just translating into the language you have to work with, adjusting implementation as suits the language you are working with.
A good operating system book might have some nice bits on schedulers or managing concurrency in applications or filesystems, but very little of that is going to be very useful in most modern application development.
Not to say OS classes are not valuable and I think everyone seriously interested in CS should work through one of those books, I just think it should be after you have the fundamentals of algorithms down. Then you can even better appreciate what is going on in the OS books.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
....I only just got the freaking pun in the title. Just now. September 2011.
Lord help me!
Do daemons dream of electric sleep()?
You've probably never heard of this book, but when you move from code monkey to engineer/architect you must read this book, http://en.wikipedia.org/wiki/A_Pattern_Language. The other one you should read is the Toyoda Way http://en.wikipedia.org/wiki/The_Toyota_Way
Better hope your manager doesn't read Slashdot. She'll be asking herself, "what use have I got for someone who takes weeks to realise he needs to use his editor's 'show white space characters' command when dealing with a white space sensitive language?"
A manifesto is ultimately an opinion or philosophy, not a fact of life or immutable physical laws. My objections don't lie with the intent but rather the substitution of logic with belief. All religious creeds begin with a "manifesto" establishing common belief systems. I think Agile is another form of belief, not backed up by much more than anecdotes.
by Robert C Martin. Its got nuggets of gold in every chapter and covers a whole gammut of topics.
I know its language specific, but the way the book was written and structured made learning a new (and challenging) language easy for me ... really inspired writing.
The dragon book came in at number 10 on the list in the original article ... quite a feat.
Not that I'd vote for one, but just a bit surprised considering the silver bullet it was meant to be for software engineering in general.
Kernighan and Plaugher wrote "Software Tools" to assert that small, capable, tightly focused programs could be hooked together to accomplish large tasks. Unix/Linux organization is a prime example of this approach.
Ideas like deriving code from specifications, developing proof outlines and code in tandem, and just generally more rigorously thinking about code and why it works.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Since my manager just spent a week fixing a build script bug that ended up being this problem, he'd not only agree with me but he'd probably be more vehement.
So lets see, that's now the 5th work around I'm supposed to be using, all because of a idiotic design decision in the language. Or I can just use languages that don't do stupid shit like this. Decisions decisions.
I still have more fans than freaks. WTF is wrong with you people?
That was 12th on stack overflow's list
Amiga Hardware Reference Manual: knowing how your program operates in physical reality will change your perception of how your code should best be structured. It will also open your mind to multiple processes running on multiple devices whilst sharing resources efficiently such as to allow real-time performance.
Leela: "Is all the work done by children?" Alien: "No, not the whipping."
How many of us got a start with "Basic Computer Games" by David H. Ahl?
Without that, I bet many would not be posting here.
--- If it's worth doing, it's worth doing in Perl!
Definitely! Too bad I don't have any mod points.
There was a number of books outside the top 10 that have been mentioned in the comments here, note that the original article has been updated to include the books placed in spots 11 through to 30... http://www.internetsecuritydb.com/2011/09/top-ten-most-influential-programming.html
Yeah agree with your view on Design Patterns ... there was a stage several years ago when if you went to an interview you were almost guaranteed to get a question on design patterns ... and if you didn't know anything about them, then sorry, better luck next time ... it was as if to be considered a good developer you must able to memorize a few design patterns, which may or not be of any use in real projects you encountered anyway.