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

111–116 of 116 posts

Re: Deconstructing Functional Programming [video]

#111

Post by Peaker »

tel wrote: post #107
gohrt wrote: post #76

Earlier quoted context omitted.

Check yourself before you try to say that "appendable" is an inappropriate name for Monoid. http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Mo... Methods mempty mappend mconcat Haskell people like their mathy terms. Mathy terms aren't universally unambigious ("group"? "ring"? "field"?), but they are mostly unambiguous within math. Haskell people tend to pretend Haskell is the same as math, ignoring the prog…

In practical Haskell people rarely use mappend eschewing it for the more generic ( ) operator. Personally I think it's exactly for the reason stated above—monoid is far more general than "appending". In particular, it's easy to define a reverse monoid for any (non-commutative) monoid such that append becomes prepend. It's easy to construct monoids which have different spacial properties like Diagrams' "stacking" mono…

Everyone hates the name mappend but it's still more commonly used than which iirc is relatively recent.

Re: Deconstructing Functional Programming [video]

#112

Post by tel »

Peaker wrote: post #111
tel wrote: post #107

Earlier quoted context omitted.

In practical Haskell people rarely use mappend eschewing it for the more generic ( ) operator. Personally I think it's exactly for the reason stated above—monoid is far more general than "appending". In particular, it's easy to define a reverse monoid for any (non-commutative) monoid such that append becomes prepend. It's easy to construct monoids which have different spacial properties like Diagrams' "stacking" mono…

Everyone hates the name mappend but it's still more commonly used than which iirc is relatively recent.

For the record, I agree. There's a lot of older code where `mappend` is used commonly. More accurately, I should have said that () has taken modern coding style by storm.

Re: Deconstructing Functional Programming [video]

#113

Post by asdasf »

gohrt wrote: post #76
asdasf wrote: post #50

Earlier quoted context omitted.

You are using the exact reasoning I was talking about. Monoids are monoids. That is what they are. 99% of programmers are not familiar with them. If you call it "addable" or "joinable" or "appendable" then you are just making people think that one subset of some monoids is the definition of monoids when it isn't. They still don't know what monoids are, now they just also don't know what they are called. You are liter…

Check yourself before you try to say that "appendable" is an inappropriate name for Monoid. http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Mo... Methods mempty mappend mconcat Haskell people like their mathy terms. Mathy terms aren't universally unambigious ("group"? "ring"? "field"?), but they are mostly unambiguous within math. Haskell people tend to pretend Haskell is the same as math, ignoring the prog…

I am fully aware of what the typeclass defines. It is an inappropriate name. I don't think there is anyone who likes those names. Everyone uses instead of mappened. Append is inappropriate because you do not append lots of monoids, like Product and Sum for example.

Re: Deconstructing Functional Programming [video]

#114

Post by asdasf »

agentultra wrote: post #13
asdasf wrote: post #8

Earlier quoted context omitted.

CLOS and scala have very little in common, both in the functional side and the OO side. Ocaml and F# are better examples. Can I ask what you think made this a brilliant talk? It seemed like the standard "I don't want to have to learn so I will pretend there's no reason to learn" nonsense we hear all the time.

wrt. CLOS/Scala, indeed very little in common and I didn't intend to suggest they were similar. In recent articles that mention this idea Scala is often mentioned in the same breath as if it has exclusive domain over it. I simply meant to debunk that claim if it exists. I thought it was brilliant because Gilad provides a humble deconstruction of common myths and claims of the FP culture. He is skeptical and I didn't…

>Gilad provides a humble deconstruction of common myths and claims of the FP culture

He argued with a joke from a comic and lost. Even he would laugh in your face at the notion that there was anything humble about his talk.

>He is skeptical and I didn't find any of his conclusions to be dismissive

That is precisely the opposite of reality. He doesn't even understand functional programming, he is thus not skeptical, he is dismissive.

>He was there to break through the hype and I think he was successful.

The fact that both he and you believe there is "hype" is indicative of the problem. "Hey, you should learn things and improve your skills" is not hype.

Most of what he says is outright wrong. He talks about smalltalk inventing all of this FP stuff that was in ML before smalltalk-76 "invented" them. He pretends smalltalk predates FP, except again, ML predates smalltalk-76. and smalltalk-72 didn't have the stuff he is talking about. He talks about things "FP languages can't do", but that I do all the time in haskell with no issues. He repeats the oldest most worn out fallacious arguments that have been debunked over and over, and pretends that since nobody is allowed to interrupt the talk to correct him, his arguments are correct. Everything about his talk is an example of the exact opposite of what you suggest it is. If you want someone to convincingly lie to you about how FP isn't all that, look to Erik Meijer. Gilad sucks at it.

Re: Deconstructing Functional Programming [video]

#115

Post by qu1j0t3 »

mafribe wrote: post #79

I found Bracha's talk poor. That guy really has a chip on his shoulder vis-a-vis functional programming. A lot of things he said were not well though out. Here are some examples. - He claimed that tail recursion could be seen as the essence of functional programming. How so? - He complained that tail recursion has problems with debugging. Well, tail recursion throws away stack information, so it should not be a surpr…

Recursion and iteration are equivalent, so it's not much of a stretch to call it a core concept (for more, see SICP & the lambda calculus). It is the only form of iteration available in functional programming.

Monads are not only a good abstraction, they are essential* if we are to move away from haphazard construction. Normal programmers have invented them many times; as the truism goes, you have have even "invented" them yourself.

Remember when function pointers seemed tricky and unnecessary? Remember when closures seemed tricky and unnecessary? Yeah. One day you're going to see monads in the same way.

* - Functional programming => programming with pure functions.

Re: Deconstructing Functional Programming [video]

#116

Post by qu1j0t3 »

charlieflowers wrote: post #95
paulkoer wrote: post #27

Earlier quoted context omitted.

I recommend: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad... But in the end I think for most people 'understanding' the concept of monads is just something that is not to be had within a couple of hours. It takes a little bit of patience thinking about them and using them for a while.

The core problem seems to be that we just don't (yet) have good words for this particular space of abstractions. Many programmers have thought about or solved the same problem monads address, but they haven't mentally labelled the concept, and we certainly have agreed as an industry on these labels. So we're all struggling to try to talk about some things we don't have terms for.

"The core problem seems to be that we just don't (yet) have good words for this particular space of abstractions"

How about "functor," "monad," "applicative" etc.?

Post reply on HN