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

Deconstructing Functional Programming [video]

infoq.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: Deconstructing Functional Programming [video]

#61

Post by taeric »

asdasf wrote: post #56
taeric wrote: post #45

Earlier quoted context omitted.

Did you watch the video? I'm not referring to monads simulating something. I'm referring to the observation that when reading code you are simulating its execution. My understanding of the video's complaint against monads is that the signature of monads is actually quite simple and well understood in different contexts by different names. The video goes on to display an environment where you do not have to simulate t…

>This progression seems somewhat interesting to me. As does the desire to not have to simulate code in your head. But none of that has anything to do with monads.

Ok... I think I'm getting trolled at this point.

I am taking issue with the video's critique of monads. Wherein it is claimed that monads manage to take a common and understandable behavior and make it laughably impossible to explain to people by giving it a weird name. Essentially, the problem with monads is one of it being difficult to "simulate" under the name "monad" for many individuals.

This part, I actually feel makes sense and resonates well. Simply follow the progression in the video and see how "FlatMappable" becomes less and less intuitive as it is given worse and worse names.

The part that is interesting to me, is how this then progresses into a point on how programmers should not have to simulate the code in their head. Now, I realize there is a big difference between "should not have to" and "is difficult to intuitively do so". Still seems an odd progression, though.

Re: Deconstructing Functional Programming [video]

#62

Post by jejones3141 »

thinkpad20 wrote: post #54
Peaker wrote: post #52

Earlier quoted context omitted.

I've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary. Monad is simple and hard, but Monoid is simple and easy.

With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematica…

Well, yeah, but... the term "monoid" already exists, and has a definite meaning. A different name might give people an intuition for it--but it will be a wrong one that they'll have to unlearn later, like the infamous burrito (not that you or anyone has suggested that monads be renamed burritos, I am happy to say!).

Re: Deconstructing Functional Programming [video]

#63

Post by bunderbunder »

latk wrote: post #14
namelezz wrote: post #9

In his talk on currying, he mentioned replying on type system to not be a good thing. Does anyone know the reasons behind his view?

Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance. As a re…

It's a problem with ML syntax, but one that can easily be overcome with parentheses. Sort of like how a circumspect C programmer uses parentheses in complex mathematical expressions rather than relying on everyone being able to correctly remember complex order of operation rules.

OTOH, pipeline operators make a good case for currying. There really is something nice about being able to write

  sliceOfBread
  |> smearWith peanut-butter
  |> smearWith jelly
  |> topWith sliceOfBread
  |> cutInHalf
  |> eat
instead of

  eat(cutInHalf(topWith(sliceOfBread, smearWith(jelly, smearWith(peanut-butter, sliceOfBread)))))

Re: Deconstructing Functional Programming [video]

#64

Post by namelezz »

latk wrote: post #14
namelezz wrote: post #9

In his talk on currying, he mentioned replying on type system to not be a good thing. Does anyone know the reasons behind his view?

Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance. As a re…

Thank you for your explanation.

Re: Deconstructing Functional Programming [video]

#65

Post by asdasf »

taeric wrote: post #61
asdasf wrote: post #56

Earlier quoted context omitted.

>This progression seems somewhat interesting to me. As does the desire to not have to simulate code in your head. But none of that has anything to do with monads.

Ok... I think I'm getting trolled at this point. I am taking issue with the video's critique of monads. Wherein it is claimed that monads manage to take a common and understandable behavior and make it laughably impossible to explain to people by giving it a weird name. Essentially, the problem with monads is one of it being difficult to "simulate" under the name "monad" for many individuals. This part, I actually fe…

>Ok... I think I'm getting trolled at this point.

If you don't want to discuss something, then don't post. You are not making any sense, and calling people trolls does not help at all.

Re: Deconstructing Functional Programming [video]

#66

Post by bunderbunder »

Great talk. Particularly the bit on the value of naming things - I rather wish he'd flogged that a bit harder.

As time goes on I'm finding it more and more frustrating to try and maintain code that relies entirely on anonymous and structural constructs without any nominal component. Yes, I do feel super-powerful when I can bang out a bunch of code really quickly by just stacking a bunch of more-or-less purely mathematical constructs on top of each other. . . but as the story of the Mars Climate Orbiter should teach us rather poignantly, when you're trying to engineer larger, more complex systems it turns out that meta-information is actually really useful stuff.

Re: Deconstructing Functional Programming [video]

#67

Post by Dewie »

thinkpad20 wrote: post #22
asdasf wrote: post #7

Earlier quoted context omitted.

>The points he makes against obtuse names based in category theory are valid No, they aren't. When you have a class of "things" that doesn't have a name most people are familiar with, you are left with two options. Either choose a name people are familiar with, but which is wrong and misleading. Or choose the correct name and people have to learn a name. Are we seriously so pathetic as an industry that learning 3 new…

To an extent, I think it's a valid criticism. There are two main problems with the mathy names that many concepts in Haskell have. The first is that they hide the meaning. For example, "Monoid" is a really scary term, and explaining it further as "something with an identity and an associative operation" really doesn't help much either. Calling it instead "Addable" or "Joinable", and explaining it instead as "things w…

I think some people should at least try to get over their math-phobia. I am trying to myself, and math is an uphill battle for me even without that kind of fear. The sloppy, opaque, inconsistent and often overloaded notation is an impediment, the 'let the reader infer most of this' proofs are an impediment... but if people are turned off to such a degree over a few names, they wouldn't last long in something which is such a mathy language anyway, relatable names or not.

Re: Deconstructing Functional Programming [video]

#68

Post by munificent »

latk wrote: post #14
namelezz wrote: post #9

In his talk on currying, he mentioned replying on type system to not be a good thing. Does anyone know the reasons behind his view?

Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance. As a re…

> more of a criticism of ML syntax than of currying – all things are good in moderation.

I don't follow this. My understanding is that currying is pure syntactic sugar: it's a cheap way to expression partial application.

What am I missing?

Re: Deconstructing Functional Programming [video]

#69

Post by groovy2shoes »

bunderbunder wrote: post #63
latk wrote: post #14

Earlier quoted context omitted.

Currying can obfuscate what is applied to what. Consider in any ML language "a b c d" – we can see that "a" is a function, but we have no idea of its arity. Uncurried, it could be: "a(b, c, d)", "a(b, c)(d)", "a(b)(c, d)", "a(b)(c)(d)" (oh, that's the curried form again). Especially when function definitions are implied through pattern matching, it is hard to understand the contract of a function at a glance. As a re…

It's a problem with ML syntax, but one that can easily be overcome with parentheses. Sort of like how a circumspect C programmer uses parentheses in complex mathematical expressions rather than relying on everyone being able to correctly remember complex order of operation rules. OTOH, pipeline operators make a good case for currying. There really is something nice about being able to write sliceOfBread |> smearWith…

I just want to point out that the pipeline operator (or, more accurately, the forward application operator), is not provided by many ML implementations, but it's trivial to define it yourself. Here it is in Standard ML:

    infix |>;
    fun x |> f = f x;
The definition is also similar in Haskell:

    x |> f = f x
And in OCaml:

    let (|>) x f = f x;;
F# and Elm provide this operator out of the box.

Re: Deconstructing Functional Programming [video]

#70

Post by Peaker »

thinkpad20 wrote: post #54
Peaker wrote: post #52

Earlier quoted context omitted.

I've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary. Monad is simple and hard, but Monoid is simple and easy.

With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematica…

We must have different ideas about what "practicality" is.
Post reply on HN