There is one question, before you press "down-vote" few times - what is the sequence of machine instructions your monad compiles into?
There is one question, before you press "down-vote" few times - what is the sequence of machine instructions your monad compiles into?
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 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.
I think, looking at sources of arc.arc or news.arc, that it is, how to say, over-hyped.
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.
The article was about pure functions as opposed to stateful functions, clean syntax that gets out of your way, and higher-order compositions over container types. It was about good habits that can be taken to other languages.
> what is the sequence of machine instructions your monad compiles into?
What is the relevance? If you're using Haskell, then machine code should be the last thing on your mind. If you're writing code to produce the most efficient machine code, then you should be writing C. The entire point of higher level languages is that they abstract away the gritty, lower level concerns like 'what register should I place this pointer in?'.