Ah, the good old Design Patterns book, responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since.
I mean, I did OOP in some languages, because, well, they had object like constructs. For example VBA had all these Excel tables modeled as objects you could access and modify via code.
Then there was C++ and Java with their factories and factory factories and whatnot.
And lastly the examples of cars that have wheels and animals that inherited stuff etc. pp.
So I had different concepts in my mind, all being objects.
On the one hand the examples of university.
On the other hand the tangible Excel table of VBA that I understood. "At table is an object with some methods and properties"
And then the "real programmer stuff" like a controller, a presenter, a singleton, a emitter... Things that were really abstract to me, because they didn't map directly to tangible things I saw in the software as a user.
Design patterns somehow made this more easy to grasp.
But I first started to understand the whole thing after building my own API in PHP (started after it got classes haha) that had module- (controllers), protocol- (views) and data-objects (models).
Careful there - lest you throw the baby with the water.
As with all things - there are some good ideas there and some bad. And as I understand it, the book simply presented patterns - programmers were already using at that time. So the book's existence in itself wouldn't cause bad code IMO.
Now if someone were to write a "modern design patterns" book, people will probably write about:
1. Actor pattern and concurrency using message passing.
2. Immutability and - designing types with no shared mutable state.
3. Dependency injection
4. Pattern matching
5. MVC
6. mocks and stubs and fake objects?
7. ...
And same as before - some of these ideas when applied to certain cases could be bad.
> "if someone were to write a "modern design patterns" book"
Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.
Having read Design Patterns in the past, I found http://gameprogrammingpatterns.com to be a really good modern follow-up, though it's targeted at game developers in particular.
I don't think that's fair. The driving point of that book was that developers needed a higher level language to talk about these patterns than simply at the code level, and showed people how to put together a vocabulary. Yes, it came with a library of sample patterns useful for Java developers, but they weren't egregious examples, nor were they the main point of the book. They were just taken to an extreme by people who skipped over the first part of the book and just skimmed the library. It was a "how to think about your craft" book that people misread as a "how to achieve a programming task" book.
This book was written before Java for C++ developers (amazon shows 1994).
Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).
That's very interesting. I haven't read Design Patterns. I have read A Pattern Language, and the Timeless Way of Building, by Christopher Alexander, and Patterns of Software by Richard Gabriel. It's been my understanding that Design Patterns had only a couple of dozen patterns (which turn up again and again in Java code) and prescribed their use generally, but if they're only examples of patterns, and programmers are encouraged to invent their own (which I do anyway), it might be worth a read.
GoF's Design Patterns, for all its flaws, was never intended as a prescription or even as an exhaustive description of every design pattern. It was a recording of commonly used and battle-tested patterns. I think the motivation was good; the bad thing was that it became some sort of bible to be followed blindly. I don't think that was the intention of the authors, though.
This is true, but it's an effect, not a cause of the book. "Design Patterns" is older than Java. They wrote it based on patterns they saw mainly in Smalltalk and C++.
> prescribed their use generally
Like "A Pattern Language", "Design Patterns" reads more descriptively than prescriptively. It's, "Here's a thing we saw people do. Here's what problem they were solving with it. Here's the context of their problem. Here's the positive and negative consequences."
I think it's not fair to the authors. As you say they are clear about the patterns being examples. However, there seems to be something about the book or maybe patterns in general that make it seemingly impossible for many developers to not look for use cases of these patterns and start using them in cases that don't quite match. I lead a book club at a post employer where we read the GoF. I constantly emphasized that these are examples of how we might reason about OOP and that they are inappropriate more often than not even though you think they are a fit. Yet, of course some people started suggesting them frequently. I think the problem might be that the first part is a support quick read and then you spend a huge amount of time reading the catalog. Once you understand them, you see how nice the patterns are on their own and you want to use them. They are pretty and you've spent time learning them. So it's only natural. It's a beautiful mental trap.
> However, there seems to be something about the book or maybe patterns in general that make it seemingly impossible for many developers to not look for use cases of these patterns and start using them in cases that don't quite match.
Perhaps. But consider the background. People write code that isn't very well designed all the time. Maybe you just see these patterns misused so often because you can identify and name them. This is entirely the point behind the book – so we can identify these common patterns and talk about them at a higher level.
You've probably seen bad code where you can't describe what's wrong with it succinctly a lot too. But you don't have the option there of saying "oh, they've used a factory there when they shouldn't have" because the bad code doesn't follow a pattern that you know / have named. So all of those cases just get filed away in the fuzzy "bad code" category instead of being an example of a pattern being misapplied.
By definition, almost, something being a pattern is going to be something you see misapplied simply because that's part of the purpose of design patterns – so you can comprehend these problems better.
>, the good old Design Patterns book, responsible for more atrocious over-abstracted,
This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation.
The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription.
Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary.
> >, the good old Design Patterns book, responsible for more atrocious over-abstracted,
> This is a misunderstanding of the DP book.
It is discussing an effect of the book, not the intent.
> It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies.
Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
>It is discussing an effect of the book, not the intent.
Do you truly believe that specific DP book caused that effect?
I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.)
I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word.
>Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts
Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.
A very weird comparison, the brief history of time is a popular science book aimed at laymen, it sacrifices precision for a larger audience and is not really a dry book.
Sorry for the confusion. (I've edited my comment for clarity so people don't think I was insulting SH.) I wasn't saying Hawking's prose was dry. That attribute was intended solely for the DP book. With ABHOT, I was comparing the ratio of readers aware of the book vs actually reading it. ABHOT has become sort of a "poster child"[1] among bibliophiles for books owned for vanity and I thought HN readers would get that reference.
I'll piggyback on you and highly recommend the "crash course astronomy" series on YouTube. It's 50 or so ~10 minute videos that does a broad overview of all of astronomy up to the current moment, starting back when the older civilizations first studied the stars just by looking up with their naked eyes.
It is fast paced and packs a lot of information into each episode, so I do end up rewinding sometimes. And being a passive video, I think retention won't be as high. However, the short videos are very approachable and bite sized. It's very well done and the host is quite entertaining. The past year, my interest in space and physics has increased a bunch. It feels like learning the deeper history and context in which all of humanity is embedded.
I think you are hugely underestimating the influence this book had. This was the first catalog including these patterns and the authors gathered them by looking at source code from many, many projects and compiled common patterns they deemed useful into this book. They named the patterns and this book ultimately popularised them. The book was a huge success when it first came out and I know many people who have indeed read the book. I've even encountered it in university twice. Without this book many of these patterns might not have a name and hardly anybody would know them. They would be patterns in the way that they randomly occur in the wild, but not in the sense that they are templates that developers seek out to solve problems.
Most people have a copy of DP and have not read the whole thing. Most people have read it in that they have read a couple pages, the table of contents, and a couple random patterns. To some extent that is how the book should be read: you have a problem that a DP solves and so you read the section on that pattern to get it right.
The problem is most people have a superficial knowledge of the patterns in the book (a list is easy to put together along with a short summary so most people have read one). They then go looking for how to apply the patterns to their domain so they can check the pattern box, without thinking about the large picture. They never consider that patterns exist to solve a specific problem and if you don't have that problem you shouldn't use the pattern.
The classic example is the singleton: it solves a tricky problem that large systems sometimes have. However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.
There are several patterns that are a specific way of creating a layer of abstraction. Abstraction layers are often very useful, but as the saying goes: "all problems in programing can be solved by adding a layer of abstraction - except too many layers of abstraction". I've seen cases of layers of abstraction that didn't solve any problems.
As such the original point: DP, by giving patterns names has created more harm than good. This is not the fault of the book though: the names were needed and the patterns are very useful when applied correctly. However before the book people would re-invent the patterns (badly) only when they needed the pattern.
> Do you truly believe that specific DP book caused that effect?
>
> I don't. The DP book is extremely dry reading and most programmers have not actually read it.
This doesn't match my experience but I think that's because you're conflating two related ideas: while few people may have deeply read DP, that's not a requirement for it to have had a strong influence on them, any more than it is necessary for someone to have deeply read and understood their holy book to have strong religious beliefs.
I make that comparison because the worst projects I've seen were heavily based on DP but in a bad way because it was used more as a club than a means for self-improvement. Architects threw it around to bolster their status, a strong push towards ritual cargo culting rather than making sure the problem was well understood enough to know that the code being written matched the actual business case, and any criticism was met with a flak shield of “This is the best practice way according to DP”.
That's not necessarily DPs fault — although there is a discussion to be had about valuing comprehensibility if you want to make meaningful improvements — but it was definitely an effect shaping software development for the worse for over a decade.
> Do you truly believe that specific DP book caused that effect?
GoF/Design Patterns was published in 1994.
Java, the standard-bearer of overapplying Design Patterns, was first released in 1995, and it only grew into the AbstractAdapterFactoryImpl cliches after that.
Based on that timeline Im not really sure how you can argue that GoF had nothing to do with DP madness, at least as exemplified by Java.
Just because GoF was originally meant to be descriptive does not mean that it can't be interpreted as prescriptive, especially by your stock work-a-day software engineer or peter-principle'd software architect.
Despite whatever intentions the GoF may have had, by giving these patterns a name, they in a sense codified them, giving people something to point to when justifying otherwise poorly thought out design decisions.
> The DP book is extremely dry reading and most programmers have not actually read it.
The thing about GoF is that you don't really have to read it to apply it--and not actually reading it only increases the odds of mis-applying patterns if youve encountered them elsewhere.
I'm actually with the others on this. I've been looking at CompSci papers, engineering methodologies, and real world code going back a long time. I saw a few patterns in use like Parnas' information hiding or state machines. I didn't see GoF patterns until I saw Java people using them while recommending the book. Also, many people in industry forgot about prior methodologies that got results without over-abstraction such as Cleanroom but were all over GoF patterns and latter Agile methodology. It seems their work was pretty influential.
You probably have already seen them. It was just things such as structured programming, decomposition into functions, layering with minimal loops between layers, interface checks for invariants, avoiding risky languages/constructs, and usage-based testing.
That may be, but it's a very common misunderstanding of the book by junior developers who read the book as a list of recipes to use anywhere they might be applicable.
Is it the book's fault that it's understood this way? I don't know. Regardless, the book + this persistent understanding and use of it are, as grabcocque says, "responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since."
I dunno if it's just _junior_ ones. I've encountered my share of "enterprise architects" that will use this book as though it were a bible when trying to justify their near-insane scribbling of boxes and lines on the white board.
The facts that the book focuses on exactly the kind of patterns which are not abstractable into libraries in the popular OOP languages of the time (mostly true now, too), and that the implementation of each pattern is central to the presentation -- both of which arguably have quite good reasons based on the books intended role, to be sure -- I think promote this misunderstanding.
Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.
Still, the original architecture "Design Patterns" book by Alexander (which this book is supposed to be the software analogy of) discusses "good practices", emphatically recommended for architects, city planners, etc. So it is maybe not that far-fetched to interpret these patterns as recommendations too.
Unfortunately, it tends to be _read_ as a how-to book rather than as a catalog of observations. I have actually heard from a professional software engineer, "We can't write the code this way because it's not using any known design pattern," said with a straight face. This is partially the mentality that gives us things like the classic AbstractSingletonProxyFactoryBean[1] class.
I've seen this argument before, but I don't really buy it. Why did they subtitle their book "elements of reusable object oriented software" if they didn't intend to present "patterns" as "templates." (After all, "reusable" is a good thing, right? So if you follow these patterns your code will be reusable, hence, good.) Why did they use the word "pattern" at all? Why not name the book "Software Structures: observations about software out in the wild?"
In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>".
This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern."
For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns."
Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to.
Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.
The GoF book is responsible for a lot of bad decisions made by inexperienced devs because colleges insist on using it as a textbook. It's the textbook used in most Java-based CS programs for their Design Patterns courses. It was when I was in school and it still is now.
Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems.
The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way.
Don't blame the book - blame the curriculum that's based on it.
A friend used to say that, he likes to share vocabulary, so they can avoid duplication. Which is entirely true, that said this book gave me nightmare, because I found the mindset so ceremonious; borderline off topic.
Giving name like flyweight to a simple "compression" scheme... The whole thing felt like "duh" to me. Sure it give common ground to people; but none of it felt like something to be written down, even less worshiped like it was.
I also strongly feel about the critics saying that it targets poor OOP languages (cpp, java <5), rendering the whole thing moot in other paradigms.
I don't think that's fair. The patterns already existed, they just created a taxonomy and added editorial. I think it's one of my favorite programming books.
Everybody independently created singletons and factories and builders, we just all called them different things.
> responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code
I have the misfortune to remember what some object-oriented codebases looked like before "Design Patterns".
While people—generally those who haven't read the book or completely glossed over the section on the consequences of each pattern—have certainly over-used design patterns, I'll still take that over under-use of them.
An over-engineered too-many-design-patterns codebase is annoying and tedious. A hundred thousand lines of code filled with half-way-reinvented design patterns with its own made up terminology, hard coupling everywhere, piles of global state, and no real architecture to speak of at all is a nightmare.
It's all in my phone. I read it all.I NEVER GAVE PERMISSION for this to be placed on my Android I decided to look one of the 50or so things like this on my phone.. I never had e permission j believe i can tell you what state and what address this man is doing this from!
I feel like it probably did more good then bad. Codebases devoid of any design patterns arent likely great quality. But it requires judgement to not over engineer.
As to be honest, I have no clue about SEO at all :) I'm happy some other developers checked it out...Didn't even think to support this project, data is quite static. But according to some feedback, some things to be changed for better filtering. Will get on it at night :) Not really interested in sales, will be happy if amazon would send me a pack of beer :)
I'm not sure I see what's wrong with this. The author obviously invested work in this and provided a resource others may find useful. You're free not to buy books through their affiliate links.
What about this is useful? There is no breakdown of whether the mentions were upvoted or downvoted, no mention of whether they solved the problem (or were even relevant to the question), no review of the books so that readers can make an informed decision, etc. This list is not much different than making a list of the top selling programming books on amazon.
I like lists like this for discovering books I haven't heard of. I don't make an immediate buy decision based on appearance in a list, and will do more research. But it's a nice way to run into something you didn't run into before for some reason.
To each their own; shaming the OP on HN for adding affiliate links on their own website, on the product of their own effort, is what I'm trying to point out.
When you say something like "nice affiliate hack" it comes with an implication that it's wrong, because a lot of people on the Internet try to trick others into clicking their affiliate links.
The English language does not change because this is HN and everything thinks their IQ is 3 standard deviations above the mean.
"Nice _______ hack" has an obvious and blatant negative connotation, particularly when it's on its own like that. The implication is that this is just a way to make a few bucks. That's not what the commenter meant, thankfully, but that's only known after further explanation.
>You're free not to buy books through their affiliate links.
You're only free to do this if you know that it's an issue. Unless you know about the affiliate program, you may be supporting this person against your own will. Even if you do know about the affiliate program, you may not know that after you click an affiliate link, the owner of the code gets a chunk of ANY Amazon purchase you make in the next 24 hours, whether or not it is related to the original link.
I find this mindset baffling. I mean that earnestly. Can you try to explain why other people making money bothers you?
It seems pretty clear that amazon thinks affiliates provide a useful service. And if you go to amazon because someone shared something that interested you enough to buy it, they've provided you with a service. What exactly is the problem?
Because it is a undisclosed conflict of interest.Imagine you go with a friend to a bookstore , and he recommends to you several books. Since you seem to trust your friend and you have the money, you buy the books. Unbenknownst to you, your friend receives a 5% commission, and he never disclosed it to you. Same principle. It is a whole different game if he mentions this to you in advance, since now you consider your friend a as an interested part and you will consider his recommendations more carefully.
So? He can overhype all the books without giving preference to one. He can pontificate about how important is to read books, how all the geniuses at HN read these very important books and so on.He only needs to maximize the money spent on the books, not the selling of a particular one.
He is advertising beers (and get money from all of them) not just Budweiser.
Out of my memory, Amazon affiliate links only earned me something like $30, total (I had other sources of revenue via targeted ads, which earned a bit more, but not much).
But lots of C++ books. C++ and Python are my primary languages, and I own far more C++ books than Python. For C++ I've got all Scott Meyers stuff, Alexandrescu, Stroustrups C++ language. For Python I've got Beazley, and that's it. My guess is that Python, and probably Ruby too, are so much easier to learn than C++, so fewer books are read and sold.
I don't grant the premise that fewer Ruby and Python books are sold... Regardless, the number sold is greater than 1 so they should really be listed in the app.
I'm pretty sure it skews old by not correcting for publication age. That's how "heads up design patterns" from 2004 beats almost everything since, simply by being older. In 2030 something newer will have higher numbers, but an old classic will have even larger numbers, so ...
Eventually old stuff tails off. I learned C from K+R edition one in the 80s, and the ANSI edition two has now displaced it.
I was genuinely curious. Superficially, it seems like "mentions" would scale with sales (as opposed to, say, recommendations if you could work that out).
"Patterns" are to the art of good programming what organized religion is to the art of good living. Everyone loves the ideas, everyone hates the implementations.
This. It's not exactly programming, but I think this should be recommended reading. I've only read it about 20 years into my career but it all clicked - I wish I had seen it earlier.
As a Senior programmer, over the years, I've bought eight copies for Juniors to help them cope and learn to deal with other types of programmers (or stop being fucking hero-programmers).
How, in the process of answering a specific programming question on Stackoverflow, would a link to a book on project management be appropriate?
Also, what's up with the phrase "I'm surprised" that always comes up in threads like this: If you believe a book should be higher up, tell us why! Or do you question the author's methodology?
If you misjudge the current significance or influence of a thing, ... so what?
Is there any way to do this datamining, but not just looking at amazon links? By that I mean that I'm sure people mention "Code Complete" often enough, but don't bother linking to it on Amazon. That'd be interesting to see the results.
Also could be interesting to see this study, but also weighted based on the number of votes the posts referring to them got.
I wonder how many people actually read the books they were suggesting.
Like here on HN, Art of Computer Programming gets mentioned a lot. But I've not met anyone who has actually read it. And I own a copy. It's so hard of a read that I am just going to assume anyone who says they did is either lying or Donald Knuth.
I'm suspect of books as a means of information conveyance. They make great mediums for narratives, but narrative is too slow for technical writing. Similarly, I dislike videos, podcasts, and conference talks. Technical writing should be a wiki-like document where terms expand in-place. Start super high-level. Always written in clipped, imperative style. Single line per fact. Like mathematical proofs, but maybe in reverse.
There's something to be said for reading "a great book" from cover to cover. It is really an investment of time, effort and discipline over many days.
I think people (and I include myself) buy such books often with an aspirational intent, to spend that "perfect" weekend or weekends deeply ensconced in the subject matter and coming out of the reading as a different, better and more skilled person. It never happens that way, of course. We're just trying to re-live some past time as students where the world was an oyster of knowledge. For the most part memories of those days are grossly inaccurate, merely softened into nostalgia by the passage of time.
In reality, many of us behave like monkeys continually zapped by shock-collars just trying to keep up with shit that never works right and always living in a profound deficit of knowledge, while drowning in information.
Still, its good to have books, and worthwhile to take insane measures to get alone-time to read them. The short practical ones are best. Comprehensive reference books are good too because you can read just what you need while ducking from life's flying shit.
I've finished and very much enjoyed the first volume, which is equivalent to the curriculum in any first year compsci course from what I've seen of university lecture schedules (Data Structures such as Lists/Stacks/Queues/Trees/Arrays,GC,'helper functions' and program design,O-notation analysis,testing and debugging w/trace routines, I/O algorithms) but of course in much more detail with much harder problems.
To understand the first few hundred pages on mathematical preliminaries, the books "The Art and Craft of Problem Solving" by Zeitz and "Concepts of Modern Mathematics" by Stewart, were essential, both of which were recommended here in other book list posts. I also had already read the CS:APP book which covers x86-64 assembly so the MIX introduction was fairly straight forward. http://csapp.cs.cmu.edu/
A book for me that was hard to read, is this book: http://www.cs.cmu.edu/~rwh/pfpl.html Practical Foundations for Programming Languages each page I have to translate with the notation guide, and is a research exercise searching Wikipedia for additional material.
I've read the first three volumes. And recently when paring down my collection, it went out. Sorry, Donald, but you've got too much about multi-phase tape sorts and not enough about current programming.
I started volume four but couldn't get my head around the first page, and am very dubious that plowing through it would have any real value.
One book(s) that I didn't see come up on the list was "The Art of Computer Programming". It would be interesting to see if that was because it's popularity got spread out because of multiple volumes or if people just don't mention it that much.
There is CS on SO, but SO is really designed to, and flooded with, stuff like "how to verify replication on mysql 5.6?" or "How do I install PIP for python on freebsd" and not so much "Lets have us a nice debate about P=NP" or "can someone clearly explain the entire proof of why 3SAT is NP-Complete at like a TED talk level?"
Didn't see SICP (Structure and Interpretation of Computer Programs) on that list. Surprised considering how often I hear it quoted on SO. You would think it was the bible of computer science. A little old in the tooth i'd imagine.
In some ways, but not others - that's the advantage of something that teaches computer science fundamentals, as much of what is in there is timeless. In many ways it's never been matched (in that particular domain).
I suppose the programming environment does make it a bit less accessible over time.
SO doesn't focus on CS, they focus on solving problems like "How to get better replication on postgres?" etc. This is also why books like SICP, TAOCP and CLRS seem to be missing.
People who make these Amazon referral farm sites, is anyone willing to share how much money they make off theirs? Maybe like a $ per 100 pageviews stat or something? I'm curious.
Seems like a flaw in the algorithm if Effective Java is not in there. I filtered by the Java tag and "Effective C++" showed up, but not Effective Java.
Can someone recommend a good book on linear algebra for somebody that took it in college but needs a refresher plus some advanced linear algebra concepts for machine learning?
- Intro to Linear Algebra, Strang
https://www.amazon.com/Introduction-Linear-Algebra-Gilbert-S...
Strang approaches LA from a practical less-theoretical angle, which makes it very sensible if you're an engineer but may not be as suitable if you're a mathematician.
The books by Klein and Strang also benefit from free videos of those courses that are available from Coursera/BrownU and MIT OCW. Klein's is also available on the Kindle.
Each short lecture had a 'Why didn't they tell me that in college!' kind of insight.
Transformations, determinants, dot products, cross products everything made sense
in a visual way.
But, it scraps user comments that contain Amazon book link from HN and orders them by theirs point. If you wonder how much money Hacker News Book has been made, I would suggest to read this post [2]. The different part with this is that Hacker News Book shows not only the most mentioned books all the time but also per week. Hacker News Book has more diversity of book topics since HN is not limited for programming discussions.
Anyway, I just want to say congratz to the OP for launching this. I think you miss "Show HN" on your post title.
Good one, will be interesting to compare amazon statistics for 5 days. I didn't think to invest in this project much time like this guys did and didn't expect so much feedback :)
I've seen that recommended many times but it's a terrible book, IMHO. (I don't remember the specifics why, but vaguely remember the author waffles around without any real points).
I think there's some value in showing how design needs to be defined by usability and not the other way around. I agree the point could have been made in way less words, but there's something extremely useful in learning to thinking about user first and not many books that talk about that.
Like, the kitchen top example, which is best summarized with two pictures:
I think it suffers a little from the Seinfeld effect, where it was completely original at the time but created enough of a following that it seems derivative when you go back to it.
Then it's not for you. I've read it, I loved it, it gave me lots of ideas. Something that you must understand is that sometimes, a book is not good or bad, it's just not for you. Sometimes, you must read into it, get inspired and develop your own useful ideas. It's kinda like when I go to conferences, I could sit in an hour long talk, and yet it will be only one minute of it that was insightful to me, and that one minute might be worth the entire talk. First time I went to a conference, I was so bored and disappointed, I expected every word, every slide to be mind blowing. When I changed my way of thinking, I got more out of it. I apply the same philosophy to books, I could read a book and perhaps it's a chapter or a few pages that will make it worth it all. For the design of everyday things, every chapter mattered to me.
255 comments
[ 3.5 ms ] story [ 310 ms ] threadBut I guess the Problem is how OOP is teached.
Before I learned about design patterns I only saw car or animal examples. Design patterns were the first real world OOP stuff I saw at university.
I learned OOP with Turbo Pascal 5.5, for MS-DOS, around 1990. Started using Turbo Vision with Turbo Pascal 6.0.
Eventually also started coding with Object Windows Library in Turbo Pascal and Turbo C++.
Borland manuals were my introduction to OOP, followed by books like "Designing Object-Oriented C++ Applications using the Booch Method.".
Only later I got to learn about the multiple ways of doing OOP (CLOS, Beta, SELF, ...).
I mean, I did OOP in some languages, because, well, they had object like constructs. For example VBA had all these Excel tables modeled as objects you could access and modify via code.
Then there was C++ and Java with their factories and factory factories and whatnot.
And lastly the examples of cars that have wheels and animals that inherited stuff etc. pp.
So I had different concepts in my mind, all being objects.
On the one hand the examples of university.
On the other hand the tangible Excel table of VBA that I understood. "At table is an object with some methods and properties"
And then the "real programmer stuff" like a controller, a presenter, a singleton, a emitter... Things that were really abstract to me, because they didn't map directly to tangible things I saw in the software as a user.
Design patterns somehow made this more easy to grasp.
But I first started to understand the whole thing after building my own API in PHP (started after it got classes haha) that had module- (controllers), protocol- (views) and data-objects (models).
As with all things - there are some good ideas there and some bad. And as I understand it, the book simply presented patterns - programmers were already using at that time. So the book's existence in itself wouldn't cause bad code IMO.
Now if someone were to write a "modern design patterns" book, people will probably write about:
1. Actor pattern and concurrency using message passing.
2. Immutability and - designing types with no shared mutable state.
3. Dependency injection
4. Pattern matching
5. MVC
6. mocks and stubs and fake objects?
7. ...
And same as before - some of these ideas when applied to certain cases could be bad.
Based on my recollection of the original Design Patterns book, all of the patterns you list are included in the original book. Caveat: I haven't opened the book in over 5 years, but I'd be surprised to learn that any of the 6 patterns you list are not in the original DP.
And afaict - none of the patterns I listed are mentioned verbatim.
Edit: I agree with your opinion. Just wanted to show that this problem is much older and related to other languages too (probably with the similar OOP implementation).
This is true, but it's an effect, not a cause of the book. "Design Patterns" is older than Java. They wrote it based on patterns they saw mainly in Smalltalk and C++.
> prescribed their use generally
Like "A Pattern Language", "Design Patterns" reads more descriptively than prescriptively. It's, "Here's a thing we saw people do. Here's what problem they were solving with it. Here's the context of their problem. Here's the positive and negative consequences."
Perhaps. But consider the background. People write code that isn't very well designed all the time. Maybe you just see these patterns misused so often because you can identify and name them. This is entirely the point behind the book – so we can identify these common patterns and talk about them at a higher level.
You've probably seen bad code where you can't describe what's wrong with it succinctly a lot too. But you don't have the option there of saying "oh, they've used a factory there when they shouldn't have" because the bad code doesn't follow a pattern that you know / have named. So all of those cases just get filed away in the fuzzy "bad code" category instead of being an example of a pattern being misapplied.
By definition, almost, something being a pattern is going to be something you see misapplied simply because that's part of the purpose of design patterns – so you can comprehend these problems better.
This is a misunderstanding of the DP book. It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies. Or, the existence of the Oxford English Dictionary is responsible for bad novels and useless documentation.
The DP book is a catalog (to gain awareness) and not a checklist (that you must do). It's a collection of observations about software structures out in the wild. It's not about prescription.
Even without the phrase "design patterns", it's easy to surmise that programmers out there are independently and unknowingly re-inventing the same higher-level structures (similar to tv tropes) but without giving them formal names. The DP book gives them formal names and hence, an attempt at shared vocabulary.
One can go to the amazon.com page for Design Patterns and click "Look inside" for the "First Pages" and see that the authors wanted to present a catalog: https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...
> This is a misunderstanding of the DP book.
It is discussing an effect of the book, not the intent.
> It would be similar to saying that the existence of TVTropes.com is responsible for terrible scripts of tv shows and movies.
Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts from it, regardless of what TVTropes is intended to be.
Do you truly believe that specific DP book caused that effect?
I don't. The DP book is extremely dry reading and most programmers have not actually read it. ([In terms of readership/ownership ratio] It's a book like Stephen Hawking's "Brief History of Time" ... everybody knows about it and some might have it on the coffee table but very few actually read it.)
I do think the _phrase_ of "design patterns" (not the book) has become a sort of gravitational force such that any discussion about "overcomplicated design" seems to fall toward that particular phrase. Or put differently, "bad designs" is now a synonym of "design patterns" so much so such that you can't even say "design pattern" and have it be interpreted as a neutral term. It's become a trigger word.
>Which would be entirely accurate if script writers were widely using TVTropes pages as templates and creating bad scripts
Yes, I agree that would be equivalent. However, I don't think the existence of tvtropes compels directors like Michael Bay to repeat the "walk away calmly from explosion in the background" scene. The motivation to repeat that "cinematic pattern" comes from somewhere else. Likewise, the majority of bad/overcomplicated abstractions in source code come from somewhere else besides that particular DP book.
[1] example from WSJ that mentions the common meme about ABHOT: https://www.wsj.com/articles/the-summers-most-unread-book-is...
Context: My formal physics education ended in high school.
It is fast paced and packs a lot of information into each episode, so I do end up rewinding sometimes. And being a passive video, I think retention won't be as high. However, the short videos are very approachable and bite sized. It's very well done and the host is quite entertaining. The past year, my interest in space and physics has increased a bunch. It feels like learning the deeper history and context in which all of humanity is embedded.
The problem is most people have a superficial knowledge of the patterns in the book (a list is easy to put together along with a short summary so most people have read one). They then go looking for how to apply the patterns to their domain so they can check the pattern box, without thinking about the large picture. They never consider that patterns exist to solve a specific problem and if you don't have that problem you shouldn't use the pattern.
The classic example is the singleton: it solves a tricky problem that large systems sometimes have. However few people realize that a singleton is a fancy name for a global variable and have all the downsides of a global variable.
There are several patterns that are a specific way of creating a layer of abstraction. Abstraction layers are often very useful, but as the saying goes: "all problems in programing can be solved by adding a layer of abstraction - except too many layers of abstraction". I've seen cases of layers of abstraction that didn't solve any problems.
As such the original point: DP, by giving patterns names has created more harm than good. This is not the fault of the book though: the names were needed and the patterns are very useful when applied correctly. However before the book people would re-invent the patterns (badly) only when they needed the pattern.
Really? It's been twenty years (maybe a bit more?) since I read the book, but I think this was pretty explicit, was it not?
This doesn't match my experience but I think that's because you're conflating two related ideas: while few people may have deeply read DP, that's not a requirement for it to have had a strong influence on them, any more than it is necessary for someone to have deeply read and understood their holy book to have strong religious beliefs.
I make that comparison because the worst projects I've seen were heavily based on DP but in a bad way because it was used more as a club than a means for self-improvement. Architects threw it around to bolster their status, a strong push towards ritual cargo culting rather than making sure the problem was well understood enough to know that the code being written matched the actual business case, and any criticism was met with a flak shield of “This is the best practice way according to DP”.
That's not necessarily DPs fault — although there is a discussion to be had about valuing comprehensibility if you want to make meaningful improvements — but it was definitely an effect shaping software development for the worse for over a decade.
I believe that it, and specific choices made in the selection and presentation of patterns in it, contributed significantly.
> The DP book is extremely dry reading and most programmers have not actually read it.
Perhaps, but the influence of a book (especially one which directly inspires other books) often extends beyond its direct readership.
Yes, definitely. People used to cite the GOF book left and right while over-engineering crappy CRUD apps.
GoF/Design Patterns was published in 1994. Java, the standard-bearer of overapplying Design Patterns, was first released in 1995, and it only grew into the AbstractAdapterFactoryImpl cliches after that. Based on that timeline Im not really sure how you can argue that GoF had nothing to do with DP madness, at least as exemplified by Java.
Just because GoF was originally meant to be descriptive does not mean that it can't be interpreted as prescriptive, especially by your stock work-a-day software engineer or peter-principle'd software architect. Despite whatever intentions the GoF may have had, by giving these patterns a name, they in a sense codified them, giving people something to point to when justifying otherwise poorly thought out design decisions.
> The DP book is extremely dry reading and most programmers have not actually read it.
The thing about GoF is that you don't really have to read it to apply it--and not actually reading it only increases the odds of mis-applying patterns if youve encountered them elsewhere.
That may be, but it's a very common misunderstanding of the book by junior developers who read the book as a list of recipes to use anywhere they might be applicable.
Is it the book's fault that it's understood this way? I don't know. Regardless, the book + this persistent understanding and use of it are, as grabcocque says, "responsible for more atrocious over-abstracted, unreadable, hard to maintain Java code than anything else before or since."
Certain other design patterns books in the software field (Patterns of Enterprise Application Architecture and Enterprise Integration Patterns, for examples that happen to be on the shelf next to me at the moment) don't share those features.
1: https://news.ycombinator.com/item?id=4549544
In any event, it doesn't really matter what the original intent of the GoF book is because in practice, people treat design patterns as, well, what the word "pattern" would suggest: "something designed or used as a model for making things <a dressmaker's pattern>".
This is further indicated by the term "anti-pattern," which basically means, "something you should avoid." If you should avoid the "anti" then it stands to reason you should follow the "pattern."
For even more demonstrations of this fact, look at subsequent design patterns book, like one by the Head First. These explicitly treat patterns as improvements to be made over some previous attempt at a coding problem. Or hell, check out this description from https://sourcemaking.com/design_patterns -- "Design patterns can speed up the development process by providing tested, proven development paradigms." " Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns."
Whether it was the original intent of the GoF or not, design patterns are mostly perceived to be _good things_ that should be adhered to.
Now, as many have suggested, the wisdom of reaching for design patterns has been increasingly viewed with skepticism, and rightly so. It'll be interesting to see over time how much weight they carry and where the equilibrium lies. My guess is that certain patterns will essentially fade from relevance (if your language has first class methods, do you really need Strategy, for example?) While some (adapter, facade) remain useful ways of handling various problems.
Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems.
The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way.
Don't blame the book - blame the curriculum that's based on it.
Giving name like flyweight to a simple "compression" scheme... The whole thing felt like "duh" to me. Sure it give common ground to people; but none of it felt like something to be written down, even less worshiped like it was.
I also strongly feel about the critics saying that it targets poor OOP languages (cpp, java <5), rendering the whole thing moot in other paradigms.
Everybody independently created singletons and factories and builders, we just all called them different things.
I have the misfortune to remember what some object-oriented codebases looked like before "Design Patterns".
While people—generally those who haven't read the book or completely glossed over the section on the consequences of each pattern—have certainly over-used design patterns, I'll still take that over under-use of them.
An over-engineered too-many-design-patterns codebase is annoying and tedious. A hundred thousand lines of code filled with half-way-reinvented design patterns with its own made up terminology, hard coupling everywhere, piles of global state, and no real architecture to speak of at all is a nightmare.
Furthermore I wonder if peddling one's own book on SO leads to more sales.
Would be great if the OP would tell us how many sales he made through this post (once he got the stats from the Amazon affiliate dashboard).
Do you think it will get decent traffic through SEO in future?
To each their own; shaming the OP on HN for adding affiliate links on their own website, on the product of their own effort, is what I'm trying to point out.
> This list is not much different than making a list of the top selling programming books on amazon.
Something which Amazon does, because likewise 'others may find [it] useful'.
It's great what the OP did and I am really interested in his sales (and he already gave some insights, he's a great guy)
"Nice _______ hack" has an obvious and blatant negative connotation, particularly when it's on its own like that. The implication is that this is just a way to make a few bucks. That's not what the commenter meant, thankfully, but that's only known after further explanation.
You're only free to do this if you know that it's an issue. Unless you know about the affiliate program, you may be supporting this person against your own will. Even if you do know about the affiliate program, you may not know that after you click an affiliate link, the owner of the code gets a chunk of ANY Amazon purchase you make in the next 24 hours, whether or not it is related to the original link.
It seems pretty clear that amazon thinks affiliates provide a useful service. And if you go to amazon because someone shared something that interested you enough to buy it, they've provided you with a service. What exactly is the problem?
So I'm still not getting it. I see no conflict.
It got a fair bit of traction.
Out of my memory, Amazon affiliate links only earned me something like $30, total (I had other sources of revenue via targeted ads, which earned a bit more, but not much).
Great! I now have an AbstractProblemFactory to generate problems on demand.
There are python books, they are sold, keeping them off this list is lame.
Eventually old stuff tails off. I learned C from K+R edition one in the 80s, and the ANSI edition two has now displaced it.
Should be mandatory reading IMHO.
Also, what's up with the phrase "I'm surprised" that always comes up in threads like this: If you believe a book should be higher up, tell us why! Or do you question the author's methodology?
If you misjudge the current significance or influence of a thing, ... so what?
Also could be interesting to see this study, but also weighted based on the number of votes the posts referring to them got.
Like here on HN, Art of Computer Programming gets mentioned a lot. But I've not met anyone who has actually read it. And I own a copy. It's so hard of a read that I am just going to assume anyone who says they did is either lying or Donald Knuth.
I'm suspect of books as a means of information conveyance. They make great mediums for narratives, but narrative is too slow for technical writing. Similarly, I dislike videos, podcasts, and conference talks. Technical writing should be a wiki-like document where terms expand in-place. Start super high-level. Always written in clipped, imperative style. Single line per fact. Like mathematical proofs, but maybe in reverse.
There's something to be said for reading "a great book" from cover to cover. It is really an investment of time, effort and discipline over many days.
I think people (and I include myself) buy such books often with an aspirational intent, to spend that "perfect" weekend or weekends deeply ensconced in the subject matter and coming out of the reading as a different, better and more skilled person. It never happens that way, of course. We're just trying to re-live some past time as students where the world was an oyster of knowledge. For the most part memories of those days are grossly inaccurate, merely softened into nostalgia by the passage of time.
In reality, many of us behave like monkeys continually zapped by shock-collars just trying to keep up with shit that never works right and always living in a profound deficit of knowledge, while drowning in information.
Still, its good to have books, and worthwhile to take insane measures to get alone-time to read them. The short practical ones are best. Comprehensive reference books are good too because you can read just what you need while ducking from life's flying shit.
To understand the first few hundred pages on mathematical preliminaries, the books "The Art and Craft of Problem Solving" by Zeitz and "Concepts of Modern Mathematics" by Stewart, were essential, both of which were recommended here in other book list posts. I also had already read the CS:APP book which covers x86-64 assembly so the MIX introduction was fairly straight forward. http://csapp.cs.cmu.edu/
A book for me that was hard to read, is this book: http://www.cs.cmu.edu/~rwh/pfpl.html Practical Foundations for Programming Languages each page I have to translate with the notation guide, and is a research exercise searching Wikipedia for additional material.
I started volume four but couldn't get my head around the first page, and am very dubious that plowing through it would have any real value.
There is CS on SO, but SO is really designed to, and flooded with, stuff like "how to verify replication on mysql 5.6?" or "How do I install PIP for python on freebsd" and not so much "Lets have us a nice debate about P=NP" or "can someone clearly explain the entire proof of why 3SAT is NP-Complete at like a TED talk level?"
I suppose the programming environment does make it a bit less accessible over time.
- Coding the Matrix, Klein https://www.amazon.com/Coding-Matrix-Algebra-Applications-Co... This has a strong emphasis on LA's utility in CS, and includes concepts outside traditional LA that enrich the narrative.
- Intro to Linear Algebra, Strang https://www.amazon.com/Introduction-Linear-Algebra-Gilbert-S... Strang approaches LA from a practical less-theoretical angle, which makes it very sensible if you're an engineer but may not be as suitable if you're a mathematician.
- Linear Algebra, A Modern Intro, Poole https://www.amazon.com/Linear-Algebra-Introduction-Available... This is a solid text that has worked out most of its bugs over the editions.
- Linear Algebra and its Applications, Lay https://www.amazon.com/Linear-Algebra-Applications-Updated-C... Like Poole, this is also a solid and long running text.
The books by Klein and Strang also benefit from free videos of those courses that are available from Coursera/BrownU and MIT OCW. Klein's is also available on the Kindle.
Each short lecture had a 'Why didn't they tell me that in college!' kind of insight. Transformations, determinants, dot products, cross products everything made sense in a visual way.
But, it scraps user comments that contain Amazon book link from HN and orders them by theirs point. If you wonder how much money Hacker News Book has been made, I would suggest to read this post [2]. The different part with this is that Hacker News Book shows not only the most mentioned books all the time but also per week. Hacker News Book has more diversity of book topics since HN is not limited for programming discussions.
Anyway, I just want to say congratz to the OP for launching this. I think you miss "Show HN" on your post title.
[1]: http://hackernewsbooks.com/
[2]: http://hackernewsbooks.com/blog/making-1000-dollars-in-5-day...
https://www.amazon.com/Effective-Engineer-Engineering-Dispro...
Edit: Here's why I like it: https://henrikwarne.com/2017/01/15/book-review-the-effective...
I've seen that recommended many times but it's a terrible book, IMHO. (I don't remember the specifics why, but vaguely remember the author waffles around without any real points).
Like, the kitchen top example, which is best summarized with two pictures:
http://www.homedepot.com/catalog/productImages/1000/20/20f59...
http://www.homedepot.com/catalog/productImages/1000/ba/ba845...
I find topology influencing brain patterns being a fascinating topic.
Also: http://i.imgur.com/ACe2b51.jpg technician clearly didn't read the book XD