Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Design Patterns” Aren't (2002)

perl.plover.com

Post reply on HN
Print view View original

41–50 of 133 posts

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

#41

Post by acomar »

asolove wrote: post #25
kornish wrote: post #2

The core points of this talk, as noted in the Addendum [0], is that "we need to take a fresh look at Christopher Alexander". Since that point has been established, it would make a phenomenal follow-up talk to take Alexander's book, which is from the 1970s, and begin a discourse on how his ideas can be applied to modern software engineering and architecture. While the reader takes away from the slides that Alexander h…

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 should tend towards the human and humane.

> Exactly the opposite is true of our usual application of "software patterns". They are often used to produce software that is inherently immoral. Alexander's patterns describe an environment of decentralization of decision-making about both architecture and the community it inhabits.

You should expand on this.

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

#42

Post by throwsincenotpc »

oomkiller wrote: post #39
infinity0 wrote: post #32

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

Can you provide more detail, this is very intriguing. Do you mean that the types are the patterns?

Not the OP but let's take a tree. In F# it's trivial to describe what a tree structure is with the type system. In Java, you'll need to use the Composite pattern and write classes (tree + leaf) to create a tree like structure. Thus the Composite pattern is made irrelevant in F# since an algebraic type system allows you to describe an intent without writing imperative code.

https://en.wikipedia.org/wiki/Composite_pattern

https://en.wikipedia.org/wiki/Algebraic_data_type

Good type systems are a trade-off between complexity and expressiveness, but it's something that is hard to get right. Obviously Java's type system is simpler thus in theory easier to learn. But in practice F#'s is easier to use if understood and might lead to smaller thus more maintainable code bases.

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

#43

Post by jfoutz »

I remember reading this when it was new.

foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard.

On large java projects it seems like composite/facade for days. Those splits seemed to let teams work together and not end up with piles of rubble.

A lot of my understanding of programmer fashion back then was pretty fuzzy. It was easy to ask any team if they were doing extreme programming and they'd all respond, well, kinda. Ask any team if they were using a pattern language, and they'd mumble about UML. Sort of the equivalent of well, kinda.

When you have to write a large project like a compiler or a web browser or something, it's handy to have around. All to often I stare at the empty text window in my ide and question my life choices. I wonder why i didn't learn to weld and why i'm a failure at everything i try. The existential dread fills my soul and i want to just crawl under my desk and cry. In that case, i'll flip through the GoF. Then i tell that endless abyss "I'm going to use the Command Pattern!" The abyss slinks back into the corner quietly murmuring until i feed it a couple beers at the end of the day.

On the other hand, i did quite a bit of perl programming around 2000, so i'm probably weird.

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

#44

Post by ryanisnan »

I'm somewhat familiar with the GoF book and Alexander's A Pattern Language book and I must say, I don't really understand this post.

I wish I had the latter in my hands now for reference (it's at home), but from what I can recall, the book goes into great detail about how to solve specific problems using generalizable solutions. For example, to establish a connection between the space inside of a building with the space outside of the building, consider adding awnings with open archways to the perimeter.

The Design Patterns book, though wildly specific (possibly only because it can be), also deals with solving specific problems with generalizable solutions. For example, creating and ensuring only one instance of an object exists (Singleton - p. 127). The book outlines the motivation for this (e.g. the problem), and defines an abstract for the solution.

Also, the fact that more modern languages can more easily solve some the problems discussed in Design Patterns is, while true, seems like a bit of a red herring. Undoubtedly the patterns themselves have a lifetime of usefulness, and will evolve as we discover new ways of solving new (and old) problems.

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

#45

Post by rezashirazian »

I personally like to implement design patterns when I'm learning a new language. Last year when I decided to learn Swift I did just that. I took on ten different made up problem and solved it using one or more popular design patterns. I wrote up a blog posts and uploaded a final repo for each solution.

If you like to check it out, you can find it here: https://shirazian.wordpress.com/2016/04/11/design-patterns-i...

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

#46

Post by hota_mazi »

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.

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

#47

Post by skrebbel »

jfoutz wrote: post #43

I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…

From the postscript of this slide deck:

It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this:

> I just read through you article "Design Patterns" Aren't. I'm afraid you got it all backwards. At least the iterator example is totally flawed.

Or people spend a lot of time arguing about how foreach is not analogous to an iterator pattern, or how it doesn't do the same thing, or how even if it does, I'm still wrong, because Perl has no analogous replacement for a model-view-controller pattern, blah blah blah. None of this has anything to do what the point of my talk. I really wish I'd left out the thing about the iterator pattern.

Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13, where I make the real point? I have a few theories. One theory is that most of these people are technical experts. They're equipped to consider technical issues, but not much else. When all you have is a hammer, all you can see are the nails. That's what happened to the guy above who said I "got it all backwards." What? The point of my talk was that we need to take a fresh look at Chrsitopher Alexander; if I got it backwards does that mean he thinks we should avoid taking a fresh look at Christopher Alexander? Or does he think that Alexander should be looking at us instead? No, he just forgot about everything after slide 7.

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

#48

Post by [deleted] »

jfoutz wrote: post #43

I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…

[deleted]

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

#49

Post by shubb »

throwsincenotpc wrote: post #33
shubb wrote: post #13

I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. 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. They can also be useful in a context where not eve…

> 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 off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system).

In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems.

I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there.

However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.

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

#50

Post by [deleted] »

jfoutz wrote: post #43

I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…

[deleted]
Post reply on HN