5 ms·

I think recursion is just one of the hurdles. Another one is the use of higher-level functions and function composition. Another one is the use of monads (at

by sltkr 5y ago

I think recursion is just one of the hurdles. Another one is the use of higher-level functions and function composition. Another one is the use of monads (at least in pure functional languages like Haskell).

nightski 5y ago
Monads aren't really related to purity. Haskell uses one instance of a monad, the IO monad to encapsulate IO. But there are other ways of doing it. Most monads have nothing to do with side effects. You see things like functors/monads all the time even in regular imperative languages. For example in .NET we have Linq, Nullable types, etc... They aren't as well defined as in Haskell but still an incredibly useful pattern. You also have higher ordered functions and whatnot in imperative languages now. In fact, in JavaScript and .NET they are used all over the place.
- DaiPlusPlus 5y ago
  I don’t believe .NET’s `System.Nullable<T>` is a monad. For example, a type that can encapsulate any other type fulfils the definition of a monadic-value, but `Nullable<T>` cannot be used with reference-types and delegates, only a strict subset of value-types (as `Nullable<T>` itself is a value-type, but you cannot use `Nullable<T2>` for T1 in `Nullable<T1>`). While .NET allows for composition with delegates, it’s not very smart, and results in unnecessary type information erasure; for example in Linq if you take a projection of a fixed-size list, then that length information is lost if you then add another step after the projection. (Linq internally has some ugly, but inconsistent implementation hacks; for example, IList<T> length information may be preserved but IReadOnlyCollection<T> length information will not.
  - nightski 5y ago
    C# has nullable reference types now. But I agree it's not perfectly a monad in implementation due to engineering decisions. But the pattern generally follows that of the Option monad in Haskell, even if it falls short. If you know the Option monad you'll find it really easy to pick up .NET's nullable types. That's my point, you find these patterns all over in common programming languages and even though they are hard to learn it's worth it.
    - recursive 5y ago
      It's going the other way that's the problem. I understand .net nullable, including some of the weird edge cases and trivia. None of that seems to provide any illumination into the working of more general monads.
      - nightski 5y ago
        Weird, when I was learning Haskell I felt like the Option type looked very familiar. Then when I learned about fmap and bind it was immediately obvious why these would be useful. You mean I can apply a function to a nullable type that has no knolwedge of nullable? Cool! Or I can compose general operations on nullables? That is neat. In fact I think this was the easiest way for me to learn monads - to learn them in the context of things I already understood.
      - DaiPlusPlus 5y ago
        That's because Nullable<T> and nullable-reference-types aren't monads - precisely because they aren't composable. I think this SO post covers it well: https://stackoverflow.com/questions/44965/what-is-a-monad https://stackoverflow.com/questions/44965/what-is-a-monad
- sltkr 5y ago
  All essential applications of monads in Haskell are there to work around the limitations of purity. The I/O monad, ST monad, State monad, etc. Yes, I know List and Maybe are also technically monads in Haskell. But you don't need to think of them as monads or even understand monads to do anything useful with them. Applying monad operators to lists and maybes is only occasionally useful. In most impure functional languages (LISP, ML) you rarely model any data types as monads explicitly. As soon as you have side-effects, they lose their appeal.
  - nightski 5y ago
    This is just not true, you throw out some of the most useful monads :) Also ST and State have no side effects. The only monad in Haskell that has side effects is IO (unless you were to sneak in an unsafePerformIO but that is an entirely different discussion). So they aren't there to work around the limitations of purity, because they are pure.
    - sltkr 5y ago
      > This is just not true, you throw out some of the most useful monads :) Namely? > Also ST and State have no side effects. I didn't say they do. I said they are useful only because Haskell doesn't allow side-effects. In ML or Lisp you'd just update a local variable instead.
      - nightski 5y ago
        Lists, Option, Either, Reader, Logging (non-effectful), STM etc... There is even a probability monad that I have found quite useful. ST & State are far more useful than updating a local variable. If you are going to choose the simplest use case for them ever and then say that is the only thing they can do it is not a productive discussion. The state monad is a lot like a context object that allows state to flow through function composition (for functions that have no knowledge of such state). For example you could compose a bunch of functions and have the results of each function call stored without changing any of the functions to know about the operation. It's a method of abstraction and encapsulation. It's not just monads that are useful either, it is the full hierarchy of Monoids, functors, applicatives, monads, etc...

by sltkr 5y ago

nightski 5y ago

Monads aren't really related to purity. Haskell uses one instance of a monad, the IO monad to encapsulate IO. But there are other ways of doing it. Most monads have nothing to do with side effects. You see things like functors/monads all the time even in regular imperative languages. For example in .NET we have Linq, Nullable types, etc... They aren't as well defined as in Haskell but still an incredibly useful pattern. You also have higher ordered functions and whatnot in imperative languages now. In fact, in JavaScript and .NET they are used all over the place.

DaiPlusPlus 5y ago
I don’t believe .NET’s `System.Nullable<T>` is a monad. For example, a type that can encapsulate any other type fulfils the definition of a monadic-value, but `Nullable<T>` cannot be used with reference-types and delegates, only a strict subset of value-types (as `Nullable<T>` itself is a value-type, but you cannot use `Nullable<T2>` for T1 in `Nullable<T1>`). While .NET allows for composition with delegates, it’s not very smart, and results in unnecessary type information erasure; for example in Linq if you take a projection of a fixed-size list, then that length information is lost if you then add another step after the projection. (Linq internally has some ugly, but inconsistent implementation hacks; for example, IList<T> length information may be preserved but IReadOnlyCollection<T> length information will not.
- nightski 5y ago
  C# has nullable reference types now. But I agree it's not perfectly a monad in implementation due to engineering decisions. But the pattern generally follows that of the Option monad in Haskell, even if it falls short. If you know the Option monad you'll find it really easy to pick up .NET's nullable types. That's my point, you find these patterns all over in common programming languages and even though they are hard to learn it's worth it.
  - recursive 5y ago
    It's going the other way that's the problem. I understand .net nullable, including some of the weird edge cases and trivia. None of that seems to provide any illumination into the working of more general monads.
    - nightski 5y ago
      Weird, when I was learning Haskell I felt like the Option type looked very familiar. Then when I learned about fmap and bind it was immediately obvious why these would be useful. You mean I can apply a function to a nullable type that has no knolwedge of nullable? Cool! Or I can compose general operations on nullables? That is neat. In fact I think this was the easiest way for me to learn monads - to learn them in the context of things I already understood.
    - DaiPlusPlus 5y ago
      That's because Nullable<T> and nullable-reference-types aren't monads - precisely because they aren't composable. I think this SO post covers it well: https://stackoverflow.com/questions/44965/what-is-a-monad https://stackoverflow.com/questions/44965/what-is-a-monad
sltkr 5y ago
All essential applications of monads in Haskell are there to work around the limitations of purity. The I/O monad, ST monad, State monad, etc. Yes, I know List and Maybe are also technically monads in Haskell. But you don't need to think of them as monads or even understand monads to do anything useful with them. Applying monad operators to lists and maybes is only occasionally useful. In most impure functional languages (LISP, ML) you rarely model any data types as monads explicitly. As soon as you have side-effects, they lose their appeal.
- nightski 5y ago
  This is just not true, you throw out some of the most useful monads :) Also ST and State have no side effects. The only monad in Haskell that has side effects is IO (unless you were to sneak in an unsafePerformIO but that is an entirely different discussion). So they aren't there to work around the limitations of purity, because they are pure.
  - sltkr 5y ago
    > This is just not true, you throw out some of the most useful monads :) Namely? > Also ST and State have no side effects. I didn't say they do. I said they are useful only because Haskell doesn't allow side-effects. In ML or Lisp you'd just update a local variable instead.
    - nightski 5y ago
      Lists, Option, Either, Reader, Logging (non-effectful), STM etc... There is even a probability monad that I have found quite useful. ST & State are far more useful than updating a local variable. If you are going to choose the simplest use case for them ever and then say that is the only thing they can do it is not a productive discussion. The state monad is a lot like a context object that allows state to flow through function composition (for functions that have no knowledge of such state). For example you could compose a bunch of functions and have the results of each function call stored without changing any of the functions to know about the operation. It's a method of abstraction and encapsulation. It's not just monads that are useful either, it is the full hierarchy of Monoids, functors, applicatives, monads, etc...