6 ms·

The best explanation I heard of design patterns is, that they are not a template to slavishly follow when producing code, but a common language to talk about co

The best explanation I heard of design patterns is, that they are not a template to slavishly follow when producing code, but a common language to talk about code. So you should be able to go and identify, look, this is an iterator, this is a command pattern, this is a monad, and you have a clear and concise way to reason about your code and talk to other people. The second best explanation is that patterns are often a sign of shortcomings in the language. OP gives the example of iterators. Another example is the visitor pattern. Or async/yield as a replacement for explicit state machines. A thing I'd really like to see in a language would be language level support for the command pattern (being able to capture arbitrary blocks of code, lift the execution to an object, and undo/redo it). Or to be able to include the state of an object in the type system - not like Rust does it with typestates, but to be able to say `Child` is a `Person` where `age < 18`, and if the compiler can't prove that the condition always holds, then it will force you to write the precondition checks or check it at runtime.

BoiledCabbage 6y ago
That last thing you're looking for I believe is called dependent types.
- Smaug123 6y ago
  Dependent types are one way to achieve that effect, but I think what you're actually referring to is "refinement types".
  - centimeter 6y ago
    See LiquidHaskell for probably the most mature SMT-based refinement types implementation.
hosh 6y ago
That’s great, but misses the point. Christopher Alexander’s big ideas involve the people who lives, works, and plays within the architecture. The pattern language was designed for them, so they can participate in the design process of their own living spaces. The equivalent would be a pattern language that app users themselves can use for their apps. Instead of having the app developers drive design with A/B testing to gain user traction (with a societal risk of dark patterns), the users themselves put things together that would work with how they are doing things. The implementation of the code would work from there. Something the end-users can change the code themselves. Smalltalk was designed to allow that level of user participation ... but the legacy we ended up with is OOP and gang of four. If anything, something like TCL/TK is closer to that vision than what we currently have. (What we currently have: mass lockin of consumers and end-users by a different Gang of Four — Facebook, Amazon, Apple, Google). Alexander’s keynote to the ‘96 OOPSLA conference goes into detail about his ideas and how it can be applicable to software engineering. He was imploring software engineers not to make the same mistake that architects did with his pattern language ideas ... but we still made the same mistake anyways.
- jluxenberg 6y ago
  The keynote is a great read! Here's a link for anyone else who is interested: https://www.patternlanguage.com/archive/ieee.html https://www.patternlanguage.com/archive/ieee.html
riffraff 6y ago
for the second thing, there's a famous presentation by Norvig[0] showing how many GoF patterns are "invisible" in powerful enough languages. It's 25 years old, but still interesting. [0] http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/
- AnimalMuppet 6y ago
  I don't think the issue is "powerful enough". I think it's that something is hard to do cleanly in the language. For instance, you could view monads for sequence and IO as "design patterns" in Haskell, because it's hard to do those things in Haskell in a straightforward manner. This is just the nature of the language. It's not that Haskell isn't "powerful enough".
capableweb 6y ago
> The second best explanation is that patterns are often a sign of shortcomings in the language Agree. Came across a blogpost that describes this very well by using Clojure as an example: http://mishadoff.com/blog/clojure-design-patterns/ http://mishadoff.com/blog/clojure-design-patterns/
matheusmoreira 6y ago
The best explanation I've ever seen for design patterns is that they are workarounds for weaknesses of the programming language. Usually Java and its contemporaries. http://journal.stuffwithstuff.com/2010/09/18/futureproofing-uniform-access-and-masquerades/ http://journal.stuffwithstuff.com/2010/09/18/futureproofing-... Factories, for example. They're essentially just constructors. So why not use the new keyword? Turns out new has limitations: - Dependency on the constructed type at the ABI level - Cannot return subtypes of the constructed type - Special keyword, not orthogonal with the rest of the language Singletons, for example. They're essentially classes with static methods and state. Why not use these language features instead of coming up with incredibly convoluted ways to ensure only a single instance of an object has been created? Turns out classes have limitations: - Classes aren't objects - Classes cannot be passed as parameters - Classes cannot implement interfaces The need for all of these patterns simply disappears in a better designed language. In Ruby for example everyone uses factory methods without even realizing it and classes are fully featured objects that can be used in any context.
- catlifeonmars 6y ago
  Interestingly enough, the same phenomenon arises in languages with fewer features. In go, for example, there are no constructors, only functions that return structs. Singletons are just global variables referencing a struct, etc etc.
- commandlinefan 6y ago
  Every programming language has “singletons”: they’re just global variables.
  - wruza 6y ago
    Singleton’s main feature is not that it is globally accessible, but in that it represents a state that cannot be naturally duplicated. The pattern itself lies in a controlled instantiation, where a method/constructor/factory returns a cached value on a second call. Globals are just that – globals.
dwaite 6y ago
> The second best explanation is that patterns are often a sign of shortcomings in the language Or the inverse, the patterns are common enough that a limited form of them is baked directly into the language itself.
kazinator 6y ago
You can't give people the language to recognize and identify a pattern, and then forbid them from using that as a tool to reproduce it. Can you imagine? "You can talk about patterns as a means of description, but don't consciously wield them as a means of production. Also, do not make statements such as 'the architect used this pattern'. Rather say, 'the pattern spontaneously emerged in the work, facilitated by the architect's intuition'." Haha, right.

BoiledCabbage 6y ago

That last thing you're looking for I believe is called dependent types.

Smaug123 6y ago
Dependent types are one way to achieve that effect, but I think what you're actually referring to is "refinement types".
- centimeter 6y ago
  See LiquidHaskell for probably the most mature SMT-based refinement types implementation.

hosh 6y ago

That’s great, but misses the point. Christopher Alexander’s big ideas involve the people who lives, works, and plays within the architecture. The pattern language was designed for them, so they can participate in the design process of their own living spaces. The equivalent would be a pattern language that app users themselves can use for their apps. Instead of having the app developers drive design with A/B testing to gain user traction (with a societal risk of dark patterns), the users themselves put things together that would work with how they are doing things. The implementation of the code would work from there. Something the end-users can change the code themselves. Smalltalk was designed to allow that level of user participation ... but the legacy we ended up with is OOP and gang of four. If anything, something like TCL/TK is closer to that vision than what we currently have. (What we currently have: mass lockin of consumers and end-users by a different Gang of Four — Facebook, Amazon, Apple, Google). Alexander’s keynote to the ‘96 OOPSLA conference goes into detail about his ideas and how it can be applicable to software engineering. He was imploring software engineers not to make the same mistake that architects did with his pattern language ideas ... but we still made the same mistake anyways.

jluxenberg 6y ago
The keynote is a great read! Here's a link for anyone else who is interested: https://www.patternlanguage.com/archive/ieee.html https://www.patternlanguage.com/archive/ieee.html

riffraff 6y ago

for the second thing, there's a famous presentation by Norvig[0] showing how many GoF patterns are "invisible" in powerful enough languages. It's 25 years old, but still interesting. [0] http://www.norvig.com/design-patterns/ http://www.norvig.com/design-patterns/

AnimalMuppet 6y ago
I don't think the issue is "powerful enough". I think it's that something is hard to do cleanly in the language. For instance, you could view monads for sequence and IO as "design patterns" in Haskell, because it's hard to do those things in Haskell in a straightforward manner. This is just the nature of the language. It's not that Haskell isn't "powerful enough".

capableweb 6y ago

> The second best explanation is that patterns are often a sign of shortcomings in the language Agree. Came across a blogpost that describes this very well by using Clojure as an example: http://mishadoff.com/blog/clojure-design-patterns/ http://mishadoff.com/blog/clojure-design-patterns/

matheusmoreira 6y ago

The best explanation I've ever seen for design patterns is that they are workarounds for weaknesses of the programming language. Usually Java and its contemporaries. http://journal.stuffwithstuff.com/2010/09/18/futureproofing-uniform-access-and-masquerades/ http://journal.stuffwithstuff.com/2010/09/18/futureproofing-... Factories, for example. They're essentially just constructors. So why not use the new keyword? Turns out new has limitations: - Dependency on the constructed type at the ABI level - Cannot return subtypes of the constructed type - Special keyword, not orthogonal with the rest of the language Singletons, for example. They're essentially classes with static methods and state. Why not use these language features instead of coming up with incredibly convoluted ways to ensure only a single instance of an object has been created? Turns out classes have limitations: - Classes aren't objects - Classes cannot be passed as parameters - Classes cannot implement interfaces The need for all of these patterns simply disappears in a better designed language. In Ruby for example everyone uses factory methods without even realizing it and classes are fully featured objects that can be used in any context.

catlifeonmars 6y ago
Interestingly enough, the same phenomenon arises in languages with fewer features. In go, for example, there are no constructors, only functions that return structs. Singletons are just global variables referencing a struct, etc etc.
commandlinefan 6y ago
Every programming language has “singletons”: they’re just global variables.
- wruza 6y ago
  Singleton’s main feature is not that it is globally accessible, but in that it represents a state that cannot be naturally duplicated. The pattern itself lies in a controlled instantiation, where a method/constructor/factory returns a cached value on a second call. Globals are just that – globals.

dwaite 6y ago

> The second best explanation is that patterns are often a sign of shortcomings in the language Or the inverse, the patterns are common enough that a limited form of them is baked directly into the language itself.

kazinator 6y ago

You can't give people the language to recognize and identify a pattern, and then forbid them from using that as a tool to reproduce it. Can you imagine? "You can talk about patterns as a means of description, but don't consciously wield them as a means of production. Also, do not make statements such as 'the architect used this pattern'. Rather say, 'the pattern spontaneously emerged in the work, facilitated by the architect's intuition'." Haha, right.