Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads as a Programming Pattern

samgrayson.me

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Monads as a Programming Pattern

#61

Post by toastal »

secure wrote: post #49
toastal wrote: post #12

I get the intention but it's even harder to understand with this Java/C# syntax. I feel like if you're gonna talk about FP you should probably highlight along the Haskell or Scala code (or similar) and provide OOP stuff for reference in case it's not clear. It ends up being so verbose that I don't many people see the 'point'.

To me, reading examples in a syntax I’m familiar in helps me much more than reading them in a language where the concept might be elegant to express, but hard for me to get into. I think it’d be best to include examples in a number of languages with a lanugage selector, actually. That way, people who are fluent in functional languages can read that version, and others can read the one they are more fluent in.

Here's a real life tangential example: I'm learning Thai. When I first started it was useful to show the Latin alphabet to get a grasp but it's often difficult or inaccurate to try to express that language without the system designed to express it. For instance, many romanizations lack a tone marker for tonal language, or don't show vowel length when it matters. Or for laughable example of พร, meaning 'blessing' but also a common woman's name, being traditionally romanized to 'porn' with its silent r when 'pawn' is a more neutral pronunciation for all English dialects (or /pʰɔːn/). Also, not being able to read or write the language, you will have a difficult time effectively engaging with the community and understanding the world around you.

The point is, functional languages are designed to express these concepts with much, much less cruft with extra features like currying, immutability-by-default, and type classes. Yes, use your current language to get oriented, but if you're going to really learn it, pick up a proper syntax to express it.

Re: Monads as a Programming Pattern

#62

Post by saghm »

toastal wrote: post #61
secure wrote: post #49

Earlier quoted context omitted.

To me, reading examples in a syntax I’m familiar in helps me much more than reading them in a language where the concept might be elegant to express, but hard for me to get into. I think it’d be best to include examples in a number of languages with a lanugage selector, actually. That way, people who are fluent in functional languages can read that version, and others can read the one they are more fluent in.

Here's a real life tangential example: I'm learning Thai. When I first started it was useful to show the Latin alphabet to get a grasp but it's often difficult or inaccurate to try to express that language without the system designed to express it. For instance, many romanizations lack a tone marker for tonal language, or don't show vowel length when it matters. Or for laughable example of พร, meaning 'blessing' but…

Sure, but to extend your metaphor, using Haskell to teach non-Haskell programmers about monads is like using Thai to teach English speakers the history of Thailand; the language might be better suited for the topic, but the people you're teaching don't know it, and learning it is orthogonal to the actual thing you're trying to teach them.

Re: Monads as a Programming Pattern

#63

Post by andrekandre »

fizixer wrote: post #60
andrekandre wrote: post #59

Earlier quoted context omitted.

> Computing is not a subset of mathematics. And Mathematics is not a subset of Computing. Same goes with Physics (Physics is not a subset of Mathematics, despite there being way more math used in Physics than CS). if i understand you correctly, are you saying that mathematics in the classical sense is not “computing” (von neumann machines?), just as math is not physics, but math is used to model physics then the prop…

I think what I'm trying to say also goes by a well known aphorism by Alfred Korzybski: The map is not the territory [1]. We like to model stuff in computing and stuff in physics, using mathematics. What we're really doing is creating maps (math models) of the territory (computing, and physics). We notice there is some part of the stuff not fully mapped, so we make our map more complex and more elaborate. We keep maki…

thanks, really appreciate the thoughtful answer and i’ll take a look at those links as well

much food for thought

Re: Monads as a Programming Pattern

#64

Post by hardwaresofton »

Another really good functional (as in related to how they work) explanation of monads:

http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

It's somewhat more than a monad explanation -- it covers functors and applicatives, and is somewhat haskell specific, but it was one of the guides that really clicked for me when I was trying to grok monads

Re: Monads as a Programming Pattern

#65

Post by jpfed »

zug_zug wrote: post #24

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future. However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad." So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an e…

Other replies talk about how Promises can be implemented as monads. Aside from that, you can come up with your own, too.

One monad that I occasionally use is something I'll call "Tracked". For "return" (when we make a new instance of the monad) we store a pair (initialValue, initialValue). For "bind" (when we act on what's in the monad) we only ever touch the second value in the pair, returning (initialValue, transformedValue).

That way, you can know where this piece of data came from. I've gotten a lot of mileage out of Tracked>: when one of your Results is an exception, then you can check what piece of data ended up triggering that exception. Yes, you could do this without the Tracked monad, but doing it monadically means that most of your functions don't need to know or care about tracking the initial data; you can just Apply those simpler functions and the Tracked instance will do it for you.

Re: Monads as a Programming Pattern

#66

Post by Double_Cast »

rhizome wrote: post #51
stcredzero wrote: post #39

Earlier quoted context omitted.

How do you deal with state in a language that would prefer to be stateless? Encapsulation? No one gets direct access to the state. Instead, there are methods or functions for dealing with the state indirectly, crafted to protect those outside. Answer: wrap the entire external universe and all its messy state up into an object, then pass that down a chain of functions which can return "universe, but with some bytes wr…

> A monad is a type that wraps an object of another type. So, the Adapter Pattern, but for types?

Monadic is a type-class. Like how Equatable is a type-class. Adapters essentially add a specific type to the type-class the client is looking for.

Re: Monads as a Programming Pattern

#67

Post by mrbrowning »

noelwelsh wrote: post #14
chongli wrote: post #9

Earlier quoted context omitted.

groups as an example Why not go all the way and teach functors and applicatives before monads? Then the student can see that monads are just a small addition built on top of the other two. Functors, in particular, are very easy to grasp despite their intimidating name. They just generalize map over arbitrary data structures: l_double : List Int -> List Int l_double xs = map (* 2) xs f_double : Functor f => f Int -> f…

Functors are not useful for much on their own, so they are difficult to motivate. The Haskell formulation of applicatives doesn't make much sense outside of languages where currying is idiomatic---which is most languages. In these languages you tend to see the product / semigroupal formulation, and here applicatives become a bit trickier to explain as you need more machinery.

Functors enable the Fix functor and, from there, the whole universe of recursion schemes, so I'm not sure that I agree that they're not useful on their own.

Re: Monads as a Programming Pattern

#68

Post by Sharlin »

eli_gottlieb wrote: post #58
Sharlin wrote: post #41

Earlier quoted context omitted.

There is a saying that the difference between poetry and math is that poetry is about giving different names to the same thing, and math is about giving the same name to different things. Grokking monads really requires the adoption of the mathematical mindset of finding commonalities in things that at a first glance appear completely different. Tell an average OO programmer that lists, exceptions, dependency injecti…

>Of course, just the fact that abstracting over those things is possible doesn’t mean it is useful. In a pure FP language it might be necessary, but why should I bother with weird mathy things in my imperative language that has side effects and global state? You really have to start by explaining why composability is such a nice thing to have, and that gives the motivation for various FP patterns that are, fundamenta…

Yeah. And then you start hearing about these things called algebraic effects…

Re: Monads as a Programming Pattern

#69

Post by dorgo »

Sharlin wrote: post #41
pjc50 wrote: post #30

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning. Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way t…

There is a saying that the difference between poetry and math is that poetry is about giving different names to the same thing, and math is about giving the same name to different things. Grokking monads really requires the adoption of the mathematical mindset of finding commonalities in things that at a first glance appear completely different. Tell an average OO programmer that lists, exceptions, dependency injecti…

>but why should I bother with weird mathy things in my imperative language that has side effects and global state

There are good reasons, like encapsulation, etc. But the real reason is, it just dosn't feel right and there is this urge to fix it.

Re: Monads as a Programming Pattern

#70

Post by mlevental »

dmitriid wrote: post #8
ajnin wrote: post #7

Earlier quoted context omitted.

"Introduction to monads" articles generally miss the mark because either 1) they insist on using Haskell syntax throughout, and this is most likely to be unfamiliar and obtuse to programmers looking for this kind of articles. Expecting people to learn a new syntax at the same time as a new concept is bound to be confusing. At least it was for me when I first came across the idea. Or 2) they go through a bunch of exam…

> they insist on using Haskell syntax throughout, and this is most likely to be unfamiliar and obtuse to programmers looking for this kind of articles. Indeed, that is a big part of a problem. I find "Functional Programming Jargon" [1] extremely approachable (if you already know modern JS) even though it has been pointed out that their definitions might not be "pure"/correct enough. [1] https://github.com/hemanth/fun…

you know of something like this in Python? I know enough js to read that but I'd prefer python
Post reply on HN