Hacker News Reader

It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about.

The point of patterns is to recognise things that reoccur all the time, ie. DFS is a pattern, FIFO queue as well, so stack, parser combinator, microservice, optimistic locking, proxy, demux etc.

The whole point it to use common volabulary where you can drop this "pattern" suffix when discussing things.

It can be anything, GoF described an idea and couple of patterns in OO context, there are many other books "Analysis Patterns", "Enterprise Integration Patterns", "Patterns of Enterprise Application Architecture" etc.

> It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about.

Arguing about a rainbow or arguing about a color in the rainbow doesn't effect the validity of an argument, I'm not sure your analogy makes any fundamental sense here.

>The whole point it to use common vocabulary where you can drop this "pattern" suffix when discussing things.

Isn't this the purpose of the English language? The "Design Pattern" concept is a redundant concept existing recursively in English. English already provides a "common vocabulary" for "discussing things."

What does design patterns provide on top of that? Only additional complexity and redundancy.

That's why basically all fields outside of programming don't really use the word "design pattern" because it's not necessary. It's a bit of snobbish for a pilot to call a flight technique a "design pattern."

>It can be anything,

And that's why it's pointless. There are even design patterns in poetry if you follow this line of logic. The English language is pretty much the "language" designed to be "anything." For a concept within "English" to be useful it must focus on a smaller subset of "anything."

> What does design patterns provide on top of that? Only additional complexity and redundancy.

understanding each other would be impossible if we just said, e.g. strategy or command.

"we use a strategy" can mean a ton of stuff in the context of a chat between developers in a company. "we use the strategy pattern" will be clear to everyone.

Change the name strategy to something more clear. Kind of pretentious to use a common word "strategy" to describe a specific technique as if it's the most strategic pattern ever.

It's like if someone came up with the "Logic pattern" or "Intelligence pattern."

> Change the name strategy to something more clear. Kind of pretentious to use a common word "strategy" to describe a specific technique as if it's the most strategic pattern ever.

It really makes sense though. I sometimes gave OOP classes to beginner students by having them discover the patterns on their own. Not only they manage to do that easily most of the time, but some of them also manage to give them the correct name, without any prior exposure to the GoF book.

Rainbow analogy meant to mean that often arguments a) focus on narrow aspects and b) don't explicitly define context. Excel patterns will be different from patterns in x86 assembly or high level software architecture.

Sometimes patters are prose about arrangement, sometimes template can be provided and in some cases even fully functional, generic code can be provided.

I don't see anything wrong with calling them "design patterns", software is about "designing" systems and "pattern" reflects the fact that they re-occur, can be reused, can be applied to similar problems etc.

The value is in recognising similar structures, communicating them, reusing solutions to already thought through problems etc.

Poorly designed code can be recognised straight away with ad-hoc, incoherent spaghetti. On the other side there are many poorly applied "pattern" implementations with idiotic verbosity that should be called out as "anti-patterns" instead (just mere change of the language is enough to move a pattern to anti-pattern).

Just because it can describe about anything doesn't make it pointless, just like "best practices" section can be about anything, it doesn't mean it makes it pointless.

Anti-patterns are very useful concept as well.

I don't think you understand my point. Programming techniques and giving names to these techniques is not pointless. What is pointless is pretentiously inflating these techniques and placing them into a pseudo academic field and calling it "design patterns."

>The value is in recognising similar structures, communicating them, reusing solutions to already thought through problems etc.

The English language already reuses concepts. You drive cars. You do not call it the "car driving pattern" and make is part of the concept of "design patterns" This is the pointlessness I am referring to.

>Anti-patterns are very useful concept as well.

Yeah in common English you call it "Bad techniques" or "ineffective methods". Everyone is already 100% aware of the concept of a technique that isn't "good" you don't need to teach people this concept. My argument here is that the name "anti-pattern" is pure snobbery. It's like calling standing still "anti-movement."

No new concept was introduced by the word "anti-pattern." Anti-pattern refers to a very simple concept that every single human understands. The pretentiousness is in the word and inflates the perception of this concept to the point where someone like you thinks "anti-pattern" is a completely new mind blowing concept (It's not).

It feels more like you had to deal with some idiot abusing word "pattern" than anything else; "pattern", "method", "solution" is "potato potato", what is important is recognising similarities, naming higher level concepts for good communication and implementing systems organised around sound abstractions as opposed to adhoc, shallow, not thought through mess holding on rolls of scotch tape.

> It's a bit of snobbish for a pilot to call a flight technique a "design pattern."

What? Why do you think this?

No more recipes from cookbooks. Those are "design patterns" from a book on "nutritional design patterns."

I take it back, everything is a design pattern now. I see the light.

How big is that chip on your shoulder?

Whoa, please don't cross into personal attack.

https://news.ycombinator.com/newsguidelines.html

See, Mark, I told you this was a violation of of the rules. We'll talk soon.

Design patterns aren't recipes, they're common applications of techniques. The use of gelatinized starch as a thickener for sauces (i.e. a roux) could be considered a "cooking pattern".

Every variable in a cooking recipe can be substituted and modified making a recipe a technique that is applicable to different sets of materials and conditions.

> This may piss some people off and get me a load of downvotes, but honestly IMO I find design patterns to be just snobbery

100%. I recently was interviewing so I decided to brush up on some design pattern terminology because plenty of job postings reference them and I didn't study them in school.

I was blown away by how much of it's just complex-sounding terms for simple concepts.

I was also surprised how poorly defined they really are.

Agreed.

Also note that school generally doesn't teach it because these patterns don't have any formal basis in theory. It's the complex vocabulary that gives these things more academic weight than they actually have. "Tricks of the trade" doesn't sound as rigorous as "Design Patterns" but really it's the same thing.

> You don't find carpentry workers referring to domain specific vocabulary as design patterns.

they don't call it a "design pattern", but a "technique".

see e.g. https://www.amazon.fr/Woodwork-Step-Carpentry-Techniques-Mad... or http://www.basiccarpentrytechniques.com/

to me, "hip roof framing" or "trench shoring" definitely sounds like "applying a visitor" or "implementing an abstract factory" would sound to a non-software-engineer carpenter.

Yeah and a technique is part of the "English" language. Techniques exist everywhere.

But in computer science they had to basically make the same concept sound more snobbish. These aren't programming techniques, they are "design patterns."

I agree with you and the TFA. I also think that naming the book "Design Patterns" and calling the techniques "Patterns" is unfortunate and misleading.

But I think calling them like that is what made the book as famous and as is it. If the book were called "OOP Programming Techniques" it wouldn't have the same popularity. Of course that doesn't make it right.

As a book it has served its purpose at the time, but by portraying what are basically "band aids" to limited programming languages (Norvig 1996) as foundational CS knowledge, it ossified the development of OOP and CS itself by a few years IMO.

I share your distaste for cargo cult programming, but ... iterating over a list can be done in multiple ways, and doesn't necessarily mean one is using the iterator pattern. Using the jargon "iterator" to refer to an object or closure that tracks the state of iteration has benefit in making conversation more concise.

Sure, my point is don't attach the word "pattern" to the end and don't call it a "design pattern"

You're just iterating through a list and calling it "iterating" is perfectly fine.

Don't get me wrong. Naming things to abstract away complexity is perfectly fine and a foundational aspect of the English language.

Naming something the "iterator pattern" and calling it a concept within the sub field of "Design patterns" is the snobbery I'm referring to.

The iterator pattern is the use of an object or closure to encapsulate the state of the iteration. This is distinct from using a loop induction variable in the same scope as the loop block itself. In a language like C, which doesn't provide iterators by default, it seems reasonable to call that a design pattern.

It seems more reasonable to say you're iterating through a collection.

It also seems more reasonable to just leave it as a programming technique rather then give it artificial weight and call it some bloated unnecessary academic term "design pattern"

Ok, call it the iterator technique, but there's a difference between using the iterator technique and iterating, which you seem to be refusing to acknowledge.

No actually I'm not completely grasping your argument. You described iteration earlier but I don't see any distinction with any definition of iteration I know of.

I'm guessing your talking about how iteration is implemented versus the action of iteration. Both are one in the same.

Using a loop induction variable is a form of iteration over the elements of a sequence, but it is not using an iterator (technique, pattern, or whatever you want to call it).

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

Heck, originally, looping was performed by physically looping your instruction tape, and a break was pausing the machine to physically break the tape. Talk about a fragile design pattern!

The implementation matters. That's why people suggest using the iterator technique. It's not the best strategy for all cases, but it's generally better practice.

The index of a variable functions as an iterator for the iterator pattern. It still applies. There's not distinction here. But my point is also more general it doesn't apply to just iterators.

Scope matters. The purpose of the iterator is to encapsulate the state. An induction variable is not an iterator. A physical loop of tape is not an iterator. I'm starting to doubt your general point, because the specific isn't holding.

Take a look at the Wikipedia page for iterators, under the heading "contrasting with indexing". It's not explained super-well, but it covers a few topics.

If you say you are iterating through a collection using a while loop and not an iterator, then you are confusing people by using the wrong word for things.

Design patterns is a formalism behind common patterns in software, and part of that formalism is that they are named.

Obviously you don't need all that formalism every time you talk about patterns, the same way you don't talk about the laws of arithmetic every time you do math.

Exactly math doesn’t call informal but repeatable techniques “design patterns,” and publish a book about it. why should programmers make a misguided claim that these same techniques are also formal and give it a pretentious name.

Design patterns is a unique phenomenon in programming. No other field is pretentious enough to refer to domain specific vocabulary as design patterns.

> Doesn't english and vocabulary fill this space?

Yes, and no. English doesn't by default fill the space of words that are shorthands for domain specific ideas. The practitioners coin the terms.

> You don't find carpentry workers referring to domain specific vocabulary as design patterns.

Every field has its conventions, shorthands, patterns, etc. They might not call them design patterns. Lawyers, for example, have tons and tons of terms that are shorthand for complex concepts, and you wouldn't understand them without first studying them, even if they are strictly made of otherwise mundane English words. For example, "strict scrutiny", or "reasonable person".

>English doesn't by default fill the space of words that are shorthands for domain specific ideas.

That was a rhetorical question. I beg to differ. English does fill the space of all kinds of of domain specific areas. Practitioners may invent new vocabulary to use within the English language but in the end they are still using English.

In fact even when you talk about "Design patterns" You are still using "English" it's inescapable. I'm saying the extra layer of "design patterns" as a "field" is not necessary. No other "domain" is snobbish enough to call their techniques "patterns" and group them as "design patterns" and fill the field with all this jargon like "strategy pattern." It's just programming techniques, carpentry techniques and the like.

I agree with 99% of what you said - I think a lot of simpler patterns aren't actually "patterns" in the first place, iterator probably being the best example. However, for things like factories and things more complicated than that, it is helpful to have a lot of context come along with just a word or two. If someone says "facade" or "memento" you know exactly what they mean.

Sure call it an iterator, call it facade. Naming things for the purpose of abstracting away complexity is one of the foundational functions of the English language.

But there's no need to group what is essentially just English Vocabulary into another sub category of "language" prefixed with "design" and then post-fix all internal concepts with "pattern."

FP practitioners are guilty of this as well, when talking about "the Maybe monad" or "the IO monad".

Naming stuff is ok. I understand this. It's done in every field.

But calling the "naming of things" a "design pattern" is pretentious. Nobody calls Monads the "Monad pattern" and categorizes it as a sub field of "design patterns."

It's just like how we abstract the concept of getting into a car and commanding the car under the word "driving." That's fine. What's wrong is if We called it the "driving pattern" and place it an area of study within the automobile field called "design patterns."

Imagine if some expert race driver publishes a driving book called "Design patterns" then with an analogy relates it to architecture. Why not just call the book "Driving techniques" and eschew the useless analogy?

I'll tell you why the GoF did this. Because "Design patterns" sounds more academic, and the catharsis of realizing the analogy between architecture and programming techniques inflates the perception of what these concepts actually are. In the end these are just programming tricks or techniques.

But both those things are Monads. They follow the Monad laws, the conform to a certain Monad interface, they both have bind and return, they behave like Monads.

To me the problem with using "pattern" is that it suggests a relationship when there's none, other than all of them being techniques that were presented in the same book.

Prematurely naming them also prevented other people from finding better names. For example, other techniques that are in the same idea-space, such as "Inversion of Control" and "Dependency Injection" don't need the "pattern" suffix, for example, but are still understandable.

FP programmers call their patterns Typeclass Laws.

Mathematicians aren't building/designing things all day long so they don't need this word.

"A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language." (Wikipedia on Pattern Language).

>Mathematicians aren't building/designing things all day long so they don't need this word.

Not true, they build proofs. Within proofs there are many many common techniques, aka "patterns."

Either way you seem to imply that "patterns" are for people who "build" things, which isn't emphasized in your definition below:

>"A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language."

The problem with the above definition is that English vocabulary already communicates what a pattern does perfectly fine. What is the point coming up with an over complex name and postfixing all of these things with "pattern?" It's basically a redundant concept.

In fact, my communication with you at this very moment is employing many many common patterns. Check the pattern in the previous sentence "many many." I call it the double emphasis pattern and I've used that pattern twice in this reply. I'll write more about it in my book on Design patterns for English communication.

I think the simplest response I can give to this is the "above defition" is of a pattern language, not a pattern.

A pattern language is an organized and coherent set of patterns. They are developed holistically to work in relation with each other. They're designed to be combined together - as sequences, in parallel, as contrasts - and also to be as "platform-agnostic" as possible.

For example, Alexander's book helpfully includes a ton of points on how to combine the various patterns in the book, and a healthy "see also:" section to get alternative ideas or just areas of overlap between them all.

And the patterns in the book are about the physical, environmental, and social needs of humans (the problems) and how they can be met trough architecture and infrastructure.

It's very distinct from just "a list of patterns." They're always described in service to the whole, in relation to the others.

For the English language, I would say Aristotle's Rhetoric is closest in spirit; whereas Elements of Style is clearly more a "list of patterns"

Other "pattern language"-style books I can think of are The Prince by Machiavelli; Capital by Marx; 22 Immutable Laws of Marketing by Ries and Trout; Diffusion of Innovations by Rogers; and High Output Management by Andrew Grove.

I would also say the original C2 Wiki comes closest to creating a "bottoms-up" pattern language. Here's the entry on A Pattern Language - https://wiki.c2.com/?PatternLanguage

But these books aren't explicitly set up as pattern language books - nor are many others. Very few books (not even the GoF) are put together so well and as comprehensively as A Pattern Language. It's truly a masterpiece.

I think that's where your bias lies. If you think a book is a masterpiece no amount of evidence can flip that bias.

You post basically declares every scientific or academic or professional field as "pattern languages."

Then you conclude to say.that there are books much more well put together then the gof book. I agree, like pretty much every axiomatic math book that proves each theorem starting from base axioms is more elegantly put together than GoF.

And none of these books have the pretentiousness to call what they're doing a "pattern language." The concept is unecessary and is only used by books that are actually very informal. The Gof book is essentially just "oop programming tricks" retitled to "design patterns" to sound more academic when in fact its so far from academia, most schools don't teach it as part of foundational computer science.

Also all the books you defined are informal and opinionated. Especially capital by marx. None of those books come close to the rigor of "pattern languages" established by even a basic math book on number theory.