5 ms·

You are young and so forgiven to have not included as #1 the seminal works of Donald Knuth, "The Art of Computer Programming", still as relevant today as it was

by dwarman 12y ago

You are young and so forgiven to have not included as #1 the seminal works of Donald Knuth, "The Art of Computer Programming", still as relevant today as it was in the late 60's and 70's. What he described is to this day true of the underpinnings of all we do, everything since is really decoration and elaboration. And I say this as a still active systems developer, familiar with and working with current SOC systems from DSP coprocessors on up, not as an old fogey left by the wayside and complaining about the youngsters today. Although they really don't know what it took to get here.

santaclaus 12y ago
In the preamble the post discusses wanting to learn how to write enterprise-type code, but if we are going just good ol' CS books in general, no one can touch SICP. The definition of abstraction in there blew my mind.
- joshAg 12y ago
  SICP is amazing. The only bad thing I can say about it is that since it was my first CS textbook in college, it naturally became my measuring stick for "good CS book", which has nearly ruined most of the CS books I read.
- deleted 12y ago
  [deleted]
- eru 12y ago
  Having recently revisited SICP, I am not nearly as impressed anymore as I used to be when I worked through it as a teenager. It aged badly (or perhaps, I outgrew it).
- nemesisrobot 12y ago
  I can't say enough good things about SICP. I'm currently working my way through it, and it's such a joy. Watching Prof. Abelson and Sussman's recorded lectures from the 80's is equally enjoyable because they're such good lecturers; thought-provoking and engaging.
dwarman 12y ago
To my down-voter: TAOCP is essential foundation to understand the whys and wherefores of writing good code at any higher level; one must understand the mechanics and limitations of the systems one is using. Hoping for Moore's Law to save your performance is not the way to do things. Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed processing gotchas, etc etc, all play their part in writing efficient and effective code wherever. Languages are tools, all are Turing Complete and can do no more than any other; which to choose for any function is a matter of convention and convenience. And what coding style to use is convention, and how to integrate with other programmers, how to manage projects, "Best Practices" and Patterns, all are conventions, and the degree to which they make the difference is a function of the quality of the involved programmers abilities, not a function of the style chosen. Hence my characterization of all the above as "Elaborations and Decorations". Most of the earlier hardware list also fit into that characterization, but the idiosyncrasies of each ISA and core architecture can have enormous impact on the final products' performance and need proper attention. It is sad that after 50 years in the business I still know how these things work, and how to make them sing. It should not be so. But the technology has only gotten smaller and faster and has more immediate storage available and faster I/O and more elaborations and accelerations. No fundamental changes. Not that it doesn't blow my mind every so often, that what was a mere pipe-dream in the 60's is today mundane, or even so ubiquitous its underpinning have faded into the background. But it was pretty much already all down on paper in the 60's, just waiting on the capacity of technology SOA to catch up. The list presented contained very little if any fundamentals. And without the fundamentals, the knowledge garnered is rote, founded upon shifting sands. Thus, I posit the books from which one learned those fundamentals should occupy top place in any such list. The knowledge garnered shapes every future thought on the subject, shapes every problem solving approach, shapes how you think about computers and computing at an internalized level. In 50 years of commercial (if not commerce per se) experience (and continuing), every hire I've had the pleasure to work with has them, and every hire that frustrated and produced bad, unreadable, buggy, and inefficient code, did not. That we have today billions of transistors in the space once occupied by one, and clock cycles thousands of times higher, and communication rates trillions of times higher (potentially anyway), is no excuse for not understanding how it all fits together. Today we need to do more with what we have, and so resources are always limited. Possibly a derivative of Parkinson's Law at work. Instead all too often I see bloat and the hope that tomorrows' machines will fix things. Tomorrow never comes, it seems. As IIRC Piccasso (Dali?) is reputed to have told one young hopeful: "Come back to me when you can show me you can draw a straight line. Then I might believe those squiggles mean something".
Erwin 12y ago
For algorithms, I like Skiena's Algorithm Design Manual. That's a practical-oriented book, where theoretical learning is mixed with anecdotes about real life problems solved. The same cannot be said for TAOCP, but it certainly looks very good on a shelf. Practical usage? Limited. You don't need Knuth to learn basics of time complexity.

by dwarman 12y ago

santaclaus 12y ago

In the preamble the post discusses wanting to learn how to write enterprise-type code, but if we are going just good ol' CS books in general, no one can touch SICP. The definition of abstraction in there blew my mind.

joshAg 12y ago
SICP is amazing. The only bad thing I can say about it is that since it was my first CS textbook in college, it naturally became my measuring stick for "good CS book", which has nearly ruined most of the CS books I read.
deleted 12y ago
[deleted]
eru 12y ago
Having recently revisited SICP, I am not nearly as impressed anymore as I used to be when I worked through it as a teenager. It aged badly (or perhaps, I outgrew it).
nemesisrobot 12y ago
I can't say enough good things about SICP. I'm currently working my way through it, and it's such a joy. Watching Prof. Abelson and Sussman's recorded lectures from the 80's is equally enjoyable because they're such good lecturers; thought-provoking and engaging.

dwarman 12y ago

To my down-voter: TAOCP is essential foundation to understand the whys and wherefores of writing good code at any higher level; one must understand the mechanics and limitations of the systems one is using. Hoping for Moore's Law to save your performance is not the way to do things. Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed processing gotchas, etc etc, all play their part in writing efficient and effective code wherever. Languages are tools, all are Turing Complete and can do no more than any other; which to choose for any function is a matter of convention and convenience. And what coding style to use is convention, and how to integrate with other programmers, how to manage projects, "Best Practices" and Patterns, all are conventions, and the degree to which they make the difference is a function of the quality of the involved programmers abilities, not a function of the style chosen. Hence my characterization of all the above as "Elaborations and Decorations". Most of the earlier hardware list also fit into that characterization, but the idiosyncrasies of each ISA and core architecture can have enormous impact on the final products' performance and need proper attention. It is sad that after 50 years in the business I still know how these things work, and how to make them sing. It should not be so. But the technology has only gotten smaller and faster and has more immediate storage available and faster I/O and more elaborations and accelerations. No fundamental changes. Not that it doesn't blow my mind every so often, that what was a mere pipe-dream in the 60's is today mundane, or even so ubiquitous its underpinning have faded into the background. But it was pretty much already all down on paper in the 60's, just waiting on the capacity of technology SOA to catch up. The list presented contained very little if any fundamentals. And without the fundamentals, the knowledge garnered is rote, founded upon shifting sands. Thus, I posit the books from which one learned those fundamentals should occupy top place in any such list. The knowledge garnered shapes every future thought on the subject, shapes every problem solving approach, shapes how you think about computers and computing at an internalized level. In 50 years of commercial (if not commerce per se) experience (and continuing), every hire I've had the pleasure to work with has them, and every hire that frustrated and produced bad, unreadable, buggy, and inefficient code, did not. That we have today billions of transistors in the space once occupied by one, and clock cycles thousands of times higher, and communication rates trillions of times higher (potentially anyway), is no excuse for not understanding how it all fits together. Today we need to do more with what we have, and so resources are always limited. Possibly a derivative of Parkinson's Law at work. Instead all too often I see bloat and the hope that tomorrows' machines will fix things. Tomorrow never comes, it seems. As IIRC Piccasso (Dali?) is reputed to have told one young hopeful: "Come back to me when you can show me you can draw a straight line. Then I might believe those squiggles mean something".

Erwin 12y ago

For algorithms, I like Skiena's Algorithm Design Manual. That's a practical-oriented book, where theoretical learning is mixed with anecdotes about real life problems solved. The same cannot be said for TAOCP, but it certainly looks very good on a shelf. Practical usage? Limited. You don't need Knuth to learn basics of time complexity.