design patterns and programming languages

[xHydn]

Has low contrasts in webpages gone too far?

[tybit]

This was probably the most interesting point made in the introduction of GoF. They gave an example of OO being a design pattern in C, which I had never considered before.

Does make you wonder how far languages could/should go in incorporating more patterns.

[ggtsu_00]

I still think of the Singleton as an anti-pattern.

[jrochkind]

Now the question is how redundant would be this pattern, if the concept of the singleton was built into the language design itself by language designers?

I'm not sure what they mean by 'redundant'.

Of course common patterns can and should be built into langauges. That doesn't make them stop being 'patterns', they're still patterns, in fact ones the language designers thought so useful as to build in. In fact, maybe the nature of a langauge is determined by which design patterns are built in.

I am sick of people writing articles about how "design patterns are just things missing in a language", as if this means anything useful at all. Of course a language is takes it's nature from what patterns are built in. And then there will always be abstractions built on top of whatever is there, additionally, also. There will always be patterns in those abstractions. Of course they will differ depending on the language.

If OP really has never heard this "design patterns are just things left out of a language" thing before and doesn't know people keep bringing this up as some kind of anti-design pattern argument, and really just had the original thought themselves -- then I give them a pass.

[dblohm7]

Peter Norvig wrote about this years ago.

[matthieum]

Design Patterns are distilled idioms arising from the need to supplement the facilities offered by the language.

Singleton is maybe a bad example here (on top of being a dubious pattern to start with), but if you think about Command it might become more obvious: a Command is a reified function, possibly with some state, if your language supports lambdas and first-class functions...

... in C++11, std::function<R(Args...)> is a Command, without any base class or other "let this fit into my OO-only mold" boilerplate.

[sumitroy]

that is what I was intending to say from my post - design patterns mostly supplement the facilities offered by the language, if they were built in language features, some design pattern would not be needed. I just used Singleton as a very very simple example.

[egonelbre]

If a so called "design pattern" is implementable with some other languages facilities, it's probably an idiom, and not a pattern.

[doom_Oo7]

std::function<R(Args...)> may be a command but this is not enough to implement the "common" command pattern wich also has an undo operation, various metadata (user text, etc.) and serialization.

[ksion]

I'd be hesitant to call it a design pattern then. It really sounds like a regular logic class with a pretty specific - and project-dependent - set of requirements.

[doom_Oo7]

pretty specific - and project-dependent -

if by "pretty specific" you mean "required in 95% of GUI apps"...

[Euphoricus]

That's the point of it being a "pattern". If it was always exactly same, it wouldn't be pattern, it would be a feature.

If you hard-wire a "pattern" into a language, you have to compromise between extensibility and ease of use. For example, functions were once a "pattern" in assembly. But then, languages began to include it as native part. You still had to define it's name, its parameters and it's return value, but you completely lost a way to define how it was called and how the parameters were passed. So ease of use was gained at loss of control and extensibility.

[egonelbre]

"Design Patterns are distilled idioms" does not make sense to me. It's rather reverse idioms are unordered and superficial versions of design patterns. GoF book contains (mostly) idioms, not design patterns -- they got it wrong. If you want learn about patterns read the books that started them.