Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

peetm (781139) writes "Having visited with me and my wife recently, the girlfriend of an ex-student of mine (now taking an M.Sc. in pure CS) asked me to suggest useful books for her boyfriend: '... He recently mentioned that he would love to have a home library, like the one you have, with variety of good, useful and must-have books from different authors. ... Mostly, I was thinking your advice would be priceless when it comes to computer science related books, but .. I would appreciate any sort of advice on books from you. ...' Whilst I could scan my own library for ideas, I doubt that I'm really that 'current' with what's good, or whether my favorites would be appropriate: I've not taught on the M.Sc. course for a while, and in some cases, and just given their price, I shouldn't really recommend such books that are just pet loves of mine — especially to someone who doesn't know whether they'd even be useful.

They're kind of dated, because few people do sorts and list manipulation at that level any more. I have both an original edition and a current edition of vols. 1-3, but haven't looked at them in years.

They're kind of dated, because few people do sorts and list manipulation at that level any more. I have both an original edition and a current edition of vols. 1-3, but haven't looked at them in years.

Sure, for the average programmer these days who relies on existing libraries, these probably aren't all that useful.

As a grad student working on a thesis and other papers however, Knuth's books are invaluable for citations. Need to defend the use of a specific algorithm? Cite Knuth. His books were invaluable citation material for when I wrote and defended my thesis a few years back.

This is, of course, good science. You may not need to use Knuth to program your own B* tree, but you have a pretty much universally accepted reference for citation if you use one in your research.

You seem to misunderstand what a citation is. A citation is not saying, "Here, this is true because Mr. XYZ said so," but, "Here, this is being accepted as true (or just considered even) because Mr. XYZ gave good argument/data in source ABC." It is not an appeal to authority, it is reducing redundancy by not re-deriving something already written about elsewhere. And this is a good science practice, as it is rare to be working on a topic where no one has already done some theory work or found some relevant experimental data.

You should have spent a lot of time deriving things in your undergrad and early grad courses, and you should double check the calculations of any citation central to your work to catch typos or actual mistakes. But by the time of writing actual papers or your doctoral thesis, you shouldn't be wasting reader's times by re-deriving things in detail beyond what is needed for outlining background and covering your premises. Unless your new contributions are a better way to present or derive the same solution, or showing a mistake in the derivation, you move on to deriving new things while cite others for stuff already done.

IANAL, but as I recall, in the practice of law (at least in the US), you don't add anything new. Unless you're a Supreme Court Justice. A lawyer's job is to piece together relevant laws and cases for precedent to provide a legal framework for whatever argument they're presenting.

If a civil case is being litigated in court there's very often a new question to be answered, because the relevant statutory and case law are unclear about the case at hand. Your job as a lawyer is to show the court how the pre-existing law applies favorably to your novel situation, when appropriately extended or amended. In the common law this is how the law slowly grows organically overtime.

Trial and lower appeals courts make new law all the time, and stare decisis demands that one trial court judge norma

if you have citations for every line, what did you do that was new and added by you?

The conclusion.

A legal paper is like a mathematical proof, where every step must be justified by drawing on an axiom, a definition or an existing theorem. In proofs, relatively few of the arguments need to explicitly state their justification, particularly those that just manipulate symbols according to the very well-known rules, but that's only because the reader can be expected to see the obvious rationales. Beginners are often required to rigorously justify every single step in order to help them under

Well at least Professor Knuth is still alive, and I don't [YET!] need to refer to the poor man as spinning in his grave.

AC posted an excellent response here. [slashdot.org]. In the event you're filtering AC's, take the time to read it, as it's completely on point.

I would add is this: if you've never completed a Masters thesis or Doctoral dissertation, just try submitting one to your committee without adequate citations. If you write somewhere "I used well-known algorithm ABC because of XYZ" and you don't have a citation for that algorithm, you'll be sent back for rewrites pretty quickly to add appropriate citations.

By way of example, in my Masters thesis several years ago, I mentioned Unix diff [wikipedia.org] , without a citation. Why would this need a citation? It was mostly mentioned in passing, and every computer scientist under the sun knows what diff is, right?

Committee came back asking for further citations on a few things, including diff (which, for the record, is "Hunt, J. W., and McIlroy, M. D. An algorithm for differential file comparison. CSTR, 41 (1976).")

Using citations isn't an appeal to authority. It's akin to using an existing library call in programming. Just as you wouldn't roll-your-own quick sort algorithm when coding, someone writing a scientific paper doesn't re-invent every algorithm ever derived. You find someone who has already done that, and you cite them. The AOCP is useful in this regard due to the sheerly massive number of algorithms Knuth describes. It's hard to go through a Computer Science program and not use one of these algorithms. Knuth himself likewise cites all of the algorithms in the AOCP, so it's not an appeal to his authority, as he delegates that out to others appropriately. It's simply useful because instead of having to track down papers written in the 1960's on your own, you can cite Knuth who cites those papers for you. This is why the AOCP is useful for a graduate student.

FWIW, I cited Knuth. I needs an algorithm to calculate variance, and another on the Box-Meuller transformation. Art of Computer Programming had one for each, which I adapted for my needs, and cited appropriately.

Few programmers actually do sorts and list manipulation at that level anymore, but any of them worth a damn should be *able* to do them at that level and understand the underlying theory to make the most effective use of them.

You may not need to be a mechanic to drive a car, but you'll damn sure get better performance out of it if you are.

I teach "Operating Systems". And yes, I don't expect (I'd love, though!) many from them to have to implement a Second-Chance (Clock) memory page replacement algorithm. But I do expect them to understand how duing professional their lives the programs they write will be treated by the operating system, and how to avoid bad performance resulting from inefficient patterns.

After a several year hiatus away from computer stuff I agree completely. I gradated CS in 2002. There was much more priority given to imperative programming and arrays for everything than there should have been. Most of the lecturers were brainwashed by terms like "object oriented is the future", "extreme programming" and other such nonsense because it's "kewl". We did some Prolog but not nearly enough.

Of that list, maybe object oriented programming is important to "know". Otherwise computer science courses should be treated as language and platform agnostic, and only focus on stuff like data structures, arrays, etc. Basic theory that is applicable to any language.

It wasn't emphasized. We did no lisp! or Scheme.. It's sad that I'm more mature than many of those guys despite being younger.

I never did any LISP programming in school either. Oddly enough the language that always fascinated me was Postscript. Its amazing what a printer page description language is capable of.

The problem with Knuth's books is that he uses MIX, a weird type of assembly language, to write his algorithms. This probably made sense in the 70s and 80s when high level languages had not matured much, but not today. In this day of modern languages, the book should implement algorithms in C, Python or even Pascal.

"Having visited with me and my wife recently, the girlfriend of an ex-student of mine (now taking an M.Sc. in pure CS) asked me to suggest useful books for her boyfriend: '..

This brings to mind the ever-classic::

Dark Helmet: Before you die there is something you should know about us, Lone Star.Lone Starr: What?Dark Helmet: I am your father's brother's nephew's cousin's former roommate.Lone Starr: What's that make us?Dark Helmet: Absolutely nothing! Which is what you are about to become.(from http://www.imdb.com/title/tt00... [imdb.com])

Generally, the highly respected works for each subarea of CS are already well known. Someone studying at the graduate level should have no difficulty finding them on their own, one would think.

Moreover, at the graduate level, one is generally studying for some specialization. Without knowing what specialization this person has chosen, any advice we could give him would be unlikely to be of use.

Add in some classical literature as well: Dumas, Steinbeck, Hemingway, Twain for good general frameworks; Nabokov, Chomsky, and Hofstadter for semantics and creative architecture. The biggest lacking I see in engineering majors (ALL of them) is understanding of other perspectives and the big picture. Good literature is a huge help here.

Actually, if you are going to go there, I'd highly suggest any prospective engineer go see a production of Titanic (the musical play, not the movie). There's this whole subplot of the owner constantly pressuring [wikipedia.org] the captain and the engineers to cut corners and run outside the established safety margins, in order to meet a schedule that will help his own marketing and make himself a few extra nickels. Of course this causes a huge disaster, in which the designer, the engineers, and the captain take the fall a

Since most of the "Computer Science" we call today is actually "industrial science" with variations on things we already know, you shouuld go back and learn all of the fundamentals fo the science, which in my opinion was established by Knuth.

Which, I can assure you, you haven't learned them if you went to a typical University in the United States. For one thing, you spent way too much time reading about other things to cover the basics of the science of computing in 4 years at a University.

This should be a graduation present for all University Students, and a cornerstone for those who want to avoid college because of cost/indoctrinized education and begin studying the topic yourself.

What I like about this set of books is, you can even as a beginner, skim the text and if you like, avoid the theory, and immediately start trying to write code and in many cases, the algorithms in the code point to an understanding to the process of many mathematical functions.

With this understanding, you can start trying to tackle some of the fairly formidable abstract ideas in the text which forms the foundations of computer science.

For example, I learned what integration was about from a computer algorithm this way when I was 14, and once I understood what was happening with the code the math was much simpler. I always thought Calculas at the time was big and scary. Not so scary when you do it in C code.

Calculas = Fancy Adding and Subtracting.:-)

But you won't touch any subject matter right now, or in the foreseeable future that Donald didn't already cover in these volumes.

The brilliance of calculus is the usage of infinitely many infinitely small rectangular slices to nonetheless derive an exact measurement of the finite area under a curve. At its core, calculus is the merging of the infinite and the finite. When you truly understand it, it is one of the most elegant and beautiful discoveries in human history.

My, I thought I was about the last person around who remembered Weinberg's book, but I see he's republished it. A group I worked with in 1976 used it to guide our approach to building teams and to "egoless programming". As i recall, most ot the examples are from the punch card era, but the reviews on Amazon say that Weinberg's updated it with comments based on experiences in the decades since.
That said, I think it's a stretch to recommend the Psychology of Computer Programming as "Computer Science". It's

Sipser's book is not bad, but I find it much shallower than any of the editions of Hopcroft[,Motwani], Ullman. Many of his proofs seemed to be more hand-waving. On the other hand, he is somewhat good at building intuition, which is valuable for students not yet used to the domain.

[...] and in addition the field of compiler optimization was more or less revolutionized by the invention of "SSA" form after the first edition was published.

Also not covered in the first edition are bottom-up code generation and graph colouring register allocation. These three techniques are the back-end of a typical compiler these days, if you don't count highly machine-specific stuff like static pipeline scheduling and D-cache optimisation.

I have trepidation about recommending the GoF book. It's a great book, don't get me wrong, but I think it should be deferred until the reader has a non-trivial amount of real-world experience to dampen any excess of enthusiasm for the patterns. Perhaps what's best is that new software engineers read GoF but are strongly cautioned that they should use it primarily to recognize common patterns, rather than as a recipe book for how they should structure their software, at least until they have more experience.

It should also be coupled with serious study of anti-patterns [c2.com]. In fact, I'd say that for new professionals a study of anti-patterns is actually more useful than a study of patterns.

If you don't read the book until you have lots of experience, you will probably have reinvented most patterns, but using different names for them which will only confuse other people reading your code. Overuse of design patterns may be a necessary developmental phase;)

By the way, while it is in the GoF book, I'd argue that Singleton is actually an anti-pattern.

By the way, while it is in the GoF book, I'd argue that Singleton is actually an anti-pattern.

It's an anti-pattern in Java and Smalltalk, and probably C# (never used it in anger, so can't say). It's not in lower-level languages (e.g. C++) where the semantics of shared libraries are not specified and you don't have enough meta-object protocol to do dependency injection. In that scenario, singleton is critical to enforce initialisation order.

Well, I'd argue that a library that needs a single global init call is itself a poorly implemented singleton with all the associated problems. It is unfortunately a common occurrence and wrapping it in a singleton class is a way to deal with it. But in my opinion that is making the best of a bad situation rather than a pattern that I'd recommend if you have anything to say about the library interface.

I have seen a lot of singleton use in C++ unrelated to libraries and most of those uses became problematic a

Strangely, nobody has addressed the graduate student part of the question. Being a CS grad student involves much more than technical knowledge. You also need to internalize the social norms of this career choice. For this purpose, there is no better information source than The PhD Grind [pgbovine.net] by Philip Guo. The book is completely free (as in beer) from Guo's web site. His web page also contains a great deal of career advice worth checking out.

These are classics. My favorite, hands-down, is Ted Nelson's "Computer Lib/Dream Machines". This is an odd book - it's written in hypertext (links to other pages and all - after all Nelson invented the term hypertext!) but in print form. Beyond that, it's really two books joined in the middle: Start reading form one cover, it's Computer Lib, start reading from the other, and it's Dream Machines.

Sure, parts of it are dated, but the concepts and thinking teach how to *think* about what we now call UI/UX an

It's a little tough to find, and stupid expensive. Makes a good gift though. It's pure madness, like other computer books of the time such as My computer likes me and What to Do After You Hit Return. It's okay though, as it adds a lot of charm.

As far as gifting goes, it's much better than The Mythical Man-Month, which is about as charming as the average Slashdotter.

Structure and Interpretation of Computer Programs, 2nd Edition. This used to be an undergraduate text for a course at MIT. But, it is now optional even at MIT. This is shocking to me. We used the text in my sophomore year at the University of Utah. If you hear old timers (okay me) complaining about programmers these days, this is part of it.

Computer Architecture, A Quantitative Approach (5th edition). I need to update my copy, but this text really allows one to reason about scale and performance.

An Introduction to the Analysis of Algorithms, 2nd Edition. Again, I need to update my copy, but this provides the key mathematical foundations for algorithmic analysis and their performance.

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable.NET Libraries (2nd Edition). This is much more practical of a book, but it gives key insights into framework design. Yes, it's about.Net, but it's really about large scale object oriented design applied in the real world and therefore useful to all.

Modern Operating Systems (4th Edition), Tannebaum. A great insight into OS internals, including key concepts that are useful in all sorts of programming.

Essentials of Programming Languages (3rd Edition). A deep dive into interpretation of programs. Provides a great start into programming language semantics.

Compiling with Continuations, Andrew Appel. Of course, the Dragon book is useful. But this book really gives some unique insights into program analysis. Combine this with Engineering a Compiler and you have insights into how code really is transformed into executable artifacts.In fact, this reminds me, I need to go make sure I still have my copy. It's pricey to replace.

I'll make a final plug for Semantics Engineering in PLT Redex. There are lots of advanced books on programming language semantics, but this is only book I've found in which the rubber hits the road. It is rigorous in its coverage of major language models, but its an actual tool as well.

Other than the obvious Cormen, Leiserson, and Rivest (plus Stein these days, apparently): http://en.wikipedia.org/wiki/I... [wikipedia.org]
I found H. J. Tichy's _Effective Writing for Engineers, Managers, and Scientists_ very useful.
I haven't finished _Hacker's Delight_ by Henry S. Warren, Jr., but there's some good stuff in there.

Knuth is of course a valuable addition to the book-shelf — as others have pointed out, it's a superb source for chasing up information, details and citations for algorithms and data structures one needs to justify or investigate, if nothing else.

Computational Geometry [amazon.com] by de Berg et al.: computational geometry techniques have a habit of turning up all over the place in CS and computing more generally, and this is probably the best overview text, providing motivating examples, a good high level theoretical discussion, and pseudo-code.

How about C. H. Lindsey's Informal Introduction to Algol 68? Obviously he isn't going to be using Algol 68, but this is beautifully and wittily written, describes a language with some interesting features, and has a very unusual two-dimensional organization.

For me, it was "Thinking Forth" by Leo Brodie. Forth is a pretty unique language, barely above assembler level, but able to (quickly) build up code/data structures of Lisp-like complexity (and like Lisp, can self-modify). Brodie's Thinking Forth pulls apart how you'd solve problems with procedural language and completely re-factors them to take advantage of how Forth works.

Even if you don't ever use Forth (and most of us enthusiasts never did for anything but school and our own utilities), learning it changes your thinking. But I'd concede that Forth itself isn't the necessity - it's to learn languages and approaches that solve problems in whole different ways. There should be books on functional languages, APL, or Lisp.

I'm not sure what the classic list would be - but for me, Starting Forth I pull off the shelf decades later to peruse when I need to pull my head outside the box. (It's now available as a free PDF, by the way.)

The book that had the greatest influence om me was Domain Driven Design, by Eric Evans.It really made the difference from thinking like a developer, to thinking like an architect (I still write code every day)

Helps you understand what goes on inside a computer at the hardware and OS level, as well as illustrating how you can reason about the performance of a system before you actually build it.

Computer Graphics: Principles and Practice by Foley & van Dam

A good starting point for learning about computer graphics. Not all of it is still relevant, but even if you skip the chapters about vector displays and user interfaces there is still plenty of useful material in there.

Programming: The Derivation of Algorithms by Kaldewaij

Teaches a way of constructing algorithms that are provably correct. Although I rarely follow this approach to the letter (it is very time consuming), elements of it are extremely valuable in everyday programming. For example, thinking in terms of preconditions, postconditions and invariants (design by contract) helps in designing good interfaces, finding bugs, placing useful asserts etc. Even just thinking to yourself "could I prove this program?" without actually doing it is useful, since if the answer is negative, the program is too complex and probably incorrect.

It was part of my required reading for a computer ethics course. Very entertaining.
You really empathize with this college sys admin who is battling an unknown adversary trying to gain access to systems he is responsible for. Throw in the love story as a background and I still remember it to this day.

I suggest Richard Feynman's Lectures on Computation. People in the physics world will know the name, but the topics covered are great for CS/CE topics, and probably not things that were considered and/or covered in regular classes.

It condenses decades of pain/suffering/learning concisely and provides a framework for many of the things that I've learned and experienced but had to rediscover all too often.

If you plan on starting a software company, being a critical part of a startup, or scaling someone's product - you had better read it - it will likely save you huge amounts of time, money, effort, and risk.

There is no good example of a CS book, well language references like "The C Book" are great for a single language, no CS book can cover all languages. Simply put, if you want a good CS book, pick a language and find the reference manual for that language.

nonsense, good books about OS and language design, compiler theory, algorithms, information theory: those are good for decades.

The contents are but it is irrelevant because you will never read them; anything they might say has been said a thousand ways on the internet.

I have all the "good" books on all those topics from my CS courses. I have not opened them in a decade or longer, despite doing a number of things quite relevant to the topics listed. They do indeed make nice shelf decorations...

anything they might say has been said a thousand ways on the internetBy people who once had a couple conversations with someone who took a class loosely based on the book (who probably ought not be saying much on the subject to those trying to learn it for real).

It's an even bigger joke is when you get quizzed in interviews by mindless retards who expect you to have memorized all the worthless "patterns" in the book. And god forbid if you ever look at the code these same idiots write. They make the OpenSSL codebase look like the greatest thing ever. If you ever though C macros could be used for ungodly amounts of obfuscation and indirection one only needs to look at the AbstractFactoryFactoryBuilderFacades that these "patterns" people write.

It would be more correct to say that it's "classically" misunderstood. GoF is fundamentally a dictionary, but too many people understand it to be a recipe book.

A 1000 times this. People seem to very frequently misundertand that GoF is a book on nomenclature. They give names to common patterns that exist in good software development. These patterns exist because they are useful and they come up time and time and time again. If you write software you will almost certainly implement a number of these patterns,

Well it certainly does include denotational semantics of programming languages. And there's no better way to really master that, than to learn and use a representative language of each of the major types;-)

Getting a denotational semantics right takes a lot more than familiarity with programming in the kind of language you're specifying. You might be better served by reading up on order theory and logic (get a text that's really pedantic about everything).

That would be true if programming languages defined in the Scott-Strachey way, which pretty much nobody does these days. The ones that do formalise their semantics tend to do so either based on an abstract machine (see Pierce's Types and Programming Languages as mentioned in the summary), or categorically.

I wouldn't usually respond to such a blatant troll, but the level of personal insecurity you demonstrate can only be the result of being rejected by your mother when trying to obtain milk. Seek some help.

If you can get into fucking grad school shouldn't you know this? What the fuck? I can't get in because you need 4 fucking references but at least I know CS theory...

Anyone with a BS degree can get into grad school. Perhaps not MIT or Stanford, but all but the top CS program in my state have no entrance criteria above just filling out an application (and the top program is not in a metropolitan area, so forget studying there while working).

ugh...I don't want to sound cross but "usability" texts have a long way to go..."computing" isnt about the "computability function"...its' about a user task...if there is no user in the chain somewhere then it's pointless

"usability" is really "human/machine interaction" of a specific instance and context...most texts talk only about those instances of design questions in a context, not the *theory*...any book or "U/X" theory that doesn't start with a *cybernetics* or system science perspective is doomed to

You absolutely do not need real/complex analysis to read 95%+ of Knuth's TAoCP. Even a math illiterate can read easily 50% of TAoCP with just a little patience, and that 50% is still way beyond what any other book will cover. Of course, whether it's worth spending this time is, as you pointed out, not obvious.

There are many more current topics; particularly, I'd plug statistics and data mining. A solid understanding of advanced statistics combined with strong algorithmic skills (coding, analysis, design, wh