Unlike some other features* , pattern matching isn't all that scary, though. "Oh, it's like a switch statement... but it can break things up and check inside... that's pretty cool." You can understand it in terms of other fairly commonplace constructs, and it's relatively clear how useful it is.

It could be presented a bit differently, but the underlying idea seems approachable.

* I'm thinking of monads, in particular; whether they actually are or whether it's just due to the way they've been presented is another question.

Monads aren't that hard. A monad is just like a burrito!

Pattern matching is awesome. It makes code immensely more readable.

I started to understand monads when I compared the Maybe monad to the short-circuiting behavior of the Unix pipe. That doesn't mean my insight will work for anybody else, though.

Also, having masses of Haskell blog posts saying, "No, monads are actually not that hard, here's (an explanation that probably won't actually make all that much sense)." probably doesn't help to dispel the myth that Haskell is hard / impractical / whatever.

In understanding monads, I think Maybe and List are the best places to start, because they're familiar data structures. IO is conceptually familiar, but IO as an immutable value representing a series of actions is not.

Agreed, strongly. Trying to understand monads in terms of IO makes things vastly more difficult than necessary.

Well, just as "monads are like burritos", IO is like a delicious but sketchy fish taco. Eating is input. We shan't discuss the output process; we all know how it works and what it looks like. Food poisoning or poor health can lead to usage of standard error. In practice, stdout and stderr are usually redirected to the same buffer, which is flushed shortly after a write.

brilliant.

A case expression is more common:

  sum ys = sum' ys 0
    where sum' list total =
      case list of
        []   -> total
        x:xs -> sum' xs (total + x)

this haskell example is exposing you to two cool things:

- algebraic types. haskell has type inference, so it can do the right thing while you only describe the function as operating on lists. now look at java...strong typing but no intelligent inference, which is why you are forced to write retarded java like HashSet<Integer> s = new HashSet<Integer>()

- pattern matching. you can describe functionality based on the pattern of the data

this isn't just syntax. these are really powerful fundamental features of the language

Yes, I totally agree. But the question I was responding to was just, "What parts of Haskell have weird syntax?" All of this cool stuff would also be possible with c-like syntax.

Retarded? Really?

I guess that you don't know that generics in Java were derived from Haskell type classes and designed by the same man who added monads to Haskell.

Retarded, indeed. Almost half of that code is a redundant repetition of type information.

It's not redundant information and in Haskell you write exactly the same thing.

  doSomething :: HashSet Int -> HashSet Int

And that man would absolutely love it if Java had a type system closer to Hindley-Milner with type inference. But, given the reality of Java, generics become undesirably verbose.

A typical well written Haskell program has more type annotation than the same program written in Java. Not only that but because of type classes those annotations are even more verbose than an equivalent declaration in Java.

It's true that you can omit most of the type signatures and let the compiler figure it out but nobody really writes Haskell code that way if they want it to be comprehensible by human readers.

I've wondered about this. It seems common for OCaml code to only have the type annotations where necessary, but it's usually included in Haskell by convention.

He had to work in the constraints of the language..

sum ys = foldl' (+) 0 ys

Combinators for the win!