4 ms·

I wish we had a new Design Patterns book in 2020. GoF book is well obsolete, since then OO has faded, JS & Python are the the most common tools, even Java is u

I wish we had a new Design Patterns book in 2020. GoF book is well obsolete, since then OO has faded, JS & Python are the the most common tools, even Java is unrecognizable with Lambdas and functional features everywhere. Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal. The GoF needs an update.

mumblemumble 6y ago
> Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful I'd argue that they still are relevant. The only thing that's seen more impressive growth than memory volume is the relative cost of a cache miss. So the great irony is, one of the most efficient ways to sabotage your CPU power is to make use of all that RAM.
- arjun-menon 6y ago
  > The only thing that's seen more impressive growth than memory volume is the relative cost of a cache miss. Has the cost of cache misses truly increased? (Also: relative to what?) Today's CPUs have far larger caches than in the past (and not to mention a lot faster too), so the number of cache misses and the time cost of each cache miss for the same program on a modern CPU should be much lower—right?
  - gjulianm 6y ago
    I think the parent talks about the relation between miss/hit, not the actual cost of a miss. In other words, if a piece of code took 100ms with 100% cache hit and 200ms with 0% hit but now it takes 20ms with 100% hit and 100ms with 0% hit, your code is 5 times slower with cache misses, when before it was only 2 times slower. Yeah, it's faster than before, but the relative cost in terms of your available performance has increased. And I'd agree with that statement. I have been doing some heavy profiling lately and it's fun to see how good are modern processors at executing even non-optimal code if it's cache friendly. However, the moment it needs to hit L3 cache or further, the pipeline stalls and performance goes down the drain.
  - mumblemumble 6y ago
    It depends a lot on how you frame it. The absolute time spent waiting on memory has improved, although not at nearly the rate of other things[1]. When I was young and rosy cheeked, the performance gap was only order of magnitude, but it now spans more than three. So the cost of a cache miss, in terms of number of CPU cycles lost (which is what I meant by the term "relative") has grown by quite a bit. Worse, while we keep adding CPU cores, there's still only the one memory bus. Even if one core is waiting on a memory access, the others can keep working - but only for as long as they don't need to access memory, either. Which may not be for very long if, for example, you're allocating lots of short-lived objects, or using persistent data structures. In memory intensive applications, things can quickly back up so that all the cores are blocked up, waiting in line behind each other for data. If you look at the cost of this in terms of per-core CPU time rather than wall clock time, things start to look pretty icky. And this can be a devious thing, because it's an effect that isn't typically shown in the output of a performance profiler. On the cache side, it's true that caches are bigger. But then we run into that old saw about software people's greatest achievement being to negate to efforts of hardware people. Caches get twice as big, and programmers decide the best thing to do with all that extra space is using 64-bit numbers as a matter of habit, or perhaps even switching to programming languages that don't have 32-bit numbers. Or by switching to dynamic languages that cram the cache full of pointers and object headers. Things like that. Which isn't to say that all of these practices are objectively bad - spending computing resources on human productivity is typically a very good trade-off. Just that there's no such thing as a free lunch. Memory usage still has a performance cost, and, in stark contrast to how things worked a quarter century ago, it now kicks in long before the system starts experiencing actual memory pressure. 1: See, for example: https://assets.bitbashing.io/images/mem_gap.png https://assets.bitbashing.io/images/mem_gap.png
    - ncmncm 6y ago
      Nowadays there are increasingly many memory buses. I think the top-end Epyc uses 8 of them, that may each simultaneously have an operation in flight, each with its own queue. Lesser Zen2s have four memory buses.
      - mumblemumble 6y ago
cle 6y ago
I'd rather just see the idea of Proper Noun Design Patterns die, in my experience they've done more harm than good by not emphasizing their tradeoffs. My struggles with over-eager developers turning everything into a smorgasbord of over-abstract design patterns outweighs any benefits I ever got from them (there's a similar tendency with some functional programming enthusiasts). I think we're better off tucking these into language documentation and calling them "idioms", to keep the zealots and dogmatists from turning them into thought-terminating cliches. > Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal. I don't agree, they are still widely used in most languages, but are often hidden behind abstractions so that developers don't need to know about them.
- whimsicalism 6y ago
  This is a problem with bad developers - the general idea of patterns makes a ton of sense because pattern recognition is important and it makes it easier to reason about the properties of various parts of code.
  - cle 6y ago
    Blaming bad developers and hoping for them to try harder isn't going to make anything better. I totally agree that patterns are important and useful, I just think that the way they're presented and over-emphasized is net-harmful, and that by changing that we can make the situation better.
    - rualca 6y ago
      >>Blaming bad developers and hoping for them to try harder isn't going to make anything better. Well, but it does, doesn't it? I mean, the first step to solve a problem is to identify it. Clearly, the problem with design patterns is that clueless developers have no idea what they are talking about, thus they mount incomprehensible complains that make no sense if you'd understood the basics. Developing software is a complex endeavor that is much more than declare variables and nest control statements. There is way more to developing software than what is covered by a "intro to language X" or "learn framework Y" blog post. If a programming language gives you brick and mortar, you start to talk about retaining walls and windows and stairs. If a programming language gives you gears and screws and bearings and springs, you start to talk about pumps and differentials and dampers. So what's hard to understand in needing design patterns to talk about components and solutions to common problems?
mhh__ 6y ago
I feel like the focus now should be on architecture rather than patterns. We know how to write good widgets now, but designing your program such that it scales well and doesn't rot is still difficult (e.g. lots of mutable state is fast but is much harder to scale when you introduce concurrency)
- rualca 6y ago
  > I feel like the focus now should be on architecture rather than patterns. It's really the same issue, isn't it? specially if you follow a component-based design. The difference is only in the level where the discussion is set. Having said that, personally I've seen a tight correlation between those who criticize about design patterns and those who criticizd software architecture. In fact, the higher the abstraction, the higher the criticism. It seems the furthest the subject is from the critic's comprehension and experience, the more their criticize.
pfranz 6y ago
I've heard design patterns described as "missing language features" and when you look at the GoF book, many don't make sense in languages other than C++ because they're already built-in or unnecessary. If you're looking for a newer book on design patterns, I've heard Head First Design Patterns (2004) suggested as much more approachable. The cover image is a bit goofy and screams mid-2000s. I've only seen excerpts, but GoF if I remember correctly is very dry and doesn't explain some things very well. Head First Design Patterns looks to be written for Java, but I don't remember having trouble understanding and implementing them in other languages. Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software 2nd Edition will be released on December 29. I guess this is the newer edition? It shares 2 of the authors.
- dblohm7 6y ago
  A lot of that stuff isn’t necessary anymore in Modern C++ either.
- rualca 6y ago
  > I've heard design patterns described as "missing language features" and when you look at the GoF book, many don't make sense in languages other than C++ because they're already built-in or unnecessary. I've heard that statement before and it really never made any sense to begin with. Design patterns describe higher-level concepts. Just because a higher level concept made its way into a standard library that doesn't male it go away, nor does it eliminate the need to reason and have higher level discussions involving it. Take for example C#. Does it make sense to talk about event loops in C#? Or observers? Or callbacks? Because those are all design patterns, aren't they? Great, you don't need to add a lot of boilerplate code to get to use one, but you're still using the concept and reasoning about the system in terms of these patterns and their features and properties, right? Just because I can buy a ready-made roof instead of having to cut down trees or buy the wood somewhere, that doesn't mean that a roof is no longer a roof.
- x87678r 6y ago
  I agree it isn't about the language features, but designs have changed a lot. 2nd ed could be great - thanks, I'll try to get a copy when the price settles down a bit.

mumblemumble 6y ago

> Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful I'd argue that they still are relevant. The only thing that's seen more impressive growth than memory volume is the relative cost of a cache miss. So the great irony is, one of the most efficient ways to sabotage your CPU power is to make use of all that RAM.

arjun-menon 6y ago
> The only thing that's seen more impressive growth than memory volume is the relative cost of a cache miss. Has the cost of cache misses truly increased? (Also: relative to what?) Today's CPUs have far larger caches than in the past (and not to mention a lot faster too), so the number of cache misses and the time cost of each cache miss for the same program on a modern CPU should be much lower—right?
- gjulianm 6y ago
  I think the parent talks about the relation between miss/hit, not the actual cost of a miss. In other words, if a piece of code took 100ms with 100% cache hit and 200ms with 0% hit but now it takes 20ms with 100% hit and 100ms with 0% hit, your code is 5 times slower with cache misses, when before it was only 2 times slower. Yeah, it's faster than before, but the relative cost in terms of your available performance has increased. And I'd agree with that statement. I have been doing some heavy profiling lately and it's fun to see how good are modern processors at executing even non-optimal code if it's cache friendly. However, the moment it needs to hit L3 cache or further, the pipeline stalls and performance goes down the drain.
- mumblemumble 6y ago
  It depends a lot on how you frame it. The absolute time spent waiting on memory has improved, although not at nearly the rate of other things[1]. When I was young and rosy cheeked, the performance gap was only order of magnitude, but it now spans more than three. So the cost of a cache miss, in terms of number of CPU cycles lost (which is what I meant by the term "relative") has grown by quite a bit. Worse, while we keep adding CPU cores, there's still only the one memory bus. Even if one core is waiting on a memory access, the others can keep working - but only for as long as they don't need to access memory, either. Which may not be for very long if, for example, you're allocating lots of short-lived objects, or using persistent data structures. In memory intensive applications, things can quickly back up so that all the cores are blocked up, waiting in line behind each other for data. If you look at the cost of this in terms of per-core CPU time rather than wall clock time, things start to look pretty icky. And this can be a devious thing, because it's an effect that isn't typically shown in the output of a performance profiler. On the cache side, it's true that caches are bigger. But then we run into that old saw about software people's greatest achievement being to negate to efforts of hardware people. Caches get twice as big, and programmers decide the best thing to do with all that extra space is using 64-bit numbers as a matter of habit, or perhaps even switching to programming languages that don't have 32-bit numbers. Or by switching to dynamic languages that cram the cache full of pointers and object headers. Things like that. Which isn't to say that all of these practices are objectively bad - spending computing resources on human productivity is typically a very good trade-off. Just that there's no such thing as a free lunch. Memory usage still has a performance cost, and, in stark contrast to how things worked a quarter century ago, it now kicks in long before the system starts experiencing actual memory pressure. 1: See, for example: https://assets.bitbashing.io/images/mem_gap.png https://assets.bitbashing.io/images/mem_gap.png
  - ncmncm 6y ago
    Nowadays there are increasingly many memory buses. I think the top-end Epyc uses 8 of them, that may each simultaneously have an operation in flight, each with its own queue. Lesser Zen2s have four memory buses.
    - mumblemumble 6y ago

cle 6y ago

I'd rather just see the idea of Proper Noun Design Patterns die, in my experience they've done more harm than good by not emphasizing their tradeoffs. My struggles with over-eager developers turning everything into a smorgasbord of over-abstract design patterns outweighs any benefits I ever got from them (there's a similar tendency with some functional programming enthusiasts). I think we're better off tucking these into language documentation and calling them "idioms", to keep the zealots and dogmatists from turning them into thought-terminating cliches. > Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal. I don't agree, they are still widely used in most languages, but are often hidden behind abstractions so that developers don't need to know about them.

whimsicalism 6y ago
This is a problem with bad developers - the general idea of patterns makes a ton of sense because pattern recognition is important and it makes it easier to reason about the properties of various parts of code.
- cle 6y ago
  Blaming bad developers and hoping for them to try harder isn't going to make anything better. I totally agree that patterns are important and useful, I just think that the way they're presented and over-emphasized is net-harmful, and that by changing that we can make the situation better.
  - rualca 6y ago
    >>Blaming bad developers and hoping for them to try harder isn't going to make anything better. Well, but it does, doesn't it? I mean, the first step to solve a problem is to identify it. Clearly, the problem with design patterns is that clueless developers have no idea what they are talking about, thus they mount incomprehensible complains that make no sense if you'd understood the basics. Developing software is a complex endeavor that is much more than declare variables and nest control statements. There is way more to developing software than what is covered by a "intro to language X" or "learn framework Y" blog post. If a programming language gives you brick and mortar, you start to talk about retaining walls and windows and stairs. If a programming language gives you gears and screws and bearings and springs, you start to talk about pumps and differentials and dampers. So what's hard to understand in needing design patterns to talk about components and solutions to common problems?

mhh__ 6y ago

I feel like the focus now should be on architecture rather than patterns. We know how to write good widgets now, but designing your program such that it scales well and doesn't rot is still difficult (e.g. lots of mutable state is fast but is much harder to scale when you introduce concurrency)

rualca 6y ago
> I feel like the focus now should be on architecture rather than patterns. It's really the same issue, isn't it? specially if you follow a component-based design. The difference is only in the level where the discussion is set. Having said that, personally I've seen a tight correlation between those who criticize about design patterns and those who criticizd software architecture. In fact, the higher the abstraction, the higher the criticism. It seems the furthest the subject is from the critic's comprehension and experience, the more their criticize.

pfranz 6y ago

I've heard design patterns described as "missing language features" and when you look at the GoF book, many don't make sense in languages other than C++ because they're already built-in or unnecessary. If you're looking for a newer book on design patterns, I've heard Head First Design Patterns (2004) suggested as much more approachable. The cover image is a bit goofy and screams mid-2000s. I've only seen excerpts, but GoF if I remember correctly is very dry and doesn't explain some things very well. Head First Design Patterns looks to be written for Java, but I don't remember having trouble understanding and implementing them in other languages. Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software 2nd Edition will be released on December 29. I guess this is the newer edition? It shares 2 of the authors.

dblohm7 6y ago
A lot of that stuff isn’t necessary anymore in Modern C++ either.
rualca 6y ago
> I've heard design patterns described as "missing language features" and when you look at the GoF book, many don't make sense in languages other than C++ because they're already built-in or unnecessary. I've heard that statement before and it really never made any sense to begin with. Design patterns describe higher-level concepts. Just because a higher level concept made its way into a standard library that doesn't male it go away, nor does it eliminate the need to reason and have higher level discussions involving it. Take for example C#. Does it make sense to talk about event loops in C#? Or observers? Or callbacks? Because those are all design patterns, aren't they? Great, you don't need to add a lot of boilerplate code to get to use one, but you're still using the concept and reasoning about the system in terms of these patterns and their features and properties, right? Just because I can buy a ready-made roof instead of having to cut down trees or buy the wood somewhere, that doesn't mean that a roof is no longer a roof.
x87678r 6y ago
I agree it isn't about the language features, but designs have changed a lot. 2nd ed could be great - thanks, I'll try to get a copy when the price settles down a bit.