Live data from Hacker News

“Design Patterns” Aren't (2002)

perl.plover.com

91–100 of 133 posts

Re: “Design Patterns” Aren't (2002)

#91
post #49

Earlier quoted context omitted.

> For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. The problem with MVC is that it lost any accurate meaning.If you tell me "my app is MVC", I vaguely understand it has a view, a controller and a model but it doesn't tell me i…

The major problem for me with MVC, is that people build complex applications on an MVC framework and then try to shoehorn various things that are definitely not views, models, or controllers, into the pattern. I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes…

This is why I disagree with the shared language interpretation of design patterns. Once you slap "MVC" or any other name on some code, you'll constantly be second-guessing whether new code is violating the pattern. The goal is to produce working, efficient, secure, maintainable software, not to implement patterns.

I think design pattern books would be more helpful if they deleted all the pattern names and just called the book "A collection of a-ha! moments in C++" or whatever. Readers could skim through the chapters every couple of months until they stop having a-ha! moments. The "patterns" may or may not emerge in the reader's code, depending on what works best for a specific project.

Re: “Design Patterns” Aren't (2002)

#92

Design patterns are good practices that emerge when a language is used by a lot of people. That's it. Nothing less, nothing more. There are two kinds of languages: languages that have design patterns and languages that don't have a lot of users.

So Haskell and Lisp are just lacking users? It has nothing to do with language design?

"functional pearls" == "design patterns" without the architectural garbage.

Re: “Design Patterns” Aren't (2002)

#93

Earlier quoted context omitted.

The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant. And it's wrong. No modern programmer does that any more. When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant. And good riddanc…

> And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly. Number one on HN at the moment for me is "Async/Await support landed in Firefox Nightly". With Async/Await, instead of explicitly queuing callbacks in the main event loop and then re…

Just some comments to your response.

`The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.`

I actually rather a domain model that mirrors the relational layout exactly, as this reduces my time spent in some god unknown framework who is over-engineering with `design patterns`.

`These are design techniques that are appropriate in some situations, but not in others`

Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.

Re: “Design Patterns” Aren't (2002)

#94
post #70

Earlier quoted context omitted.

I mean, lots of people can't read for crap, but at some point, some of the failure to communicate has to fall on the one doing the talking.

Actually. It's always the sender's responsibility, not the receiver. Or, as it's been said: It's not what you say, it's what they hear.

That saying was before the internet, though. There are plenty of people who read something to say what they want it to say, and no amount of planning will ever change that.

Re: “Design Patterns” Aren't (2002)

#96

This is what strongly-typed functional programming languages have been teaching and preaching and practising for years.

It's not really a property of a functional or strongly typed language. Trees are trivial to define and iterate over in e.g. Prolog or Erlang as well. The essential thing here is the first class support for structured/abstract data types.

Re: “Design Patterns” Aren't (2002)

#97

Design patterns are good practices that emerge when a language is used by a lot of people. That's it. Nothing less, nothing more. There are two kinds of languages: languages that have design patterns and languages that don't have a lot of users.

So Haskell and Lisp are just lacking users? It has nothing to do with language design?

Those languages have a ton of patterns. Heck, not only they have patterns, but some of the patterns are studied to the point of having an entire branch of mathematics dedicated to them and have countless properties that can be proven about them. They even predate the language (Category Theory)

Re: “Design Patterns” Aren't (2002)

#98
post #93

Earlier quoted context omitted.

> And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly. Number one on HN at the moment for me is "Async/Await support landed in Firefox Nightly". With Async/Await, instead of explicitly queuing callbacks in the main event loop and then re…

Just some comments to your response. `The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.` I actually rather a domain model that mirrors the relation…

'Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.'

Really? This requires proof? I would have thought it was self evident. Take the Flyweight pattern mentioned previously - appropriate when you have thousands (millions, billions...) of entities and memory is constrained.

Re: “Design Patterns” Aren't (2002)

#99

Christopher Alexander's books: https://archive.org/details/TheTimelessWayOfBuilding https://archive.org/details/APatternLanguage It's also worth reading Patterns of Software by Richard Gabriel: http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf who draws heavily on Alexander's work.

Patterns of Software is worth it just for the Forward.

Re: “Design Patterns” Aren't (2002)

#100
post #41
post #25

Earlier quoted context omitted.

Or, indeed, to look at Alexander's work since this book, which has gone in a direction very similar to the programming world. In "The Nature of Order", Alexander shows how the idea of "good design" is actually best analyzed as just the output of "good process": design is about how a thing unfolds over time and becomes more itself through gradual refinements and responding to its environment. The bigger complaint abou…

> Meanwhile, our "software patterns" embed a centralized power structure both in the code (architect->team lead->junior programmer) and in the world now increasingly controlled by the whims of Silicon Valley founders. None of these things is obvious to me. In fact, this whole paragraph veers in the direction of a conspiracy theory. The rest of your post is quite interesting and I agree that the design of our software…

I certainly don't mean to imply a conspiracy theory, any more than Alexander would say that the past century of poor architecture is deliberately brought about by a conspiracy of architects. It's simply a case of the environment bringing about bad results naturally.

His critique of architecture is this: the quality of a building comes from a process which has to unfold over time and take into account very minute preferences of the kinds of people who will actually inhabit it. A good house design can't be measured by the plans, but only by living in it and seeing what kind of life occurs to the people who are there. Therefore, if you build it by one person's design, or because the renderings look nice as a 2d composition or as a 3d model, or to reduce costs by repeating the exact same things over and over, you will necessarily end up with a bad building. It won't be bad on purpose, but the power structure of the process that built it will have made it bad. (Maybe an architect wanted to win an award, or a developer wanted to sell the properties quickly without worrying about the owners' long-term experience, etc.) And if you want a better building, instead of arguing about design, you should just find a process where more of the decision-making is made by the kind of people who will inhabit the house.

The same is true of software. I do not think most people set out to make bad software. But Conway's law tells us that the result will reflect the organization and process by which it was created. If the process of creating the software is embedded in a large corporate structure where VPs are fighting, that politics is necessarily felt by developers and even embedded into the system. If the process of creating the software is embedded into a VC unicorn and its only chance of growth is to destroy local communities or mistreat workers on a large scale, that will happen.

This is even true just for the people building the software. I've worked at companies where the design team had the power, where the engineering team had the power, or where the project management tool had the power. The same people might work with the same goals, but in these three environments they will produce three very difference pieces of software. And I've worked at companies that had the power to trick money out of customers, which soon replaced the desire to actually provide customers any benefit, and produced its own unique form of engineering environment.

Alexander's critique is aimed at the very idea of "scalability": any one person or process who can determine the way architecture (or software) behaves for thousands of people will get it wrong. Not because the person is bad or the decision is inherently wrong. But because no one decision could possibly be right for all of those people.

Post reply on HN