Comment by tmhedberg | Hacker News Reader

Comment by tmhedberg | Hacker News Reader

Parent Full thread

Who is arguing that the monad as a means of composition is superior to all others? Or that Haskell doesn't emphasize the power of composition of high-order functions? Function composition is one of the most important tools in a Haskell programmer's toolbox. Monads are just another one of those.

The thing is, most popular languages these days support higher-order functions. It's nothing to write home about. Monads get a lot of attention specifically because they are a fairly unique idea that is not supported out-of-the-box in other languages. People who are advocating (or evangelizing, if that's your perspective) for a particular thing are going to focus primarily on the specific aspects of that thing that make it stand out from the crowd. For Haskell, that means things like monads, algebraic data types, non-strict evaluation, functional purity, etc.

There is one question, before you press "down-vote" few times - what is the sequence of machine instructions your monad compiles into?

I can't understand what you're getting at here. What difference does it make what code the compiler emits, unless I am trying to aggressively optimize low-level performance? If it does what I intend it to do, and is reasonably fast at doing it, I don't care about the specific instructions. How is that relevant?

The question was why should one have to learn some sophisticated, over-engineered type system along with unreadable notation, when the result will be plain, sequential machine code anyway? What is the point besides "I'm so clever"?

I'm not clever enough to write that "plain, sequential machine code" in a sufficiently correct fashion.

Your claim that it is over-engineered is unsubstantiated, and from a Haskell user's point of view, plainly false.

The claim that the notation is unreadable is similar.

Haskell's notation is certainly unfamiliar, and that can be frustrating (as all unfamiliar notations are), but it is one of the best designed ones out there.

As for the question: Why learn the type system? Because it helps you encode your program's invariants as types -- allowing them to be verified cheaply and repeatedly by an automated prover (the type checker), rather than being documented and checked by expensive tests.

They are also documentation you can rely on, as it is guaranteed to stay in sync with the program. It means you can get up to speed with other's code much quicker.

They also restrict code in useful ways, encouraging code that is more concurrency-friendly, simpler, and generally better.

OK, those are arguments in favor of strong-typing, early-binding and compile-time checks. Java arguments, in other words.

I think, looking at sources of arc.arc or news.arc, that it is, how to say, over-hyped.

Strong typing is not nearly as good when the type system is weaker.

Java's "strong typing" doesn't protect you from null dereference errors, as one example out of many.

Also, strong typing is not as good when you have to specify a lot of the types repeatedly. Without good type inference, it loses a lot of the appeal.

Strong typing is not nearly as good when every function has arbitrary effects not specified by its type.

Strong typing is not as good when it is harder to do parametericity, as discouraging it means you get monomorphic types, which are far less effective at preventing errors.

Haskell gives a whole lot more benefits via static types than Java does.

Reply on news.ycombinator.com