Hacker News Reader

Comment by chowells | Hacker News Reader

That presentation makes a funny assumption that it's dynamic languages that do that. Haskell is nearly as far from dynamic as possible, with all the same advantages w.r.t. patterns.

View on HN

The presentation is about dynamic languages, but the observation about design patterns being crutches for offsetting language deficiencies is in fact a general one.

Haskell needs "zip3" when there are three arguments to zip.

That's a design pattern for optional arguments straight out of ISO C.

I think it would be possible to create a generalised `zipN` function, using the Haskell printf trick[0], but it would be a lot of complication for little benefit. It's rare that you need to merge that many streams at once, and adding a single digit is not a huge hassle in those cases. Also I'd probably consider splitting the operation up into stages if I was using anything higher than `zipWith3`.

[0]http://stackoverflow.com/questions/7828072/how-does-haskell-...

You also have an equivalent on a family of isomorphic types, namely the types

    forall z. (a -> b -> c -> ... -> z) -> ZipList z

This is gotten by taking your `list_a :: [a]` etc. and writing:

    \f -> f <$> ZipList list_a <*> ZipList list_b <*> ZipList list_c <*> ...

You can of course also use Haskell pair-stacks to do all of this, storing (a, b, c, ...) as the type (a, (b, (c, ... ())))...

I've done some examples of transposing Java code explaining various design patterns from the GoF book to Haskell, then seeing how it gets simpler when you have a couple of higher-level ideas from Haskell to work with. It could make a fun talk to present at a Java-centric conference, "today I'm going to teach you some Haskell." As a bonus, you get to see how the Java code deals with a tremendous amount of needless complexity.

For example, here's what I've written so far for the Visitor pattern:

https://gist.github.com/drostie/818c54ca5c8182143699a72da986...

Reply on news.ycombinator.com