3 ms·

Sure. Instead of learning the power of composition of high-order functions, you will learn that particular composition, with a trendy name, and will start to ar

Sure. Instead of learning the power of composition of high-order functions, you will learn that particular composition, with a trendy name, and will start to argue on forums, that this particular function composition is somehow superior to all other compositions and you must do everything using that particular composition, which is called monad..) There is one question, before you press "down-vote" few times - what is the sequence of machine instructions your monad compiles into?

tmhedberg 14y ago
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?
- dschiptsov 14y ago
  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"?
  - mbetter 14y ago
    I'm not clever enough to write that "plain, sequential machine code" in a sufficiently correct fashion.
  - Peaker 14y ago
    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.
    - dschiptsov 14y ago
      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.
      - Peaker 14y ago
        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.
trobertson 14y ago
Why are you building up a straw man? The author didn't even talk about monads. The content had nothing to do with monads. 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?'.

tmhedberg 14y ago

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?

dschiptsov 14y ago
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"?
- mbetter 14y ago
  I'm not clever enough to write that "plain, sequential machine code" in a sufficiently correct fashion.
- Peaker 14y ago
  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.
  - dschiptsov 14y ago
    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.
    - Peaker 14y ago
      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.

trobertson 14y ago

Why are you building up a straw man? The author didn't even talk about monads. The content had nothing to do with monads. 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?'.