4 ms·

I think a partial cause for the loss of importance is due to design patterns being relatively oriented towards OOP. With the move away from OOP and towards func

I think a partial cause for the loss of importance is due to design patterns being relatively oriented towards OOP. With the move away from OOP and towards functional programming and type theory, the term fell away because the design patterns relevant in those domains are not really called "design patterns".

slaymaker1907 5y ago
Functional programming still has patterns, they are just different patterns. For example, (let loop ([arg _]) ...) in Scheme for iteration. Monads are another one. Another common one is a foreach method/function for iteration over data instead of using iterators.
- akavi 5y ago
  > Monads Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces) > a foreach method/function for iteration over data Again, "just" an interface a data type can implement/obey.
  - deleted 5y ago
    [deleted]
  - jcelerier 5y ago
    Patterns being reified as language objects don't make them not-patterns. Trusty old function calls are still patterns, only reified from asm routines and procedures.
- Aeolun 5y ago
  Something at the level of a loop does not strike me as something you can call a design pattern.
  - lotophage 5y ago
    I agree. I'd be more inclined to call something like that an idiom.
- feanaro 5y ago
  > Functional programming still has patterns, they are just different patterns. Yes, exactly what I meant by > the design patterns relevant in those domains are not really called "design patterns". I was thinking of things like algebraic or categorical laws, or invariants.
endymi0n 5y ago
I've had the same thought. I've never seen it confirmed by anyone, but to me, a lot of the original design patterns were stopgap conventions to patch shortcomings in the languages of their time (mainly early Java). Just look at the Visitor pattern. It's a convention to expose an "accept" method that can be "visited". That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. Going in depth, you can see the same possibilities everywhere. "Proxy" should probably be a registerable middleware, etc. etc. Then again, I might be biased. Design Patterns already let my BS detector go bonkers 15 years ago when I encountered them first, as as academization and complication of software by self-indulgent "enterprise programmers" that I couldn't ever see any advantages to (and these days, I feel enjoyably vindicated). Funnily enough, in this way they were quite anti-academic, as they came from original research of the "Gang of Four" and I've never seen scientific proof they actually made anything better. I stand to be corrected though.
- fiddlerwoaroof 5y ago
  I sort of think of design patterns as common code patterns that can’t be abstracted over. In Haskell, I think mtl-style type classes probably count. Maybe also the sort thing the lens library does where it says “any function that looks like this and obeys these laws can be used as a lens”. In Java (especially older versions), this set of things includes a lot of things that are trivial if you have lambda expressions.
  - tome 5y ago
    (By the way mtl-style type classes can be abstracted over, for example see my article: http://h2.jaguarpaw.co.uk/posts/mtl-style-for-free/ http://h2.jaguarpaw.co.uk/posts/mtl-style-for-free/)
- jcelerier 5y ago
  > That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. but it's still a pattern ? patterns aren't classes. A specific way of sequencing function calls and operators is still a pattern.

slaymaker1907 5y ago

Functional programming still has patterns, they are just different patterns. For example, (let loop ([arg _]) ...) in Scheme for iteration. Monads are another one. Another common one is a foreach method/function for iteration over data instead of using iterators.

akavi 5y ago
> Monads Are "just" an interface a data type can implement/obey (in languages that support higher kinded interfaces) > a foreach method/function for iteration over data Again, "just" an interface a data type can implement/obey.
- deleted 5y ago
  [deleted]
- jcelerier 5y ago
  Patterns being reified as language objects don't make them not-patterns. Trusty old function calls are still patterns, only reified from asm routines and procedures.
Aeolun 5y ago
Something at the level of a loop does not strike me as something you can call a design pattern.
- lotophage 5y ago
  I agree. I'd be more inclined to call something like that an idiom.
feanaro 5y ago
> Functional programming still has patterns, they are just different patterns. Yes, exactly what I meant by > the design patterns relevant in those domains are not really called "design patterns". I was thinking of things like algebraic or categorical laws, or invariants.

endymi0n 5y ago

I've had the same thought. I've never seen it confirmed by anyone, but to me, a lot of the original design patterns were stopgap conventions to patch shortcomings in the languages of their time (mainly early Java). Just look at the Visitor pattern. It's a convention to expose an "accept" method that can be "visited". That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. Going in depth, you can see the same possibilities everywhere. "Proxy" should probably be a registerable middleware, etc. etc. Then again, I might be biased. Design Patterns already let my BS detector go bonkers 15 years ago when I encountered them first, as as academization and complication of software by self-indulgent "enterprise programmers" that I couldn't ever see any advantages to (and these days, I feel enjoyably vindicated). Funnily enough, in this way they were quite anti-academic, as they came from original research of the "Gang of Four" and I've never seen scientific proof they actually made anything better. I stand to be corrected though.

fiddlerwoaroof 5y ago
I sort of think of design patterns as common code patterns that can’t be abstracted over. In Haskell, I think mtl-style type classes probably count. Maybe also the sort thing the lens library does where it says “any function that looks like this and obeys these laws can be used as a lens”. In Java (especially older versions), this set of things includes a lot of things that are trivial if you have lambda expressions.
- tome 5y ago
  (By the way mtl-style type classes can be abstracted over, for example see my article: http://h2.jaguarpaw.co.uk/posts/mtl-style-for-free/ http://h2.jaguarpaw.co.uk/posts/mtl-style-for-free/)
jcelerier 5y ago
> That's pretty much what you'd do far easier and more naturally with functional programming these days, even in Java. but it's still a pattern ? patterns aren't classes. A specific way of sequencing function calls and operators is still a pattern.