Stevens (APUE and Network Programming) doesn't hold up. You'd do better with Beej. They weren't all that great even at the time; what they were were book-length treatments of the topics that you could reasonably expect to find on the shelf in a suburban Borders bookstore. Even the motivation for those books is obsolete!
Varghese is much too situational a book for this list; it's like bringing a trebuchet to your street fight. It's a book about building dedicated middleboxes. You can Google the title and get the PDF of the whole book on the first search result page. I like it a lot but I can't imagine sending anybody to it.
I will give the list this: Hanson is probably the best general-purpose C programming book. Of course, part of that is that almost nobody writes general-purpose programs in C anymore.
Stroustrup, on the other hand, is like being one of those flashy sword fighters in the souk in Cairo in Raiders of the Lost Ark. Indiana is just going to shoot you before you make it through the first chapter.
Axler is not the linear algebra book I would take to a street fight. Nobody writes proofs in a street fight. You want Strang.
Maths aside --- you need the exercises at the ends of the chapters to get anywhere with math --- I'm not sure books are really the thing anyways. I can quickly think of things I've learned by doing (and being taught while doing), but not a lot of things I feel like I meaningfully picked up because I read it in a book. Excepting maybe Hanson's C book, which definitely did change the way I wrote C. (Alexandrescu's book changed the way I wrote C++, but it also set me on a rapid trajectory out of C++).
> Stevens (APUE and Network Programming) doesn't hold up.
> They weren't all that great even at the time
I can’t say I agree with this. Stevens’ books have always been a go to for me for ever. They don’t have great coverage on more recent topics like Anycast and Multicast, so probably outdated at this point, but I can’t think of a single author who taught me more about network and unix/posix programming. All of the concepts transferred well into Java and Rust after it for me. I’m eternally grateful for Stevens’ work.
Hell yeah you want Gilbert. Watching the guy's MIT lectures is a joy and the gumby-colored book reads like a narrative. I wish my calc books were as well written, else I'd not be reviewing vector calc with some intensity in my 30s.
That said, I have to recommend "Div, Grad, Curl, and All That" as I believe that I found it through someone's random comment here and it was a stellar find. I've realized I'm rather rusty on these topics and this book is very assertive of its target audience.
Networking Algorithmics is a weird one. I haven't looked much at the new edition, but back about ten years ago (yeesh) I kept tripping over the first edition of that book by accident, and then referring to it. I never read it cover to cover. In what I feel is a decent test for a book, it was the best at explaining a few specific concepts that other books which were searchable using O'Reilly's online library barely touched on. I bet that might still be the case.
When I needed a refresher for socket programming back in that same timeframe, I divided my time pretty evenly between Stevens, Beej, and Kerrisk. I get why people felt so much reverence for Stevens when it came out, but I also get why Beej's guide came about later on, as a more straightforward option. Kerrisk is just amazing, but I bet some would find it to be overkill. I suppose it aims to inhabit some of the space Stevens did, and it's undeniably a lot better.
You mention needing exercises after each chapter for maths, but I find this lacking in far too many technical books I pick up. Most of them take the "good enough" approach were the chapter exercise is really just some limp-wristed vocab quiz, and that's if there's an attempt to get the reader to use the practice at all. It's wildly disappointing and such a waste of the readers time to do that. I wish technical authors would get a clue.
> I'm not sure books are really the thing anyways
I agree, here, although I still like to have books for offline reference and general brush-up in my downtime. That said, do you recommend any non-book sources for maths pertaining to CS? You seem to have good suggestions otherwise, so I figured I'd ask.
Alexandrescu's "Modern C++ Design" is a collection of mostly impractical "clever" tricks that should be avoided in most situations. Like design patterns books, none of its advice should be used unless it solves a real problem that you noticed while not looking for a place to use the technique you just read about.
I kinda hate the book, it's about the exact opposite of what I consider good programming: trying to make complicated things look simple.
For what it's worth, I agree; I don't think Alexandrescu changed my C++ for the better, but it did sort of serve as an object lesson for overly nerding out on PL capabilities.
Reading the O'Reilly Perl book when I wanted to get more serious about programming did something similar for me. I knew very little at the time, but enough to conclude that Perl is the opposite of what I want.
great feedback; i shall check out Beej and see what's up. it was many years ago that i learned my basic UNIX work.
networking algorithmics is a classic, and there's nothing else quite like it. i stand by that one for sure. he also has a lot of the great networking algorithms in there that you can't get collected anywhere else.
haven't looked at strang, either--axler did well by me!
appreciate the informed and quality comments. --nick
You didn't call him an "anti-vax conspiracy nutso" in the first comment, you said he was "pretty insane based on his tweets" with no other context (though I, and probably others, found the anti-vax stuff based on looking it up). (I didn't downvote/flag it, but I'm not vouching/upvoting it either, this comment is much better than your first.)
As to turning a dissertation into a book, it's sufficiently common that universities like Georgetown have content like this on their university library site referencing other major universities: https://library.georgetown.edu/scholarly-communication/etds-...
I really would like to street-fight with TAPL and Purely Functional Data Structures. Imagine a different world where competitive programming is about proving theorems in Coq and people play with finger trees instead of segment trees.
I'll have you know that Pugs, the first implementation of Perl 6, was written as a result of Audrey Tang reading TAPL and then getting interested in Haskell. Audrey was at that time known as Autrijus but she later underwent a sex change. I guess I'm no longer allowed to joke "this is what Perl 6 does to people".
Are there really people who actually read this many textbooks? I read half the textbook “Rigid Body Dynamics Algorithms” and it took a couple months. And I had time because I read it for a research project in grad school. I can’t imagine going home after work and grinding these textbooks for years.
> eventually only read vol 2 because I was interested in (pseudo) random number at that time
Your comment comes at the perfect time, I am looking at learning about random number functions and tests of randomness myself. Do you have any other resources about these topics?
Some statistics books, perhaps? I think there are some references on them. I don't study random numbers anymore because my interest changed few years ago.
Needs a database book (suggestions?), an OS book, (Silberschatz, Galvin, and whatever coauthors they have by now, maybe Tanenbaum as well) and a graphics book (Foley and van Dam, again plus however many coauthors they have by now).
Someone else suggested a machine learning book. I'd agree, except I doubt there are any books out that give enough coverage to the LLM stuff that's exploding everywhere. That stuff is still coming out in academic journals, not textbooks. Maybe in five years.
I've been using Xournalpp[1] for many years, highlighting books as I read them, adding in text/hand drawn annotations in whitespaces if necessary. Unlike other PDF readers/annotators, it saves a separate file, so the original PDF is untouched. It can also export the annotated PDF as a new PDF with highlights and annotations. I've used Xournalpp with a convertible laptop with a builtin digitizer+pen, but you can also use it with a mouse to highlight stuff, drawing would be awkward with a mouse though.
Obsidian[2] also has PDF support, where you can open a markdown document side by side with the PDF to take notes as you read. I think it also lets you highlight the PDF itself.
Emacs I think has a similar feature, via plugins/org-mode(?) to the Obsidian setup.
And of course your typical PDF reader probably has support for highlighting PDFs too, but I find them clunky and they save by exporting a PDF, which can be a bit heavy-handed IMO compared to just saving the annotations/highlights as a separate file as Xournalpp does.
> Unlike other PDF readers/annotators, it saves a separate file, so the original PDF is untouched.
Just to give people another perspective on these issues [edit: not to deny the parent's perspective, just to add another]:
In PDFs, annotations are effectively (or actually?) on a separate layer from the document. It's not like marking up a paper book; in a PDF the annotations leave the original untouched, and can be easily hidden or removed.
Another advantage of using PDF annotations is that they are retained, readable, and editable for decades. There's no other file to retain. And if Xournalpp stops being developed, what happens to your annotations?
Fair enough. I was providing alternatives, not prescribing a single solution. You'll notice I said what I use and also provided suggestions that I don't use.
Xournalpp uses layers as well, hiding annotations is also possible there.
Just a different solution to the same problem.
Xournalpp, is free and open source. It is actually a fork of an older software called Xournal. If it stops being developed, C++ compilers aren't going anywhere, I'll compile it myself -- beyond that it's just pedantic to discuss what and what won't be possible in decades.
PDF readers on the other hand, especially proprietary ones have a bad habit of, for lack of a better word, enshitifying (cloud, saas, subscription, etc). I've had PDF a editor corrupt my PDF as well (sample size 1, so not indicative of all PDF editors), my fault for not having backups I suppose, but I've avoided them since.
But whatever works for you, I'm not here to dictate what you can or should use. Just providing ideas as the OP originally asked in the root comment.
Anyhow, the only solution that will survive ultimately is plain text. All others rely on abstractions upon abstraction (C++, compilers, libraries, etc). Plaintext is bits and bytes you can decode by hand if you wanted.
> Fair enough. I was providing alternatives, not prescribing a single solution.
Yes, I agree completely. Sorry that I gave a different impression.
> Xournalpp, is free and open source. It is actually a fork of an older software called Xournal. If it stops being developed, C++ compilers aren't going anywhere, I'll compile it myself -- beyond that it's just pedantic to discuss what and what won't be possible in decades.
Few users will compile anything, and eventually incompatibilities arise between the application and the latest platform. My PDF reader functions fine with documents that are decades old - that is part of the PDF specification; it's not pedantic, it's deliberately and successfully engineered.
> PDF readers on the other hand, especially proprietary ones have a bad habit of, for lack of a better word, enshitifying (cloud, saas, subscription, etc). I've had PDF editors corrupt my PDF as well, my fault for not having backups I suppose, but I've avoided them since.
There are many, many PDF readers. I have no problem finding a good one (I agree, stay away from Adobe, which you seem to describe). Yes, I'd be careful with PDF editors - that's not really what PDFs are designed for afaik.
One of the nice things about Xournalpp is that is just plain XML (the save file). So its really just plaintext, I don't have to bother with reading hundreds of pages of PDF spec to try and write a reader in the future. If I needed to, I only need to write an application capable of rendering a PDF page, then drawing text/lines as described by the XML. Assuming libraries to render the PDF will continue to exist in this theoretical future we're describing here.
<stroke tool="highlighter" color="#00ff007f" width="7.86" fill="60" capStyle="butt">254.802 713.98302 283.955 713.98302</stroke>
<stroke tool="highlighter" color="#00ff007f" width="9" fill="60" capStyle="butt">283.955 714.01302 539.992 714.01302</stroke>
<stroke tool="highlighter" color="#00ff007f" width="0" fill="60" capStyle="butt">539.992 718.51302 539.992 718.51302</stroke>
<text font="Sans" size="8" x="456.87471" y="427.46622" color="#ff0000ff" ts="0" fn="">Here the first capture group is
`([\"'])`, which captures either a
`"` or a `'`. Then the `(.-)` lazy matches
any thing, and finally `%1` matches
the original type of (closing) quote</text>
</layer>
</page>
<page width="612" height="792">
<background type="pdf" pageno="95"/>
<layer>
<stroke tool="highlighter" color="#00ff007f" width="9" fill="60" capStyle="butt">120 78 169.674 78</stroke>
<stroke tool="highlighter" color="#00ff007f" width="7.86" fill="60" capStyle="butt">265.784 77.97 292.676 77.97</stroke>
<stroke tool="highlighter" color="#00ff007f" width="9" fill="60" capStyle="butt">292.676 78 397.442 78</stroke>
Very cool. One thing I dislike about PDFs is the complexity, and like you I do use text when possible (text files aren't so great if I want to annotate them, unfortunately).
Searching and bookmarking make navigation much faster and easier, including for cross-referencing, glossaries, etc.
Annotations are far more powerful; they are editable, copyable, come in many forms (highlight, underline, text boxes, draw, hyperlinks, etc etc.). You can type much faster and fit much more than you can write with a pen.
PDFs are of course far more portable, and they are durable over decades (esp. PDF/A).
I'll never study a book on paper again; it's just too inefficient, so much that it's not worth matching PDF functionality. I'll just wait however long it takes to obtain the PDF.
> Personally i find studying from a pdf basically impossible.
Agreed. Until and unless i can get a e-ink/e-paper display (minimum A4 size, 13" or more is better) which will not cause eye strain/fatigue it is impossible to read any kind of technical book electronically for long periods of time. And this i say as a person who owns a 27" iMac, a iPad, a Nexus10 and a couple of 10" and 16" inch laptops. I have a huge collection of technical books as pdfs which i only consult on my devices. For serious studying of any books i always get a paper copy; nothing else works.
I mentioned/implied three things; a) The nature of the display causing eye-strain/fatigue b) The size of the display being inadequate and c) The needs of a technical book/paper rendering. This trifecta has not been solved (i believe intentionally) by the Industry at reasonable cost. All i am asking for is A4 (or larger) size display using some technology which does not cause eye-strain/fatigue and some software which can render pdf/epub/whatever correctly.
My current setup is iBooks on iPad, MoonReader Pro on Android and Adobe on desktop/laptop none of which is optimal for reading/studying for long periods of time.
If i had to guess, its because i have never found highlighting particularly useful (whether in physical or digital form), and i generally find it easier to read things in order first and then go back to fill in gaps of understanding instead of constant cross referencing which breaks the flow of thought. So in essence i personally find most of the benefits of digital form is lost on me leaving just the downsides (not lugging around 100lb book would be nice though) But to each their own.
The point im trying to make is that there is no one true way. Reasons why probably aren't fully portable between people and blindly copying what other people do wont get you very far. What one should do is try all the different possibilities and figure out what works for yourself. There is no magic formula.
1) Read the ToC carefully to see what each chapter is about. Identify which chapters/sections are about "Concepts/Ideas" vs. "Implementation/Technology".
2) Read the book's Foreward/Preface/Introduction where the author(s) often lay out a plan of action for reading the book. This will give you the dependencies among the chapters and which are the most important so that you can decide on your path of action.
3) If the book has appendices/introductory chapter which lays out some needed background knowledge refresher in Mathematics/etc. read these first.
4) Go through each chapter's beginning introductory section and last summary section in sequence for all the chapters. Now you have an idea of what each chapter is about (motivation and summary) even though much is still unknown. Mark/Underline/Annotate key points/terms as needed.
5) Now from (1) & (2) you have a set of chapters/sections dealing with the fundamental "Concepts/Ideas" which is what you now start studying in sequence. Have paper and pencil handy to mark/underline/annotate the text and take notes as needed. You could use "SQ3R" (https://en.wikipedia.org/wiki/SQ3R) and "Cornell Note-taking method" (https://en.wikipedia.org/wiki/Cornell_Notes) as techniques.
6) Make another pass over (5) to better grasp the "Concepts/Ideas". For difficult to grasp subjects this might not be enough. Make a note of why; perhaps you still lack some needed background knowledge/Mathematics which you need to brush up on. Make sure you don't go too deep into tangents; sometimes it can be treated as a black box i.e you just need to know "what it is" and "how to use it".
7) Now with some understanding of Concepts/Ideas in hand go through the chapters sequentially looking at the "Implementation/Technology" sections. Follow and understand the logic of the solved examples/code snippets/etc. This will help cement your understanding.
8) Make another pass over (7) but now also work out some exercises from each chapter as needed. A lot of folks get hung-up on this in the early stages which is counter-productive. Only when you have some idea of the concepts involved will you find the motivation to do the exercises. Obviously, for Mathematical subjects this is of higher importance but even here go according to your comfort level and needs/wants.
Finally, keep in mind that Reading/Studying should be positive/enjoyable so that you keep doing it. Work around anything that makes you anxious/demotivated so you never get into a negative mental state when you think about studying. Your memories of learning should always be pleasant.
There’s some good ones here. But there’s also some that are deeply silly. The Barendregt book (I’m not even remembering the correct spelling) is definitely of no use for applied computer science, or most flavors of theoretical programming language work.
Anderson, Security Engineering (Wiley) would make an excellent addition to this list.
(The blog post omitted anything infosec saying the field is “part of QA” but it’s not like this list is pure CS — a lot of engineering topics aka “applied computer science” are on the list already.)
Security economics is important when building real world software because one has to know one’s enemy in order to decide what to defend against. It is literally the most “street fighting” topic in the field.
It's like 8 different and mostly unrelated disciplines, so, "hardware security", "software security", "vulnerability research", "exploit development", "software reverse engineering", "cryptography engineering", maybe "systems security" if you want to put OS security in a different bucket from software security. And then all the IT and risk management stuff (network security, corporate security, &c). This is off the top of my head. Most of this work is totally unlike QA.
Even the parts of it that are like QA (vulnerability research, say) are pretty unlike QA; the bugs you find in QA tend not to be driven by adversaries, so you get to work with a relaxed set of constraints. QA work is much more process-focussed, about repeatability and coverage, and less about detailed study of how systems work. In hardware and cryptography, the work closer in spirit to vuln research is called "verification".
There's superficial vuln research that any QA person can (and should! but probably doesn't!) do. But if "looking for bugs" is "QA", have fun explaining to people writing Tamarin proofs for protocols that they're just QA engineers.
None of this is to belittle QA work, which is very difficult to do well, and which has its own subfield of ideas and research and tooling and stuff.
Yes, it almost doesn't have any meaning at all as a term. It's an umbrella for a bunch of disciplines that are less similar than, say, QA and software development. It can also, as you intuited, kind of be a "tell" for people who aren't thinking seriously about the computer science of security. It isn't automatically, but it pretty clearly is when you're using it in the same breath as "security is just QA". It is the CISSP of terms.
Perhaps if all you want to do is write papers with lots of equations about algorithmic complexity, then Crochemore may be a fine choice. If you want to write papers with graphs showing your new library’s string processing bandwidth goes up and to the right (this is for street fighting, yes?), then you want Navarro and Raffinot over ol’ stuffy Crochemore.
i am not sure i agree some of those book are a bit too hardcore
- Knuth, The Art of Computer Programming
- Pierce, Types and Programming Languages
And its too unix focused, too systems or low level programming focused
there is a lot more to programming than mastering unix and c
I think this list needs
- A Python book
- A SQL book and a Relational DB book
- Some windows and unix admin books
- A book about testing and CI/CD
- A book about computer security
- A Machine Learning book
I get the impression the author of the list is the type of person who believes that if you master the hard core stuff the soft core stuff will come easily.
Varghese is much too situational a book for this list; it's like bringing a trebuchet to your street fight. It's a book about building dedicated middleboxes. You can Google the title and get the PDF of the whole book on the first search result page. I like it a lot but I can't imagine sending anybody to it.
I will give the list this: Hanson is probably the best general-purpose C programming book. Of course, part of that is that almost nobody writes general-purpose programs in C anymore.
Stroustrup, on the other hand, is like being one of those flashy sword fighters in the souk in Cairo in Raiders of the Lost Ark. Indiana is just going to shoot you before you make it through the first chapter.
Axler is not the linear algebra book I would take to a street fight. Nobody writes proofs in a street fight. You want Strang.
Maths aside --- you need the exercises at the ends of the chapters to get anywhere with math --- I'm not sure books are really the thing anyways. I can quickly think of things I've learned by doing (and being taught while doing), but not a lot of things I feel like I meaningfully picked up because I read it in a book. Excepting maybe Hanson's C book, which definitely did change the way I wrote C. (Alexandrescu's book changed the way I wrote C++, but it also set me on a rapid trajectory out of C++).