Agree fully. Such a great book, good thread to read from cover to cover. Many references to other articles/books.
Heck, for me it feels like it even has some suspense. “Ok, I now understood the single database instance and various ways data can be organized on disk - what can go wrong next? What problems are with more dbs?”
I never had this book-“feeling” with a technical book before, where you just want to continue reading it under your blankets at night. Love it and happily advocating it in the company. :)
Agreed, good book. Was a bit more theoretical than I expected, but way better way to refresh that stuff than digging through my course materials from university.
"A Philosophy of Software Design" by Ousterhout is my favourite of the last few years.
It's a shortish book but there is stuff in it I'm still unpacking on the third read through and a lot of stuff I sorta instinctively knew but it's nice to see someone else thinks the same.
+1 on this. I don't think anything in that book was especially new to me, but it matches what I think of as "good software design", and having it all compiled in book form makes it easier to transmit that knowledge to other people, especially students or newer engineers.
That was my general feeling but there is definite value to having it stated clearly and coherently and with the implied authority of a book (which is silly but a thing).
The book is specifically written around the Idris language, so some aspects would not work in most other languages. If you are willing to accept the loss of tooling, you can apply the development practice but you lose a lot. With Idris, a partial program is still verifiable even if not executable. Compared to an incomplete C program.
A particular quality of Idris is the ability to leave "holes" in programs. That is, if I don't know what's going to happen in this function, I can leave a hole:
main : IO ()
main = putStrLn ?greeting
I can then extract that hole into a new function and develop its particular capabilities. This will type check. Idris understands that ?greeting must be a string (or something which will produce a string).
If you have some experience with Haskell or SML or OCaml, it's not too hard to pick up the language (particularly the first). It'll look and behave very similarly to what you've seen before. If you aren't familiar with them, you'll be learning a whole new language, but the book is a good introduction to the language and the concepts the language introduces.
> do you have to pick up another language in order to gain from the book?
No, there aren't any prerequisites going in. The book is basically a huge tutorial on Idris, functional programming, and dependent typing, so you'll be pretty fluent in Idris by the end of it. Also, Idris without dependent types is basically a cleaned up Haskell, so you'll be somewhat fluent in Haskell by the end of it too.
If you're asking, "I'll never use Idris after working through this book; is there still something to be gained wrt/ my day job in C++/Java/etc?"... I would say that some of the basic functional programming insights would carry over--immutability, higher order functions, separation of concerns, totality, etc.--but the dependent type stuff probably won't. Nonetheless, the parts that don't carry over (holes, type-level computation, etc.) are precisely the most eye-opening bits so at some level I have to recommend learning about them just for learning's sake.
> Mind [to] elaborate a bit more?
Sure, here are some of the "eye openers" for me:
- The biggest one honestly is that apparently it's quite possible to teach this stuff to ordinary mortals. I've had numerous false starts with Coq and Agda tutorials, but here I really appreciated that this is a very gentle, readable introduction to the topic. The book teaches dependent typing through "computery" examples, like programming a hangman console application, instead of "mathy" examples, like proving DeMorgan's laws. You can immediately appreciate how the techniques the book teaches you can be applied to normal, programming concerns: preventing resource leaks, reducing the need for writing tests, refactoring code to make it more generic, designing better APIs, etc.
- Central to the book, and book title, is this idea of "interactive development". The type checker becomes a kind of assistant that actually helps you design your code, not just this batch process at the end that slaps you on the wrist for forgetting a semicolon. This will be huge someday.
- I always thought that dependent types were something that you would only bother to spend the extra effort on for key parts of low-level, "hardcore" code; proving that a crypto function is secure, or that a particular concurrent data structure is deadlock-free... that kind of thing. This book completely turned that world-view upside down. Dependent types are more applicable to high-level "business logic" code; you can literally express (normally unwritten) business rules in types and have the computer mechanically check everything. Designing this stuff in dialogue with the typechecker can help you design better business rules.
- There are a bunch of mind-benders, like the type-safe printf function, that really challenge what you previously thought was possible. Gave me the same chills as when finally grokking other "big" ideas, like lisp's "code is data; data is code".
Surprised this is the only mention of SICP. Although I don't know that I would have been able to handle it earlier in life. Perhaps it's different with accompanying lectures, but for self study it's quite a workout. I think it's worth trying, worth putting aside for later if you're not ready, and worth ultimately returning to. I'd be amazed if the undergraduates it was aimed at were able to appreciate it in full.
I'm surprised no one mentioned Steve McConnell's books.
Some of the material is dated, but what's left is pure gold. Takes a much more empirical approach to software development than a lot of other books in the same vein.
Code Complete is a great book that thankfully my first boss required me to read when he hired me but I personally feel that Clean Code covers most of the same and is an easier read. Just my two cents thought.
I never read Clean Code because of a kind of silly reason. I've worked with a couple of devs who read it and then decided the optimal number of lines of code per function was three. I always felt like I needed 6 monitors to be able to understand anything that was happening.
But if you recommend and say it's similar to Code Complete I'll give it a shot. What I liked most about Code Complete is he always talks about trade offs with a clear goal in mind. For instance if function sizes are too small hidden pre-conditions or side effects can cause a bug. But if functions are too large they are hard to follow and it's difficult to isolate side effects.
Yes. I'm building a relational language, after read a lot about compilers and database engines.
I probably will never succeed at it (ie: Become a small hit with this side project) but learning about stuff help to apply better solution to what you do.
Contrary to popular belief, CRUDs apps are much harder and more sophisticated than many other kinds of apps, and worse, you have a much faster release cycle with worse specifications and other bad stuff (I build apps for business, so this is my thing). So pay a lot to learn how be smart about that!
Have you spent your 13 years aping the legacy code and doing no personal development? The books will almost certainly help. Have you taken advantage of those 13 years to make yourself the best CRUD programmer you can be? You've probably read these books already.
I have used the concepts in this book weekly, if not daily. Note: The tracer bullet framework helps with thinking about any complicated system, not just software.
Clean Code (2008) is at the top of my Books I wish I'd read 10 or 20 years earlier list, along with Refactoring (1999). They totally transformed the quality of my finished programs, in many ways. Some what I learnt may fit into "That's so obvious, why didn't I think of that", or making conscious the things you already do... Refactoring, just by naming and defining the activity, was useful. They're both talking about the programming equivalent of editing for writers. And how to do that, how to get from the 'dirty code' first draft to the 50th draft with everything as good as it can get. Do your future self (and other people) a favour - they're the ones who will have to read and understand your programs.
A couple of years later I came across Allen Holub's Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming (1995). I didn't learn anything from it, but it contains almost all of what's in those 2 books, and was written years earlier, (so could have been read earlier), and I think he deserves more credit.
It's pretty good. Depends on your skill level. It focuses on how to write algorithm, classes, and grouping classes into modules in a way that is considered "clean". He has another book on clean architecture that deals with structuring programs.
I’ve read a couple of those books. To me, many of them are too dull. School textbooks. The same books also seem to be on every list like this.
Today, 12 years after finishing university I prefer the hands-on pragmatic books, written by practitioners for practitioners, books that would never work as text books at a university. For example Effectiva Java.
I think you'd be better off buying a different algorithms textbook for another perspective. The Algorithm Design Manual is a popular (and much cheaper) option.
An overview of databases (what and why, but also a lot of how) plus distributed concepts and modern architectures.
[0] https://www.amazon.com/Designing-Data-Intensive-Applications...