5 ms·

Really enjoyed this book. Once you get currying, and using curried functions to pipe/compose, everything clicks into place. I found the examples of using Nothin

Really enjoyed this book. Once you get currying, and using curried functions to pipe/compose, everything clicks into place. I found the examples of using Nothing/Maybe monads for error handling pretty neat as well - is that a common pattern, because I don't remember native support for those types when I briefly dabbled in elixir. Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?

yen223 8y ago
Haskell-style types aren't a prerequisite for functional programming. Lisp and Elixir are dynamically-typed, which is why you don't see monads in those. That said, they do occasionally form useful abstractions.
- AnimalMuppet 8y ago
  Can you explain why you don't need monads if your language is dynamically typed? That's a new one to me.
  - marcosdumay 8y ago
    I don't agree with that "not needed" explanation. But they are quite useless if the compiler can not deduce that both the values returned from the functions you are calling are monads, and what kind of binding should apply to them.
    - dvlsg 8y ago
      I find them to be at least somewhat useful in a language like javascript. I imagine they are more useful in a typed language with proper inference, but I wouldn't say they're entirely useless in a dynamic language.
    - AnimalMuppet 8y ago
      OK, for the slow of understanding: What I think you said is that, in an untyped language, a function will just return "something" (as far as the compiler is concerned). But in a typed language, the compiler knows that a monad was returned. So the point of the monad is to make the compiler do magic, not to make the runtime do magic. Is that accurate?
      - chowells 8y ago
        Well.. It's like 25% accurate, and you hit the part you were most worried about. But you have been seriously misled about monads in the past. There is no magic in monads. At the level of runtime operations, they're just a couple of functions. The magic taking place in the compiler is type inference guiding the selection of the right pair of functions during compilation. Without that, you have to explicitly use the correct functions. It's much easier to offload that bookkeeping to a computer than it is to do it yourself.
- dragonwriter 8y ago
  > Haskell-style types aren't a prerequisite for functional programming. Sure. > Lisp and Elixir are dynamically-typed, which is why you don't see monads in those. More to the point, Lisp and Elixir are impure functional languages, which is why you don't have some pure construct, like monads, that isolates IO.
  - dllthomas 8y ago
    > you don't have some pure construct, like monads, that isolates IO In Haskell IO is isolated, and then the Monad interface is used for some particularly important ways of interacting with values of that type. That's not quite the same thing as "monads isolate IO" - the Monad interface is useful for quite a few other types of values.
green_on_black 8y ago
imo, that's basically what they are. altho the fact that they can be created via unit is actually really useful too (even tho thats technically part of applicative).
brianberns 8y ago
The Option/Maybe monad is very common in FP languages. I don't know if it's native in Elixir, but apparently it's pretty easy to implement: http://www.zohaib.me/monads-in-elixir-2/#maybe http://www.zohaib.me/monads-in-elixir-2/#maybe There are lots of ways to conceptualize monads. I think "functors that flatten" is accurate, but is just one way.
tuukkah 8y ago
Functors have fmap. Pointeds have pure. Monads have fmap, pure and join/flatten. So what's missing from "functors that can flatten" is pure, and monads are more precisely "pointed functors that can flatten". This is the canonical source: https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia
jerf 8y ago
There's really multiple definitions of "functional" right now, and the type of "functional" being discussed here, Erlang isn't, and I don't think Elixir particularly is either. This is not a criticism of any kind; this is a point about definitions. There are definitions of functional where Erlang is functional, and IIRC Elixir can be said to support it. (And there are definitions of "functional" where almost every language in current use is "functional". There's even some so weak that C is "functional" because it has "function pointers", though this one is now out-of-date and not currently being used by anyone. But, yes, there was once a time in which C would have been considered "unusually strong" in its "functional programming" support, because other contemporary languages didn't even have function pointers.) "Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?" A little of both. Technically it is correct, but the "flattening" in question applies to many things that most programmers wouldn't consider "flattening". For instance, consider monadic IO as Haskell uses. There is a way in which you can consider the execution of an IO value as "flattening" it, and it corresponds to the mathematical term, but it's not what most people have in mind. There's more to "flattening" than "simplifying data structures in some manner"; it doesn't even always involve what we'd traditionally think of as data structures at all, such as, again, IO. Personally I think it is an actively unhelpful metaphor for these reasons, as it is very prone to leading to false understanding, but YMMV.
- mediocrejoker 8y ago
  > There's really multiple definitions of "functional" right now It would be very helpful to see an explanation of this spectrum you describe for someone who is not really familiar with the definitions. I would love to read an explanation of the various “functional” paradigms as they diverge from “conventional” (ie. C) programming languages.
  - jerf 8y ago
    The weakest definition of functional is that functions are a first-class object that can be passed around. This is the one that C conforms to in that old sense. This is a dead definition because almost everything in modern use conforms to this definition, and definitions are only useful to the extent they create distinct categories. Because almost every modern language has this, it can be difficult to imagine a language in which this is not true. But, yes, once upon a time, languages did not in general have a data type that could contain a function that you could call. (This is before my time, but I caught the tail end of these arguments.) This was also one of the reasons that assembly programmers were always banging on about the power of assembly back in the day. Nowadays the only remnant of that argument is the claim that you can write more optimal assembly than the compiler. But back in the day, assembly programmers enjoyed the ability to have a pointer to a function and jump to it and/or call it (it's a bit fuzzier in assembler) and people using high-level languages were definitely getting a "weaker" experience. Today we expect our high level languages to also provide us significant power advantages over assembler. (Of course you can do anything in assembler, but not as concisely necessarily.) When I got into computing, the definition of "functional" that excluded C included having "closures". This is a function pointer + an environment for the function to run in. C only has the function pointer; you don't get an environment. It is more convenient than nothing, but vastly less useful than a full closure. (You can do them manually, but they become problematic fast.) Stepping up from there, you got languages that generally permitted an imperative style of programming, but "preferred" what we would today call a functional style, when you use map, filter, and such to perform operations. These languages loved them some linked lists; linked lists everywhere. With their own special names like "cons lists". They also tended to be garbage collected, which for a while was a "functional programming" thing, but is now also simply an accepted thing that a language may be, regardless of how "functional" it is. This definition is still in some usage today, though some improvement in understanding the structure of the relevant of code ("iteration" as a concept you can abstract, rather than accidentally conflating "a linked list" with "the thing you can iterate on") and the fact that hardware is getting ever-more grumpy about non-locality has erased the linked list obsession. You can either have a "functional language" like Lisp, or you can program in a "functional style" in a multi-paradigm language like Javascript. In the latter case, you can do a lot of work with the functional paradigm, but technically you always end back up at structured programming with some flavor of OO, which is the dominant language paradigm. (Languages can be multi-paradigm, but there is always a dominant paradigm, one that when the paradigms conflict, is the winner. And my personal default definition of OO includes Javascript, considering the prototype system a detail relative to the fact you still have "collections of data with associated methods".) People who say that "Javascript is a functional language" mean this definition. Finally, there's the Haskell definition. Here, immutability is the default, and possibly the only option. Type systems are very strong, able to express types like "a block of code that does not do any IO" that other languages can not express, or can only do very laboriously. You get "functor" and "monad" and such being not just demonstrated on a one-off basis, but being the foundational abstractions of libraries and entire applications. People argue over how much category theory you have to know to practically use these languages. F#, O'Caml, and Haskell live here. Haskell is as far as you can currently go in this direction and get a language usable for practical tasks, work that you can build a business on. (As an interesting side bar, I think Erlang made an error here, although a perfectly understandable one. When it was written, one of the reasons immutability was favored at the academic level was that it helped write multi-core code. At the time, only big industry and academia had multi-core systems. But you only really need isolation between threads. Immutability is one way to achieve this, but you can also make it so that it is impossible to communicate "references" between processes/threads, so everything is a copy. Within an Erlang process there's no reason not to allow one to "assign" to existing variables. But at the time, "access control" and "immutable" were sort of conflated together. Rust is the first big language that seems to be levering those concepts apart in a really systematic way.) However, the spectrum keeps going from here. Past Haskell there are functional languages that get really mathematical, and are focused on proving code, creating even more elaborate type systems such as dependent types ("this function takes a string whose length is a prime number", to give a silly example), and constraining the abstractions even further for things like total functional programming, which is one of the most interesting possible ways to limit programming so that it is not Turing Complete, but can still do real work. Here you can get such exotica as ways of using the type system to separate out what code is total, and what is not, in various principled ways. One of the common "I've been in this industry for 20 years and it sucks and here's what we all need to do to fix it" posts is to extol the virtues of one or more of these things. However, while there has been some interesting progress on many of these fronts in the past couple of decades, they remain impractical.
lr4444lr 8y ago
It's a pretty usefully compact definition. In my understanding however, it's valuable to note that the chain-ability of the bind operation also sets up a continuously nested set of closures, which is where the real power comes into play to give you a useful approximation to imperative programming. (This can easily be abused, of course, to circumvent thinking and structuring code functionally.) Related to this, SJP stressed in a talk some years back about how monads conveniently encapsulate the unavoidable messiness of side-effects in the least painful way yet discovered.

yen223 8y ago

Haskell-style types aren't a prerequisite for functional programming. Lisp and Elixir are dynamically-typed, which is why you don't see monads in those. That said, they do occasionally form useful abstractions.

AnimalMuppet 8y ago
Can you explain why you don't need monads if your language is dynamically typed? That's a new one to me.
- marcosdumay 8y ago
  I don't agree with that "not needed" explanation. But they are quite useless if the compiler can not deduce that both the values returned from the functions you are calling are monads, and what kind of binding should apply to them.
  - dvlsg 8y ago
    I find them to be at least somewhat useful in a language like javascript. I imagine they are more useful in a typed language with proper inference, but I wouldn't say they're entirely useless in a dynamic language.
  - AnimalMuppet 8y ago
    OK, for the slow of understanding: What I think you said is that, in an untyped language, a function will just return "something" (as far as the compiler is concerned). But in a typed language, the compiler knows that a monad was returned. So the point of the monad is to make the compiler do magic, not to make the runtime do magic. Is that accurate?
    - chowells 8y ago
      Well.. It's like 25% accurate, and you hit the part you were most worried about. But you have been seriously misled about monads in the past. There is no magic in monads. At the level of runtime operations, they're just a couple of functions. The magic taking place in the compiler is type inference guiding the selection of the right pair of functions during compilation. Without that, you have to explicitly use the correct functions. It's much easier to offload that bookkeeping to a computer than it is to do it yourself.
dragonwriter 8y ago
> Haskell-style types aren't a prerequisite for functional programming. Sure. > Lisp and Elixir are dynamically-typed, which is why you don't see monads in those. More to the point, Lisp and Elixir are impure functional languages, which is why you don't have some pure construct, like monads, that isolates IO.
- dllthomas 8y ago
  > you don't have some pure construct, like monads, that isolates IO In Haskell IO is isolated, and then the Monad interface is used for some particularly important ways of interacting with values of that type. That's not quite the same thing as "monads isolate IO" - the Monad interface is useful for quite a few other types of values.

green_on_black 8y ago

imo, that's basically what they are. altho the fact that they can be created via unit is actually really useful too (even tho thats technically part of applicative).

brianberns 8y ago

The Option/Maybe monad is very common in FP languages. I don't know if it's native in Elixir, but apparently it's pretty easy to implement: http://www.zohaib.me/monads-in-elixir-2/#maybe http://www.zohaib.me/monads-in-elixir-2/#maybe There are lots of ways to conceptualize monads. I think "functors that flatten" is accurate, but is just one way.

tuukkah 8y ago

Functors have fmap. Pointeds have pure. Monads have fmap, pure and join/flatten. So what's missing from "functors that can flatten" is pure, and monads are more precisely "pointed functors that can flatten". This is the canonical source: https://wiki.haskell.org/Typeclassopedia https://wiki.haskell.org/Typeclassopedia

jerf 8y ago

There's really multiple definitions of "functional" right now, and the type of "functional" being discussed here, Erlang isn't, and I don't think Elixir particularly is either. This is not a criticism of any kind; this is a point about definitions. There are definitions of functional where Erlang is functional, and IIRC Elixir can be said to support it. (And there are definitions of "functional" where almost every language in current use is "functional". There's even some so weak that C is "functional" because it has "function pointers", though this one is now out-of-date and not currently being used by anyone. But, yes, there was once a time in which C would have been considered "unusually strong" in its "functional programming" support, because other contemporary languages didn't even have function pointers.) "Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?" A little of both. Technically it is correct, but the "flattening" in question applies to many things that most programmers wouldn't consider "flattening". For instance, consider monadic IO as Haskell uses. There is a way in which you can consider the execution of an IO value as "flattening" it, and it corresponds to the mathematical term, but it's not what most people have in mind. There's more to "flattening" than "simplifying data structures in some manner"; it doesn't even always involve what we'd traditionally think of as data structures at all, such as, again, IO. Personally I think it is an actively unhelpful metaphor for these reasons, as it is very prone to leading to false understanding, but YMMV.

mediocrejoker 8y ago
> There's really multiple definitions of "functional" right now It would be very helpful to see an explanation of this spectrum you describe for someone who is not really familiar with the definitions. I would love to read an explanation of the various “functional” paradigms as they diverge from “conventional” (ie. C) programming languages.
- jerf 8y ago
  The weakest definition of functional is that functions are a first-class object that can be passed around. This is the one that C conforms to in that old sense. This is a dead definition because almost everything in modern use conforms to this definition, and definitions are only useful to the extent they create distinct categories. Because almost every modern language has this, it can be difficult to imagine a language in which this is not true. But, yes, once upon a time, languages did not in general have a data type that could contain a function that you could call. (This is before my time, but I caught the tail end of these arguments.) This was also one of the reasons that assembly programmers were always banging on about the power of assembly back in the day. Nowadays the only remnant of that argument is the claim that you can write more optimal assembly than the compiler. But back in the day, assembly programmers enjoyed the ability to have a pointer to a function and jump to it and/or call it (it's a bit fuzzier in assembler) and people using high-level languages were definitely getting a "weaker" experience. Today we expect our high level languages to also provide us significant power advantages over assembler. (Of course you can do anything in assembler, but not as concisely necessarily.) When I got into computing, the definition of "functional" that excluded C included having "closures". This is a function pointer + an environment for the function to run in. C only has the function pointer; you don't get an environment. It is more convenient than nothing, but vastly less useful than a full closure. (You can do them manually, but they become problematic fast.) Stepping up from there, you got languages that generally permitted an imperative style of programming, but "preferred" what we would today call a functional style, when you use map, filter, and such to perform operations. These languages loved them some linked lists; linked lists everywhere. With their own special names like "cons lists". They also tended to be garbage collected, which for a while was a "functional programming" thing, but is now also simply an accepted thing that a language may be, regardless of how "functional" it is. This definition is still in some usage today, though some improvement in understanding the structure of the relevant of code ("iteration" as a concept you can abstract, rather than accidentally conflating "a linked list" with "the thing you can iterate on") and the fact that hardware is getting ever-more grumpy about non-locality has erased the linked list obsession. You can either have a "functional language" like Lisp, or you can program in a "functional style" in a multi-paradigm language like Javascript. In the latter case, you can do a lot of work with the functional paradigm, but technically you always end back up at structured programming with some flavor of OO, which is the dominant language paradigm. (Languages can be multi-paradigm, but there is always a dominant paradigm, one that when the paradigms conflict, is the winner. And my personal default definition of OO includes Javascript, considering the prototype system a detail relative to the fact you still have "collections of data with associated methods".) People who say that "Javascript is a functional language" mean this definition. Finally, there's the Haskell definition. Here, immutability is the default, and possibly the only option. Type systems are very strong, able to express types like "a block of code that does not do any IO" that other languages can not express, or can only do very laboriously. You get "functor" and "monad" and such being not just demonstrated on a one-off basis, but being the foundational abstractions of libraries and entire applications. People argue over how much category theory you have to know to practically use these languages. F#, O'Caml, and Haskell live here. Haskell is as far as you can currently go in this direction and get a language usable for practical tasks, work that you can build a business on. (As an interesting side bar, I think Erlang made an error here, although a perfectly understandable one. When it was written, one of the reasons immutability was favored at the academic level was that it helped write multi-core code. At the time, only big industry and academia had multi-core systems. But you only really need isolation between threads. Immutability is one way to achieve this, but you can also make it so that it is impossible to communicate "references" between processes/threads, so everything is a copy. Within an Erlang process there's no reason not to allow one to "assign" to existing variables. But at the time, "access control" and "immutable" were sort of conflated together. Rust is the first big language that seems to be levering those concepts apart in a really systematic way.) However, the spectrum keeps going from here. Past Haskell there are functional languages that get really mathematical, and are focused on proving code, creating even more elaborate type systems such as dependent types ("this function takes a string whose length is a prime number", to give a silly example), and constraining the abstractions even further for things like total functional programming, which is one of the most interesting possible ways to limit programming so that it is not Turing Complete, but can still do real work. Here you can get such exotica as ways of using the type system to separate out what code is total, and what is not, in various principled ways. One of the common "I've been in this industry for 20 years and it sucks and here's what we all need to do to fix it" posts is to extol the virtues of one or more of these things. However, while there has been some interesting progress on many of these fronts in the past couple of decades, they remain impractical.

lr4444lr 8y ago

It's a pretty usefully compact definition. In my understanding however, it's valuable to note that the chain-ability of the bind operation also sets up a continuously nested set of closures, which is where the real power comes into play to give you a useful approximation to imperative programming. (This can easily be abused, of course, to circumvent thinking and structuring code functionally.) Related to this, SJP stressed in a talk some years back about how monads conveniently encapsulate the unavoidable messiness of side-effects in the least painful way yet discovered.