I've been collecting and researching science, math, physics, programming books since 2001 or 2002, so it's been close to 15 years of book research. I'm really passionate about high quality books. For every high quality book there are a thousand sloppy books and I want nothing to do with them. I'm only interested in books that have the highest value. I wouldn't recommend a book that I don't trust is really well written. That just wouldn't be me. I stand behind my recommendations.
This time I'm sharing my favorite books about Linux assembly programming, quantum physics and physics of computation, computational logic and inductive computer program proofs, and general Unix programming.
In one of the next posts I'll create a neat pdf with all the books listed so far and keep updating it as I write more posts. It will be a handy reference for quality books.
Here are this week's five books.
#21 Programming from the Ground Up (free pdf)
Programming from the Ground Up is a fantastic book to get into x86 assembler and assembly programming on Linux quickly. This book was published in 2004 but it doesn't make it outdated. The material in this book gives you fundamental knowledge about how Linux programs work and how to write them in GNU AS assembler.
Jonathan Bartlett wrote this book because he was frustrated to no end with the existing books. At the end of them he could still ask, "How does the computer really work?" and not have a good answer. Jonathan's goal is to take you from knowing nothing about programming to understanding how to think, write, and learn like a programmer. You won't know everything, but you will have a background for how everything fits together.
Even now in 2016 there are no better book to learn assembly than this one. At least I haven't seen one. Jonathan Bartlett has written a masterpiece. (If you know any fantastic recent (last 10 years) assembly books, let me know so I can evaluate them.)
The introductory will capture anyone who's interested in computers. It says:
Programming is like poetry. It conveys a message, not only to the computer, but to those who modify and use your program. With a program, you build your own world with your own rules. You create your world according to your conception of both the problem and the solution. Masterful programmers create worlds with programs that are clear and succinct, much like a poem or essay.
This book not just teaches assembly but also good programming style and philosophy of writing good programs. It says, "Your goal as a programmer is to solve the problem at hand, doing so with balance and taste, and teach your solution to future programmers." That's something programmers often forget or ignore. This book is filled with advice like this and even has a whole chapter on developing robust programs. It is a very didactic book.
I also really like this paragraphs from the book:
The difference between mediocre and star programmers is that star programmers understand assembly language, whether or not they use it on a daily basis. Assembly language is the language of the computer itself. To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works. To be a truly successful programmer, you have to understand exactly what the computer sees when it is running a program. Nothing short of learning assembly language will do that for you. Assembly language is often seen as a black art among today's programmers - with those knowing this art being more productive, more knowledgeable, and better paid, even if they primarily work in other languages.
Appendixes are very useful as well. There's one on common x86 instructions, difference between AT&T syntax and Intel syntax, important system calls, summary of using gdb, and C programming idioms in asm. C idioms in asm is the most awesome appendix.
I remember how I went through this book in 2004, a day before a job interview, and I exactly got asked a question about how C functions get compiled to assembly, how the stack and memory management works. I got that job.
Layout of the
Author: Jonathan Bartlett.
#22 Quantum Paradoxes: Quantum Theory for the Perplexed
I'm a huge fan of paradoxes, counter examples, thought experiments, and unexpected results. When I was studying physics I loved when the professors showed these things. They really made you jump in excitement, made you feel pleasantly eerie, they broke your brain a little bit and made you think a lot.
Paradoxes, thought experiments, accidents, toy examples, and counterexamples play a major role in scientific development. How did Einstein invent the relativity theory? He imagined chasing after a beam of light at the speed of light, and this thought experiment played a vital role in his development of special relativity.
This book is a super fun, graduate-level physics book. It's designed for physics students, physicists and philosophers of science with an interest in fundamental aspects of quantum theory. This book is not a science fiction book. Unless you're a trained physicist you won't understand much. But if you're a physicist you'll want to understand every single paradox in this book and you'll want more after you've done reading.
Each chapter begins with a paradox motivating the study of a fundamental aspect of the theory. There are more than two dozen paradoxes examined in this book, such as arrow of time, time reversal, quantum walks, quantum shell games, a quantum catalogs, quantum card tricks, Zeno effect, and quantum cats.
Close-up of book's cover.
I can't believe I've put this book #22 as it should've been top 10, but you can't put all of them in top 10. If did an article series called "My top 100 books sorted by information density," then this book would definitely be #1 or #2.
A Stern-Gerlach measurement inside a spaceship.
I've got several other excellent paradoxes/counter examples/thought experiment books and I'll share them in the upcoming articles.
Authors: Yakir Aharonov and Daniel Rohrlich.
#23 Feynman and Computation: Exploring Limits of Computers
Hell yes! Feynman again! The great teacher and all around fun guy. In previous part I listed Feynman Lectures on Computation, one of Feynman's least known books. This is even less known of Feynman's books but also one of the best.
This volume follows-up on Feynman Lectures on Computation. It's now nearly 20 years old but the content is timeless. It's a collection of fascinating scientific publications and stories by and about Richard Feynman. Feynman had a tendency to tell captivating stories. It was part and parcel of his style. And it's generally fun to see more of his stories and more stories about him. This book will boost your geekiness levels, expand your brain size, as well as provide a historical insight into development of neural networks, nanotechnology, quantum computers and information theory.
Feynman was decades ahead when he gave his original talks There's Plenty of Room at the Bottom (pdf) and Simulating Physics with Computers (pdf). These two provocative talks (both transcribed and reprinted in this book) anticipated several breakthroughs that have since become fields of science in their own right, such as nanotechnology and quantum computing. Many of the stories in this book cross-reference these two talks.
The book is divided into five sections: Looking at the original series of lectures on computation, reducing the size of computers, limits on computers imposed by quantum mechanics, parallel computation, and fundamental computing theories such as reversible computing and information theory.
Other fun topics include analysis of chaotic motion of Pluto, quantum robots, crystalline computation, fungibility of computation, parallel computation and algorithmic randomness.
In his There's Plenty of Room at the Bottom talk Feynman offered a $1000 prize to anyone who invented an operating motor that's 1/64 inch cube in size. Here's a picture of Feynman examining the the winner's motor:
Feynman examines Bill McLellan's micromotor.
There's also a TED Talk Feynman and Computation by Tony Hey, the author of this book.
Author: Anthony J.G. Hey.
#24 The Little Prover
Here we go again! In parts one, two, three and four I listed The Little Schemer, The Seasoned Schemer, The Reasoned Schemer, The Little MLer, and now it's time for a new adventure with The Little Prover.
The Little Prover was published just a few months ago and when I learned it's getting published I pre-ordered a bunch of copies not just for myself but for all my friends. I was that excited!
The Little Prover teaches the readers how to determine facts about recursive functions using induction. The book starts with programming concepts such as recursive functions and lists, and leads the reader along the shortest path to inductive proofs. It assumes knowledge of neither logic nor mathematics beyond arithmetic. Just like all other books in the series, it's written as a dialog between the authors and you in a super fun style with a lot of jokes and insider references. This book will make you think from page one and it will stretch your mind quite a bit.
You'll learn about axioms, theorems, what it means for something to be true in computing, conjectures, claims, counterexamples, total functions, partial functions, conjunctions, induction, natural recursion, and more.
While working through this book, you'll need j-bob, the proof assistant:
You'll truly appreciate this book only after having read the other books in the series. Get those first, and then read this book. And then read all the books again for full effect.
Only the true fan will understand this message.
I also just started a GitHub repository the-little-prover that contains all code examples from the book (just like I did for all previous books in the series.)
Author: Daniel P. Friedman and Carl Eastlund. Illustrations by Duane Bibby.
#25 Advanced Programming in the UNIX Environment (APUE) (3rd Ed)
Sir. Richard. Stevens. Himself. Do I need to say more? I've got all his books and almost all of them are in top 100. I also have all three editions of this book. This book is a classic. As long as there will be Unix (forever), there will be this book. Of course I haven't read it all but I've consulted it hundreds of times. This is the definitive reference book for every serious and professional UNIX systems programmer. Every concept is explained clearly, there are thousands of code examples, hundreds of illustrations and graphics that show how various concepts relate.
I don't know what else to say. Get this book if you want to live.
Extra tip: The book contains a rich set of examples and downloadable code that is very useful. Here's the link to source code from the book: http://www.apuebook.com/code3e.html.
Relationship between the seven
Another new, seemingly great book about programming in the Unix environment that was recently published is The Linux Programming Interface. This book is written by Michael Kerrisk, the current maintainer of Linux man pages. I haven't gone through it in detail but it's worth mentioning.
Pro tip: Want to know what's happening in Linux userspace and kernelspace but don't have much time? Follow man pages changelog! The latest changes always get reflected in man pages. It's the quickest way to know what's happening.
Author: William R. Stevens (W. Richard Stevens)
Until next time!
As always, I hope you liked these five book recommendations. Let me know in the comments what your all-time favorite books are and what your new favorite books are.
Also I just recently got four new interesting books but I haven't spent much time with them:
- The Go Programming Language by Brian Kernighan. Because Kernighan.
- The Princeton Companion to Applied Mathematics by a bunch of random authors, because I like applied math and this looked like a fun book similar to the famous The Princeton Companion to Mathematics by Timothy Gowers.
- Why Prove it Again? Alternative Proofs in Mathematical Practice by John W. Dawson Jr. I got this because I really like seeing various approaches to proofs.
- Inside Interesting Integrals by Paul J. Nahin. I got this one because I'm a huge integral nerd. It also has an amazing tagline: A Collection of Sneaky Tricks, Sly Substitutions, and Numerous Other Stupendously Clever, Awesomely Wicked, and Devilishly Seductive Maneuvers for Computing Nearly 200 Perplexing Definite Integrals From Physics, Engineering, and Mathematics.
This is how Browserling is made. These are commits to Browserling's private repositories. I just hit 370 days of nonstop commits. I'm on a mission to build a great company.
I thought I'd document this once-in-a-lifetime accomplishment. Until next time.
I'm on a mission to make developers' lives as simple as possible, and I just released Browserling's Safari extension. Safari extension lets you quickly access all Browserling's browsers with one click right from your browser. No need to go to www.browserling.com first. Just install the extension and you can start testing.
Download and install here:
Browserling now has extensions for four major browsers - Firefox, Opera, Chrome and Safari.
I've also submitted Safari extension to Safari Extension Gallery and it will soon be available there. I'll make an announcement when it is.
Work continues on finishing the extension for Internet Explorer. Once done Browserling will have extensions for all five major browsers.
Exciting news! I just added Android 6 Marshmallow to Browserling. You can now cross-browser test your websites in Android 6.
If you've a developer plan you can access Android 6 immediately through this URL in a few seconds:
Browserling is live interactive cross-browser testing service. It lets you get a browser in 5 seconds and test your website in all the most popular browsers, such as Internet Explorers, Firefox, Chrome, Opera, Safari and now Android browsers as well. It's awesome, try it out for free!
Until next time!
Frameworks are one of the hugest anti-patterns in software development. They're hard to learn. They limit your creativity. They increase your project's complexity and dependencies. They go out of business and get abandoned. You have to maintain and upgrade your code to match the latest framework versions for no good reason. You have to search for help and ask others for advice when you're stuck. And you probably only need a small percentage of features that the framework offers anyway. They just don't make much sense.
You should prefer core-language solutions to small abstractions to small helper libraries to general libraries to frameworks. Software should be developed using least amount of complexity, dependencies, effort and using fundamental tools that have been and will be here for the next 20 years. Frameworks are at the far end of software complexity spectrum and you want to avoid them as much as possible. You should be fighting complexity and not embracing it. I don't use frameworks and I encourage you not to use them as well.
In fact, one of the rules for writing software at Browserling is to avoid frameworks at all costs. There must be a tremendous reason to use a framework. So far we've used 0 frameworks and just a few libraries to get things done. I've yet to see someone come up with a good reason to use a framework. Simplicity is the law at Browserling. I've taught my employees well to never choose a framework solution and to try to find the simplest solution starting from the core language and core tools and going up.
Let's go over the reasons why you shouldn't be using frameworks in more details.
Frameworks are hard to learn and this knowledge is generally useless
Frameworks take a lot of time to learn. Instead of learning fundamental tools, core computer science concepts, and programming techniques, you spend time learning something specific and generally useless. Just because someone invented a framework and many people use it doesn't mean you need to learn or use it. People give in peer pressure too easily. "Everyone's using FrameworkA/FrameworkB, I must be using it as well."
No, you shouldn't.
You should be thinking, how do I avoid using this framework? How many actual features or core concepts do I need from this framework? Can I implement these features in a hundred lines of code and be done with it and never depend on this framework? Who are the authors of this framework? Do these guys have a track record of maintaining their code or did they just put it together in a weekend and released it?
Don't learn useless frameworks that have no value.
Frameworks limit your scope of creativity
Frameworks limit the scope of your creativity. Frameworks put you in a box you can't escape. Frameworks make you dumb. Whenever you're faced with a problem you can't just invent a solution; you're limited by what the framework lets you do. You have to seek experts, waste your time and energy to find a solution to a problem you shouldn't have had in the first place if you hadn't used a framework.
You can't let framework authors control what you can or can't do. You should be in total control over your product.
Frameworks increase your project's complexity and dependencies
Complexity and dependencies are bad. You should keep both your project's complexity and dependencies at minimum. If no one controls complexity and dependencies, and no one enforces how software is written, then one dependency leads to another, and soon your project ends up using 25 different frameworks and 5 different programming languages. There should be strict rules what you can and can't use in your project, and someone has to make that call.
Without rules you might save time at the beginning and sound cool using all the latest frameworks, but now your software is so complex that no one understands how or why it works. It's also become unmaintainable. You may not notice it in the first few months as things are moving along quickly, but as your project progresses, your team's productivity will drop because of all the complexity and dependencies. You'll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you're dead.
You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.
Frameworks go out of business and get abandoned
Frameworks go out of business and new frameworks appear. You have to learn the new frameworks again. It takes a lot of effort, energy and resources. You just spent all that time earlier learning the old framework and now it's out of business. All the skills you accumulated are now useless.
Everyone's hyped about the new frameworks and you don't want to be left out, but in fact you shouldn't even care what they are. Core fundamental tools already let you do everything that these frameworks do and you'll just waste your time learning something that doesn't solve anything new. The more marketing and buzz a framework has, the less you should trust it.
Even worse, framework authors sometimes just abandon their projects or they quit the projects and delete their entire projects. Your entire build now fails because of one author.
Use fundamental core concepts, solid tools and programming techniques that are here for the next 20 years, rather than frameworks and useless libraries. You don't need them.
Frameworks evolve and you have to spend time upgrading your framework versions and other dependencies.
If you wait too long between updates, frameworks have changed dramatically, and you have to spend days adjusting your code and learning the new interfaces. You don't need all the extra functionality the framework developers added. Most likely you don't need anything at all from the new version.
Framework developers can't stop evolving their projects for no good reason. Often software is just done. It does what it's supposed to do and doesn't need any changes ever again. You don't need the latest version of every software. Some of the best software was written 10 or 20 years ago. Use it!
Upgrading versions for no reason is another huge anti-pattern. If software works at version X, then it should stay at version X and should never be touched unless absolutely necessary.
Ask how happy your developers and system administrators are when you have to upgrade from Framework v1.4.3 to Framework v2.0.0. It's the worst time of their lives.
You have to ask others for help
When something goes wrong with the framework or you get stuck, you can't just come up with a solution because you're limited by what the framework lets you do. You have to ask for expert help, wait until someone helps you or pay an expert framework consultant.
If you keep your dependencies to bare minimum, then you're the expert and you can quickly get things done and come up with the solutions without ever asking for anyone's help or advice.
You probably only need just a few of framework's features
I've seen this again and again - someone starts their project with a bunch of full blown frameworks when they only need a few features from each. At this point they have already destroyed their project. "Which frameworks shall we use?" is the wrong question to start you new project with. Start your project with an empty file and use programming and a few helper libraries and core tools to get it going.
Use frameworks only when absolutely necessary
I'm not saying that there isn't a use-case where framework would be good but it should be an absolute exception. The only areas that come to mind where frameworks make sense are mathematically complex areas of computing such as sound processing, image processing, and machine learning, where it would take many months to write the code that does the job. And even then you should try to avoid them.
Friends don't let friends use frameworks
Until next time!