4 ms·

Luciano Ramalho in his book "Fluent Python" mentioned that some (most?) of the GoF patterns are unneeded in a dynamic language like Python. I see [0] he is fav

by hcrisp 5y ago

Luciano Ramalho in his book "Fluent Python" mentioned that some (most?) of the GoF patterns are unneeded in a dynamic language like Python. I see [0] he is favorable to this site's author, so it is probably worth a look. [0] https://twitter.com/ramalhoorg/status/960746929025142784?s=20&t=5bJW1H_sB25B7KZvwNEX0g https://twitter.com/ramalhoorg/status/960746929025142784?s=2...

stingraycharles 5y ago
Interesting, thanks for sharing. Is the opposite also true, that when a language is statically typed, design patterns are likely to be needed?
- javcasas 5y ago
  It depends on the language expresiveness, not on it being static/dynamic types. Dynamic languages tend to have less limitations to expresiveness (no typechecker in the middle) and then you have programming languages with static types and decent typecheckers that don't require design patterns because they are still very expressive.
polynomial 5y ago
How did you happen to see that? That tweet is perfectly relevant, it's byond uncanny that you had it at the ready.
- hcrisp 5y ago
  Coincidence. I was trying to find the reference to Ramalho's comment about GoF and found his comment in a random search.
hcrisp 5y ago
I found the quote. He says Peter Norvig wrote that "16 out of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern" and that Python shares some of the dynamic features of these languages such as first-class functions. I wonder if making GoF patterns simpler or even "invisible" in C++ using functions or callable-objects is implicitly not allowed because of the static typing of the language or if it just wasn't considered by the authors.
javcasas 5y ago
Most of the design patterns exist because of limitations in programming languages, especially java/c++/c#. The strategy pattern disappears when you can store functions in data structures. The abstract factory pattern disappears when you can pass functions as parameters. The builder pattern disappears when your progamming language has named parameters. The observer pattern is callbacks with additional steps. The mediator pattern disappears with support on variants of functional reactive programming. The iterator pattern disappears by using your favourite version of generators (or just go hardcore like Haskell and do foldable/traversable). IMO GoF has been obsolete for the last 20 years (50 years if you consider that languages like ML, Lisp and friends already existed then).
- valenterry 5y ago
  Storing functions in datastructures with the purpose of applying a different logic depending on context/configuration but with the same goal _is_ the strategy pattern. It doesn't matter if you call it like that or not.
  - javcasas 5y ago
    Do we have a special name for storing numbers in data structures? Do we have special names for storing strings in data structures? Do we have special names for storing lists in data structures? Do we have special names for storing source code as strings in data structures? Do we have special names for storing abstract syntax trees as data structures? Do we have special names for storing compiled code as data structures? Do we have special names for storing pairs of compiled code and related memory in data structures? Why do we need special names for storing functions in data structures? When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. But, somehow, if it's a function list then it's a strategy pattern. Free your mind of unnecessary labels.
    - valenterry 5y ago
      > Do we have a special name for storing numbers in data structures? Yes, we do. For instance, if I store numbers that describe a limit, I'll call it a limit. And it will give a hint how it is used. Do I call all numbers in a data structure limit? Of course not - the same is true for functions in datastructures. > Why do we need special names for storing functions in data structures? Well, it is helpful. There are many reasons to store functions in datastructures. For example to do mappings, to cache/memoize them or even to create interpretable datastructures, using free monads. But the strategy pattern describes the situation where there are multiple functions and they all serve the same purpose and have the same interface (and thus are interchangeble) and usually one is chosen and applied - but it is expected to be different ones, depending on the context. Do we really need a name for that or use it in code? I don't know. But that's not the my point - which is that the concept doesn't go away just because it is easier to use it. > When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. Sure, if you don't change the way you filter then it's not a strategy pattern. > But, somehow, if it's a function list then it's a strategy pattern. Now you have lost me. Maybe we disagree because we are talking about a different thing?. A list of functions does not make a strategy pattern. And very often, strategies are implemented using inheritance (or composition) without any lists being involved. At least that's how I remeber the pattern when I saw it (in the pure functional programming world we indeed rarely call it like that) and how it's written in the GoF book.

by hcrisp 5y ago

stingraycharles 5y ago

Interesting, thanks for sharing. Is the opposite also true, that when a language is statically typed, design patterns are likely to be needed?

javcasas 5y ago
It depends on the language expresiveness, not on it being static/dynamic types. Dynamic languages tend to have less limitations to expresiveness (no typechecker in the middle) and then you have programming languages with static types and decent typecheckers that don't require design patterns because they are still very expressive.

polynomial 5y ago

How did you happen to see that? That tweet is perfectly relevant, it's byond uncanny that you had it at the ready.

hcrisp 5y ago
Coincidence. I was trying to find the reference to Ramalho's comment about GoF and found his comment in a random search.

hcrisp 5y ago

I found the quote. He says Peter Norvig wrote that "16 out of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern" and that Python shares some of the dynamic features of these languages such as first-class functions. I wonder if making GoF patterns simpler or even "invisible" in C++ using functions or callable-objects is implicitly not allowed because of the static typing of the language or if it just wasn't considered by the authors.

javcasas 5y ago

Most of the design patterns exist because of limitations in programming languages, especially java/c++/c#. The strategy pattern disappears when you can store functions in data structures. The abstract factory pattern disappears when you can pass functions as parameters. The builder pattern disappears when your progamming language has named parameters. The observer pattern is callbacks with additional steps. The mediator pattern disappears with support on variants of functional reactive programming. The iterator pattern disappears by using your favourite version of generators (or just go hardcore like Haskell and do foldable/traversable). IMO GoF has been obsolete for the last 20 years (50 years if you consider that languages like ML, Lisp and friends already existed then).

valenterry 5y ago
Storing functions in datastructures with the purpose of applying a different logic depending on context/configuration but with the same goal _is_ the strategy pattern. It doesn't matter if you call it like that or not.
- javcasas 5y ago
  Do we have a special name for storing numbers in data structures? Do we have special names for storing strings in data structures? Do we have special names for storing lists in data structures? Do we have special names for storing source code as strings in data structures? Do we have special names for storing abstract syntax trees as data structures? Do we have special names for storing compiled code as data structures? Do we have special names for storing pairs of compiled code and related memory in data structures? Why do we need special names for storing functions in data structures? When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. But, somehow, if it's a function list then it's a strategy pattern. Free your mind of unnecessary labels.
  - valenterry 5y ago
    > Do we have a special name for storing numbers in data structures? Yes, we do. For instance, if I store numbers that describe a limit, I'll call it a limit. And it will give a hint how it is used. Do I call all numbers in a data structure limit? Of course not - the same is true for functions in datastructures. > Why do we need special names for storing functions in data structures? Well, it is helpful. There are many reasons to store functions in datastructures. For example to do mappings, to cache/memoize them or even to create interpretable datastructures, using free monads. But the strategy pattern describes the situation where there are multiple functions and they all serve the same purpose and have the same interface (and thus are interchangeble) and usually one is chosen and applied - but it is expected to be different ones, depending on the context. Do we really need a name for that or use it in code? I don't know. But that's not the my point - which is that the concept doesn't go away just because it is easier to use it. > When I filter the list of numbers it's not a strategy pattern. Neither is when I filter the string list, or the AST list, or the compiled code+closure list. Sure, if you don't change the way you filter then it's not a strategy pattern. > But, somehow, if it's a function list then it's a strategy pattern. Now you have lost me. Maybe we disagree because we are talking about a different thing?. A list of functions does not make a strategy pattern. And very often, strategies are implemented using inheritance (or composition) without any lists being involved. At least that's how I remeber the pattern when I saw it (in the pure functional programming world we indeed rarely call it like that) and how it's written in the GoF book.