Hacker News Reader

Comment by toolslive | Hacker News Reader

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.

View on HN

"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/08/07/design2.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/

>>"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.

Not part of the core language. Expressible as a library in the language.

See Steele's "Growing a Language" talk.

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.

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?

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.

Yeah you're right. My bad, I was thinking of f(x, y). a.f(x) is single dispatch - just like C++ and Java.

> 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

And now the first result links back to your comment here. :)

I admit this was bait ;)

It comes from "Pearls of Functional Algorithm Design" (R.Bird) It's basically a tree with shared nodes.

What is the difference between that and DAG?

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.

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).

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.

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?

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 ?

Reply on news.ycombinator.com