Hacker News Reader

Comment by jeremiep | Hacker News Reader

Wasn't that the joke when the book was first released? All design patterns merely handle the lack of anonymous and first-class functions.

View on HN

..and closures

... and pattern-matching. But yeh, patterns are a sign of a weakness in the language. And it's not infrequent that patterns really turn out to be anti-patterns.

> But yeh, patterns are a sign of a weakness in the language.

That line of reasoning never ceases to be amusing by how silly and self-defeating,particularly as those who make those claims try to pin ignorance on others while manifesting their own ignorance. They seem to be entirely oblivious to the fact that the main goal and usefulness of patterns is to communicate intent and provide semantics and use a common language to describe common problems. A function is a function but a strategy pattern isn't a state pattern. Those who miss this fundamental difference are totally oblivious to what design patterns actually are.

> the main goal and usefulness of patterns is to communicate intent and provide semantics and use a common language to describe common problems

No, that's the role of programming languages. If you can't do it in your programming language of choice, you aren't using a high-level enough one.

Right, a function isn't a pattern. But a pattern in the common usage is some functionality that needs to be communicated outside the core language. In languages that offer that functionaliry in the core, I would argue there no longer "patterns". I don't think many of the gof patterns are remarkable in a modern Language like clojure, because the options are obvious.

> But a pattern in the common usage is some functionality that needs to be communicated outside the core language.

What a truism. Programming languages exist to implement functionalities outside of the core language. So what? Does this mean that software projects aren't designed, and parts of the design may not be shared and integrated in other projects? Those working on software projects still need to discuss design issues, and it's easier and more efficient to assign names to recurring patterns. Those who don't understand this issue and opt to manifest their ignorance by criticizing the existence of patterns are simply fools who try to feign competence by ridiculing the consequences of their own ignorance.

Names are useless unless they convey a precise meaning. And, if you can't write down that meaning in a formal system (such as a programming language or mathematics), then it can't be that precise after all.

> Names are useless unless they convey a precise meaning.

They do convey a precise meaning. You simply fail to understand it, and even make it your point to complain about something you systematically fail to understand where you stand on your dunning-kruger corner.

> They do convey a precise meaning.

Then formalize it. Mathematically.

You are aware you're asking to "mathematically formalize" algorithm constructs, right? Either you know nothing about the subject or are trolling this thread in spite of being completely removed from the field.

Algorithms are mathematical objects, and they sure as hell can be formalized. Alas, software design “patterns” aren't algorithms. And, so long as they resist formalization, they are non-ideas.

Accusations of trolling are completely unwarranted.

It should be clarified that the whole thing is about functional patterns in Clojure that are expressing same functionality as well known OO patterns in Java.

Adding "it's just..." in front of functional patterns doesn't make them non-patterns.

Patterns are named ideas on how to approach/solve similar problems.

They are not tied to OO programming, Java, they are not good or bad per-se; it's just a cookbook with recipes that have names.

Otherwise nice format, I like it.

Presumably the point is that most functional programmers wouldn't have bothered giving dedicated names to, say, “strategies” or “factories”, more or less the same way nobody would bother calling “(a + b) / 2” the “average pattern”.

Maybe they would call it a monoid or something much clearer like that.

Fortunately you have about an hour to edit your comment into something that, at least, is not patently stupid.

> nobody would bother calling “(a + b) / 2” the “average pattern”.

don't you mean.... the arithmetic mean?

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

Oh my god, and people bother themselves calling the addition o sequences of numbers as summation.

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

Where does this madness end? These morons even bothered themselves forming whole fields in mathematics by studying adding numbers

https://en.wikipedia.org/wiki/Series_(mathematics)

Why is humanity so wrong about such a simple concept? Why is everyone bothered to give dedicated names to concepts you fail to understand?

The mean is an precisely defined operation in mathematics, not a vaguely defined “pattern” in software engineering.

I insist: You only need “patterns” when you can't articulate your ideas precisely in a formal language, such as a programming language or mathematics.

The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries. You know what's better than having a shared vocabulary you expect everyone to know from a book? Having a shared vocabulary defined in the language and accessible not only to programmers but to the compiler and tooling as well.

> The point is that patterns shouldn't be patterns in books—they should be abstractions in libraries.

And how you go about developing those "libraries"?

By writing code using the programming language, isn't it?

Just because C++ and Java and Python and many other programming languages added support for iterators and generators it doesn't make them out to be less of a design pattern. Heck, supporting emcapsulation and composition and information hiding doesn't make a facade pattern, as well as its concept and the semantics of implementing one, magically disappear.

This fundamental fact regarding design patterns is what these self-important fools miss. While they are too busy grandstanding with their criticism, they are actually showing off their ignorance and demonstrating they don't even understand the basic problems solved by design patterns, which are orthogonal to programming languages and their features.

> A function is a function but a strategy pattern isn't a state pattern.

Funny you should mention that. What does "state pattern" communicate about the design, that "state machine" does not? Because state machine is a well-established term, applicable across paradigms.

And what can you communicate with "strategy pattern"? I mean, pick a design for solving a problem (any problem), and explain the design in writing using the words "strategy pattern". I bet I can rephrase it to be at least as simple, and use common-language terms that predate the "strategy pattern".

I've heard people try to take this stance before, that "design patterns are a way to communicate your designs", but to me, it doesn't hold water. How do you communicate your designs simpler, with them?

In a strong language patterns don't exist? Everybody always solves every problem in a completely unique way?

Two people shouldn't be solving the same problem. So, yes, in a perfect language no two people would solve a problem in the same way.

So no two people would ever use lists or maps?

What pattern is there on using those structures? It's barebones syntax and nothing else.

No idea what you mean by “strong language”, but a high-level programming language is one in which patterns are expressible directly as libraries or frameworks.

Reply on news.ycombinator.com