Adrian Banner's The Calculus Lifesaver is an excellent companion text as well. It's not really a textbook, but it's a great reference to help you alongside it that's written in a way meant to be accessible to introductory students.
Stewart, Calculus, at a mere $285. Or like $5 for the fifth edition. He's very readable.
Strang is a fine lecturer, especially his Linear Algebra videos. But Linear Algebra Done Right is much better than Strang. MIT, Stanford and Berkeley agree on this one thing.
This may be the best book and it's great that you can download it for free, but it's scanned, and that makes it horrible to read. Still I marked it in my book list under math, and hope I'll find the time to read it in the future. I will buy a decent EPUB or PDF then. I don't mind to pay for that convenience.
Lang's "Short Calculus" (a reprint of the 1st edition of his calculus textbook) is a welcome change from those 2234th edition doorstop textbooks that make calculus into a boring parade of examples, where the goal of the game seems to be becoming an ace at pattern-matching.
More recent, more idiosyncratic but quite nice is T.W. Körner's Calculus for the Ambitious. I could see a motivated high-schooler learn calculus from this.
I used calculus book that written by Mathematics department of my university. Beside that, I read Calculus book by Purcell et al. [1]. This book is a good choice for supplement and exercise.
Some people are able to do it. But most are exaggerating or not doing the exercises. It takes me weeks to properly finish a good technical book due to time constraints. Either way, just do your best and forget about anybody else.
It probably isn't if you're coming at the material for the first time, or after a long break. I took a 15-week course in Linear Algebra a few months ago, and we only covered about half the book in that time. I spent just about every weekend and evening doing those exercises. It's very time consuming.
However, if you gave me my old College Algebra book, I might be able to skim through it in a month of weekends and refresh myself on most of it, because I've used that stuff a lot in various jobs. Same goes for a lot of (but by no means all) programming books. I'm immersed in that stuff daily, so I can get through it pretty quickly.
I rarely "finish" a technical book. I instead skim over it once or twice and then keep it on hand as a reference. Some books are indeed worth reading front-to-back and in-depth, but usually the use as reference material is more important to me.
Dan Luu's style is so impressive for his ability to be super objective about pros and cons of things. There's a post he wrote where he traces his career and lists out possible missteps and successes. His ability to dispassionately look at situations and evaluate them on their merits rather than allow their connotations into his judgement is quite enjoyable to read.
Can you link to his post tracing his career. I often wonder how others have made decision to make career choices, and what they think of their past decisions.
It's good for other field too. I've know union Electricians who didn't know how a three way switch works. They could wire it, but couldn't conceptualize it. Same with relay, and transformers.
It wasen't there fault. They just weren't taught it in the right fashion.
I do feel the book is dry though. I don't feel you need to read it front to back. I personally got more out of the diagrams, than the writing.
(My pet peeve in most technical books is the apparent lack of editing. If anyone is on the road to writing a technical book; there is nothing wrong with short books. People will pay for short books. Less is more--much of the time.)
The best introduction to optimization methods book I've ever read is "Optimization by Vector Space Methods" by Luenberger. This is the book that opened my eyes to the generality of least-squares methods, the actual geometry of the problem, and how to apply it extremely generally. I read this before Boyd and Vanderberghe's "Convex Optimization", and I'm glad I did - it goes much more deeply into the intuition and exposition. It's not as well known as it should be, but it's a complete gem.
"If I’m writing grungy low-level threading
code today, I’m overwhelmingly like to
be using c++11 threading primitives, so
I’d like something that uses those instead
of semaphores,"
But as someone whose lowest-level experience of concurrency is with APIs similar to the C++ primitives (which are not that different from pthreads), I disagree. I found it a real eye-opener to see how all this can be broken down to semaphores.
I am starting to think that a semaphore-only set of primtives would be easier to reason about. I've seen better coders than me make over-complicated mutex based solutions when sempahores gave a simple answer. And I bet I've done it too.
I totally agree. I've spent way too much time in the depths of terrible embedded operating systems trying to do basic synchronisation out of whatever terrible primitive they'd decided to implement instead of semaphores, when semaphores would be so much easier.
(Frequently I ended up just implementing semaphores, and then doing everything else in terms of those, frequently using a standard library I had precisely for that purpose...)
(Embedded device flashback moment: a mobile phone OS where the only concurrency primitive was a mutex, each of which contained a fixed-size buffer of waiting tasks. The size of the buffer was smaller than the number of tasks on the system, and if a task blocked on the mutex while the buffer was fill, another task would randomly wake up.)
When you use pthread semaphores, be careful reading the documentation, because there are some gotchas that are not immediately obvious. I think that's why more programmers don't use them, because at first they seem intimidating.
> This book agrees with my biases and I’d love for this book to be right, but the meta evidence makes me want to re-read this with a critical eye and look up primary sources.
Too true. Peopleware did not live up to my expectations. It's very light on evidence, has the chapter flow of a monthly-newsletter-turned-book, and contradicts itself in a few places without blinking an eye.
I like Hennessy and Patterson Computer Organization more than their Computer Architecture, especially the last edition. I'm looking forward to reading the ARM version of COAD:
I own the ARM version. I have enjoyed reading it, but if I recall correctly, most of the chapters are the same, and the few that do mention ARM kind of mention that ARM is similar to MIPS and then proceed with the old MIPS content.
It never goes deeply into ARM architecture.
I would like to see a true rewritten version for ARM.
I assume you mean the "Modern Processor Design: Fundamentals of Superscalar Processors" by Shen and Lipasti. I agree that is a great book to read. Just quite an expensive book for a casual reading. I was fortunate to get it cheap at a local used book store.
The idea is good: a list of general topics, a "why should you care" section for each (the part I really liked) and a few specific titles.
I would love an expanded list of topics (the current one is short) e.g., compilers, comms, security, Arduinos/ raspberry Pi / IoT. I personally did not like long lists of specific books -- I'd rather know about the topic and browse bookshelves at a Barnes and Noble to pick a couple that I like, but that's just my preferences.
> This book seemed convincing when I read it in college. It even had all sorts of studies backing up what they said. No deadlines is better than having deadlines. Offices are better than cubicles. Basically all devs I talk to agree with this stuff.
> But virtually every successful company is run the opposite way. Even Microsoft is remodeling buildings from individual offices to open plan layouts. Could it be that all of this stuff just doesn’t matter that much? If it really is that important, how come companies that have drank the koolaid, like Fog Creek, aren’t running roughshod over their competitors?
> For a lot of products, the sales team is more important than the engineering team.
Put another way, every measure of engineer / software quality and project success (including the qualitative ones that are harder to measure) like delivering on time / under budget, correctness of implementation, system performance, uptime / reliability, number of bugs, ease of maintenance, minimal technical debt, etc. etc., are very often only nice-to-haves. Not necessarily all of them at all times, but often enough most of them except one or two (not the same one or two, though).
Which is a good thing, or startups would never be able to trade off covering edge and corner-cases, or scale, or 'standard' feature-completeness, etc. in favor of new and game-changing capabilities (or business models) & incumbents could never be disrupted.
But as it happens, we know that 'worse is better' in lots of ways and in lots of circumstances. So companies that 'drink the kool-aide' and focus on developer productivity and happiness may produce 'better' software by any and all measures you care to use as a developer, instead of focusing on only the most important ones that directly relate to optimizing the customer acquisition funnel and subsequently reducing customer churn.
At the level of the corporation, programming is a competitive sport, but companies are not scored on software quality, or developer productivity, or developer happiness. Companies are only scored on 'getting and keeping customers' and 'making a profit' (which may require paying attention to some quality measures, just not all of them all the time).
Put yet another way: If you're doing Lean Startup / Customer Development right, the customer decides what 'quality' means, not you.
These type of lists have nothing to do with efficient learning. In the information age we have more available information than time. Knowing how to learn is the multiplication factor. If you do your due diligence these lists quickly becomes anecdotal.
Personally, my favorite algorithms/data structures books is Algorithms 4th ed by Sedgwick and Wayne. It does a great job explaining the material from a theoretical standpoint, but also focuses on practical application in addressing real problems, and every algorithm comes with real, working Java code that in some cases is even superior to the implementations in the standard Java libraries.
And it perfectly accompanies Sedgwick's free algorithms course on Coursera.
I saw that he mentioned that he got the book off of an author's website for free and went looking for it -- found Dr. Vazirani's site and course page[0]. He mentions that it's available for download because at the time of writing, it wasn't found in bookstores.
Berkeley, in the meantime, has deliberately blocked access to the linked algorithms.html[1], as well as the root directory of the algorithm PDF files, suggesting to me that this is not an actual "free" book.
If anyone knows otherwise, I'd love to hear about it since I love free books.
Can anyone recommend a good book about compilers? I just watched Martin Odersky's talk from Scala World [1] where he talks about the new Scala compiler he is working on called Dotty [2], but he talks a bit about other compilers and now I am interested to learn more.
Could anyone weigh in on his assessment of Martin Fowler's Refactoring book? I'm considering picking it up - some seem to be of the opinion that its ideas are old news in 2016 and there's not much to learn from it, others say there's still lots of useful information.
It's still extremely relevant and useful. Once you've read it cover-to-cover, it remains useful as a reference. I would also recommend Michael Feathers "Working with Legacy Code".
I'm surprised the author didn't include Axler's Linear Algebra Done Right under the math section considering how fundamental linear algebra is to so many domains of computer science.
Cool to see lots of comments on real life algorithm applications, if anyone is interested in diving deeper there's a good book that came out recently called "Algorithms to Live By" by Brian Christian and Tom Griffiths. It talks about how we often use CS algorithms in real life without knowing.
[+] [-] jcoffland|9 years ago|reply
https://ocw.mit.edu/resources/res-18-001-calculus-online-tex...
[+] [-] Bluestrike2|9 years ago|reply
http://press.princeton.edu/titles/8351.html
[+] [-] CalChris|9 years ago|reply
Strang is a fine lecturer, especially his Linear Algebra videos. But Linear Algebra Done Right is much better than Strang. MIT, Stanford and Berkeley agree on this one thing.
http://www.linear.axler.net/
The abridged version sans proofs is available in PDF:
http://linear.axler.net/LinearAbridged.pdf
[+] [-] hollander|9 years ago|reply
[+] [-] apricot|9 years ago|reply
More recent, more idiosyncratic but quite nice is T.W. Körner's Calculus for the Ambitious. I could see a motivated high-schooler learn calculus from this.
[+] [-] 0x54MUR41|9 years ago|reply
I used calculus book that written by Mathematics department of my university. Beside that, I read Calculus book by Purcell et al. [1]. This book is a good choice for supplement and exercise.
[1]: https://www.amazon.com/Calculus-Differential-Equations-Dale-...
[+] [-] wycx|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] questionr|9 years ago|reply
But I don't see how thats possible if it includes completing all (or even most of) the given exercises. Especially when you have a full-time job.
[+] [-] asimuvPR|9 years ago|reply
[+] [-] peruvian|9 years ago|reply
An hour or so every day is much better and realistic.
[+] [-] cruise02|9 years ago|reply
However, if you gave me my old College Algebra book, I might be able to skim through it in a month of weekends and refresh myself on most of it, because I've used that stuff a lot in various jobs. Same goes for a lot of (but by no means all) programming books. I'm immersed in that stuff daily, so I can get through it pretty quickly.
[+] [-] yellowapple|9 years ago|reply
[+] [-] lamby|9 years ago|reply
[+] [-] andrew_wc_brown|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] questionr|9 years ago|reply
[+] [-] ambulancechaser|9 years ago|reply
Also his talk at strange loop was spectacular.
[+] [-] chamakits|9 years ago|reply
[+] [-] bosie|9 years ago|reply
[+] [-] nickpsecurity|9 years ago|reply
[+] [-] zump|9 years ago|reply
[+] [-] lisper|9 years ago|reply
https://www.amazon.com/dp/B00JDMPOK2/
Takes you from simple mechanical switches all the way to a CPU.
[+] [-] unethical_ban|9 years ago|reply
[+] [-] marincounty|9 years ago|reply
It's good for other field too. I've know union Electricians who didn't know how a three way switch works. They could wire it, but couldn't conceptualize it. Same with relay, and transformers.
It wasen't there fault. They just weren't taught it in the right fashion.
I do feel the book is dry though. I don't feel you need to read it front to back. I personally got more out of the diagrams, than the writing.
(My pet peeve in most technical books is the apparent lack of editing. If anyone is on the road to writing a technical book; there is nothing wrong with short books. People will pay for short books. Less is more--much of the time.)
[+] [-] cscheid|9 years ago|reply
[+] [-] adrianratnapala|9 years ago|reply
"If I’m writing grungy low-level threading code today, I’m overwhelmingly like to be using c++11 threading primitives, so I’d like something that uses those instead of semaphores,"
But as someone whose lowest-level experience of concurrency is with APIs similar to the C++ primitives (which are not that different from pthreads), I disagree. I found it a real eye-opener to see how all this can be broken down to semaphores.
I am starting to think that a semaphore-only set of primtives would be easier to reason about. I've seen better coders than me make over-complicated mutex based solutions when sempahores gave a simple answer. And I bet I've done it too.
[+] [-] david-given|9 years ago|reply
(Frequently I ended up just implementing semaphores, and then doing everything else in terms of those, frequently using a standard library I had precisely for that purpose...)
(Embedded device flashback moment: a mobile phone OS where the only concurrency primitive was a mutex, each of which contained a fixed-size buffer of waiting tasks. The size of the buffer was smaller than the number of tasks on the system, and if a task blocked on the mutex while the buffer was fill, another task would randomly wake up.)
[+] [-] ktRolster|9 years ago|reply
[+] [-] jldugger|9 years ago|reply
Too true. Peopleware did not live up to my expectations. It's very light on evidence, has the chapter flow of a monthly-newsletter-turned-book, and contradicts itself in a few places without blinking an eye.
[+] [-] gmfawcett|9 years ago|reply
[1] https://www.reddit.com/r/csbooks/
[+] [-] CalChris|9 years ago|reply
I like Hennessy and Patterson Computer Organization more than their Computer Architecture, especially the last edition. I'm looking forward to reading the ARM version of COAD:
https://www.elsevier.com/about/press-releases/research-and-j...
[+] [-] optymizer|9 years ago|reply
I would like to see a true rewritten version for ARM.
[+] [-] pkaye|9 years ago|reply
[+] [-] ptero|9 years ago|reply
I would love an expanded list of topics (the current one is short) e.g., compilers, comms, security, Arduinos/ raspberry Pi / IoT. I personally did not like long lists of specific books -- I'd rather know about the topic and browse bookshelves at a Barnes and Noble to pick a couple that I like, but that's just my preferences.
[+] [-] abecedarius|9 years ago|reply
[+] [-] suprfnk|9 years ago|reply
[+] [-] masteruvpuppetz|9 years ago|reply
[+] [-] webmaven|9 years ago|reply
> This book seemed convincing when I read it in college. It even had all sorts of studies backing up what they said. No deadlines is better than having deadlines. Offices are better than cubicles. Basically all devs I talk to agree with this stuff.
> But virtually every successful company is run the opposite way. Even Microsoft is remodeling buildings from individual offices to open plan layouts. Could it be that all of this stuff just doesn’t matter that much? If it really is that important, how come companies that have drank the koolaid, like Fog Creek, aren’t running roughshod over their competitors?
The answer is in another recent post (http://danluu.com/sounds-easy/#fn:S):
> For a lot of products, the sales team is more important than the engineering team.
Put another way, every measure of engineer / software quality and project success (including the qualitative ones that are harder to measure) like delivering on time / under budget, correctness of implementation, system performance, uptime / reliability, number of bugs, ease of maintenance, minimal technical debt, etc. etc., are very often only nice-to-haves. Not necessarily all of them at all times, but often enough most of them except one or two (not the same one or two, though).
Which is a good thing, or startups would never be able to trade off covering edge and corner-cases, or scale, or 'standard' feature-completeness, etc. in favor of new and game-changing capabilities (or business models) & incumbents could never be disrupted.
But as it happens, we know that 'worse is better' in lots of ways and in lots of circumstances. So companies that 'drink the kool-aide' and focus on developer productivity and happiness may produce 'better' software by any and all measures you care to use as a developer, instead of focusing on only the most important ones that directly relate to optimizing the customer acquisition funnel and subsequently reducing customer churn.
At the level of the corporation, programming is a competitive sport, but companies are not scored on software quality, or developer productivity, or developer happiness. Companies are only scored on 'getting and keeping customers' and 'making a profit' (which may require paying attention to some quality measures, just not all of them all the time).
Put yet another way: If you're doing Lean Startup / Customer Development right, the customer decides what 'quality' means, not you.
[+] [-] adamnemecek|9 years ago|reply
[+] [-] kodiera|9 years ago|reply
For a more thorough understanding I would recommend Donald Knuth's "The Art of Computer Programming".
[+] [-] uola|9 years ago|reply
[+] [-] hal9000xp|9 years ago|reply
Unlike TAOCP and CLRS it's actually readable in realistic amount of time.
This book is also very good at explaining theoretical computer science. In particular - NP completeness.
Official copy is available at home page of Umesh Vazirani at berkeley.edu:
0: Prologue - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap0....
1: Algorithms with numbers - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap1....
2: Divide-and-conquer algorithms - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap2....
3: Decompositions of graphs - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap3....
4: Paths in graphs - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap4....
5: Greedy algorithms - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap5....
6: Dynamic programming - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap6....
7: Linear programming and reductions - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap7....
8: NP-complete problems - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap8....
9: Coping with NP-completeness - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap9....
10: Quantum algorithms - https://people.eecs.berkeley.edu/~vazirani/algorithms/chap10...
[+] [-] gautamnarula|9 years ago|reply
And it perfectly accompanies Sedgwick's free algorithms course on Coursera.
[+] [-] sdrothrock|9 years ago|reply
Berkeley, in the meantime, has deliberately blocked access to the linked algorithms.html[1], as well as the root directory of the algorithm PDF files, suggesting to me that this is not an actual "free" book.
If anyone knows otherwise, I'd love to hear about it since I love free books.
[0] http://www-inst.eecs.berkeley.edu/~cs170/fa06/
[1] http://www.cs.berkeley.edu/~vazirani/algorithms.html
[+] [-] tylerpachal|9 years ago|reply
[1] https://www.youtube.com/watch?v=w1ca4KL9UXc
[2] http://dotty.epfl.ch
[+] [-] syncopatience|9 years ago|reply
[+] [-] blowski|9 years ago|reply
[+] [-] eachro|9 years ago|reply
[+] [-] anthnguyen94|9 years ago|reply
If you want a glimpse here's a talk they gave at Google: https://www.youtube.com/watch?v=OwKj-wgXteo