6 ms·

GOF patterns are indeed language agnostic, as long as you work within the OO paradigm. You can indeed apply the same pattern (fe visitor) in Python, Java, C++,

GOF patterns are indeed language agnostic, as long as you work within the OO paradigm. You can indeed apply the same pattern (fe visitor) in Python, Java, C++, Go. This is also the reason why it isn't that difficult to move from one OO language to another. Functional programming languages fall within another paradigm. You do have patterns like 'fold', 'map', or 'nexus' but in general, they tend to be very small. This is because functions allow both more strict and more flexible composition than objects. Again, once you know Lisp, or Scheme or ML you can jump from one language to another, although from Scheme to Haskell will be a larger jump (purity & laziness) than from Scheme to Erlang. Two final remarks: ) The declarative paradigm (Prolog, Mercury, ...) seems to be out of flavour these days. ) Every self respecting developer should have mastered at least 1 language in every paradigm.

fuzzix 14y ago
"GOF patterns are indeed language agnostic" I enjoyed this series of articles published some years ago making the case that many of the useful design patterns are built into Perl already: http://www.perl.com/pub/2003/06/13/design1.html http://www.perl.com/pub/2003/06/13/design1.html http://www.perl.com/pub/2003/08/07/design2.html http://www.perl.com/pub/2003/08/07/design2.html http://www.perl.com/pub/2003/08/15/design3.html http://www.perl.com/pub/2003/08/15/design3.html The take-away point being "If a pattern is really valuable, then it should be part of the core language". Perl, of course, has very strong functional features, as described in Higher Order Perl: http://hop.perl.plover.com/ http://hop.perl.plover.com/
- kamaal 14y ago
  >>"If a pattern is really valuable, then it should be part of the core language" I think this is what has caused so many misunderstandings people have about Perl over time. Perl has so many of such patterns built which solve many problems with default. In fact most people fall in love with Perl for these reasons. To understand why that is important you need to recognize such patterns in your problems, if you don't see any you will feel the solutions contained in a language as rubbish. The entire Unix command line toolset is entirely about this thing. Unless you learn how to reduce a problem to a text processing problem, you will never learn to appreciate it.
- Evbn 14y ago
  Not part of the core language. Expressible as a library in the language. See Steele's "Growing a Language" talk.
jewbacca 14y ago
> You do have patterns like 'fold', 'map', or 'nexus' 'nexus'? The only relevant hit on the first page of the google results for those 3 words together is actually a link back to your post https://www.google.com/search?q=map+fold+nexus https://www.google.com/search?q=map+fold+nexus
- Deestan 14y ago
  And now the first result links back to your comment here. :)
- toolslive 14y ago
  I admit this was bait ;) It comes from "Pearls of Functional Algorithm Design" (R.Bird) It's basically a tree with shared nodes.
  - Evbn 14y ago
    What is the difference between that and DAG?
  - jewbacca 14y ago
    Ah! Cool. Found a PDF here: ftp://kawais.org.ua/incoming/Bird%20-%20Pearls%20of%20Functional%20Algorithm%20Design%20(Computer%20Science)%20-%202010.pdf This is actually a pattern that I've been looking for a name for, for years! And you've actually sold the OP's featured answer for me by making me use that word ("pattern"), notice the concept's genuine applicability to this context, and realize it's not a Java-spawned vulgarity.
martincmartin 14y ago
The visitor pattern is a way around a lack of multiple dispatch: choosing a method based on the run-time type of all arguments. Common Lisp, for example, has no need of the visitor pattern since it has multiple dispatch. The O.P. is about when the design patterns are needed, not what you need to implement them. Incidentally, the visitor pattern doesn't require OO for implementation, it requires a type system and single dispatch, i.e. choosing a method based on the run-time type of its first argument. Python doesn't have single dispatch. So the visitor pattern doesn't really work in Python, you essentially have to code a huge number of branches, e.g. n switch statements, each with n cases, in order to dispatch n^2 ways.
- omaranto 14y ago
  Wait, what? Python doesn't have single dispatch? How does it pick which block of code to run when you say a.f(x)? That dispatches on the class of a doesn't it?
  - skittles 14y ago
    You're correct. Python objects have methods that explicitly take "self" as the first argument. In Java and C#, self or "this" is implied. They all are single-dispatch languages unless an add-on library is used.
  - martincmartin 14y ago
    Yeah you're right. My bad, I was thinking of f(x, y). a.f(x) is single dispatch - just like C++ and Java.
omaranto 14y ago
About logic programming: I think the current feeling is that its great for certain kinds of subproblems cropping up in a program but not so hot for structuring the whole thing, and that therefore Prolog or something like it is better as a library than a language. There are nice logic programming libraries for any Lisp (core.logic in Clojure is particularly nice, I'd say), for Haskell (some having only the search part of Prolog, without logical variables, others having both).
webreac 14y ago
GoF DP have failed to deliver their premises. They are not language agnostic. They are useful for education and to help communication when speaking about code. They have never helped me to develop code. Sometimes, my code contains a DP or another one, but it is never the most stable parts of my architectures.
- Evbn 14y ago
  Did you read the book? The original patterns were highly relevant at the time. The immortality of DP is the the notion that we should identify and name and share patterns as we invent new ones for changing times. Did K&R fail to deliver because not everyone writes C for everything today?
  - webreac 14y ago
    Yes, I bought it and learned it. At that time (1999) I was preparing an interview where questions about this kind of knowledge were expected. I was already an experienced developer, the presentation of the DP was new for me and the promises were exciting. But in fact, I had already encountered most of the patterns in projects that were not great examples of good coding (IMHO). Outside this interview (I succeeded), knowing DP has never helped me to be a better developer. The patterns in the GoF are often encountered in libraries written in object oriented languages that do not use much templates or parallelism. There were many in Java library. I think I have not found any of them in the C++ standard library. Now, I see singleton used everywhere because people are too lazy to design correctly program startup. When tasking is involved, incorrect use of singleton causes very nasty bugs (a crash every month). For me, singleton is a dangerous pattern (almost as bad as global variables, sometime worse), the others patterns just happen to be the best way to do some common things. Identifying them is never a problem, having a name for them is useful. The main proof of GoF failure is that we have never seen all the new books with new DPs. I still wait for a new list of common and language agnostic design patterns. Until that, DP remain for me a good example of failure. C has exceeded all its expectations, what is the point of your comparison ?

fuzzix 14y ago

"GOF patterns are indeed language agnostic" I enjoyed this series of articles published some years ago making the case that many of the useful design patterns are built into Perl already: http://www.perl.com/pub/2003/06/13/design1.html http://www.perl.com/pub/2003/06/13/design1.html http://www.perl.com/pub/2003/08/07/design2.html http://www.perl.com/pub/2003/08/07/design2.html http://www.perl.com/pub/2003/08/15/design3.html http://www.perl.com/pub/2003/08/15/design3.html The take-away point being "If a pattern is really valuable, then it should be part of the core language". Perl, of course, has very strong functional features, as described in Higher Order Perl: http://hop.perl.plover.com/ http://hop.perl.plover.com/

kamaal 14y ago
>>"If a pattern is really valuable, then it should be part of the core language" I think this is what has caused so many misunderstandings people have about Perl over time. Perl has so many of such patterns built which solve many problems with default. In fact most people fall in love with Perl for these reasons. To understand why that is important you need to recognize such patterns in your problems, if you don't see any you will feel the solutions contained in a language as rubbish. The entire Unix command line toolset is entirely about this thing. Unless you learn how to reduce a problem to a text processing problem, you will never learn to appreciate it.
Evbn 14y ago
Not part of the core language. Expressible as a library in the language. See Steele's "Growing a Language" talk.

jewbacca 14y ago

> You do have patterns like 'fold', 'map', or 'nexus' 'nexus'? The only relevant hit on the first page of the google results for those 3 words together is actually a link back to your post https://www.google.com/search?q=map+fold+nexus https://www.google.com/search?q=map+fold+nexus

Deestan 14y ago
And now the first result links back to your comment here. :)
toolslive 14y ago
I admit this was bait ;) It comes from "Pearls of Functional Algorithm Design" (R.Bird) It's basically a tree with shared nodes.
- Evbn 14y ago
  What is the difference between that and DAG?
- jewbacca 14y ago
  Ah! Cool. Found a PDF here: ftp://kawais.org.ua/incoming/Bird%20-%20Pearls%20of%20Functional%20Algorithm%20Design%20(Computer%20Science)%20-%202010.pdf This is actually a pattern that I've been looking for a name for, for years! And you've actually sold the OP's featured answer for me by making me use that word ("pattern"), notice the concept's genuine applicability to this context, and realize it's not a Java-spawned vulgarity.

martincmartin 14y ago

The visitor pattern is a way around a lack of multiple dispatch: choosing a method based on the run-time type of all arguments. Common Lisp, for example, has no need of the visitor pattern since it has multiple dispatch. The O.P. is about when the design patterns are needed, not what you need to implement them. Incidentally, the visitor pattern doesn't require OO for implementation, it requires a type system and single dispatch, i.e. choosing a method based on the run-time type of its first argument. Python doesn't have single dispatch. So the visitor pattern doesn't really work in Python, you essentially have to code a huge number of branches, e.g. n switch statements, each with n cases, in order to dispatch n^2 ways.

omaranto 14y ago
Wait, what? Python doesn't have single dispatch? How does it pick which block of code to run when you say a.f(x)? That dispatches on the class of a doesn't it?
- skittles 14y ago
  You're correct. Python objects have methods that explicitly take "self" as the first argument. In Java and C#, self or "this" is implied. They all are single-dispatch languages unless an add-on library is used.
- martincmartin 14y ago
  Yeah you're right. My bad, I was thinking of f(x, y). a.f(x) is single dispatch - just like C++ and Java.

omaranto 14y ago

About logic programming: I think the current feeling is that its great for certain kinds of subproblems cropping up in a program but not so hot for structuring the whole thing, and that therefore Prolog or something like it is better as a library than a language. There are nice logic programming libraries for any Lisp (core.logic in Clojure is particularly nice, I'd say), for Haskell (some having only the search part of Prolog, without logical variables, others having both).

webreac 14y ago

GoF DP have failed to deliver their premises. They are not language agnostic. They are useful for education and to help communication when speaking about code. They have never helped me to develop code. Sometimes, my code contains a DP or another one, but it is never the most stable parts of my architectures.

Evbn 14y ago
Did you read the book? The original patterns were highly relevant at the time. The immortality of DP is the the notion that we should identify and name and share patterns as we invent new ones for changing times. Did K&R fail to deliver because not everyone writes C for everything today?
- webreac 14y ago
  Yes, I bought it and learned it. At that time (1999) I was preparing an interview where questions about this kind of knowledge were expected. I was already an experienced developer, the presentation of the DP was new for me and the promises were exciting. But in fact, I had already encountered most of the patterns in projects that were not great examples of good coding (IMHO). Outside this interview (I succeeded), knowing DP has never helped me to be a better developer. The patterns in the GoF are often encountered in libraries written in object oriented languages that do not use much templates or parallelism. There were many in Java library. I think I have not found any of them in the C++ standard library. Now, I see singleton used everywhere because people are too lazy to design correctly program startup. When tasking is involved, incorrect use of singleton causes very nasty bugs (a crash every month). For me, singleton is a dangerous pattern (almost as bad as global variables, sometime worse), the others patterns just happen to be the best way to do some common things. Identifying them is never a problem, having a name for them is useful. The main proof of GoF failure is that we have never seen all the new books with new DPs. I still wait for a new list of common and language agnostic design patterns. Until that, DP remain for me a good example of failure. C has exceeded all its expectations, what is the point of your comparison ?