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

21–30 of 116 posts

Re: Deconstructing Functional Programming [video]

#21

Post by catnaroek »

asdasf wrote: post #7
jstratr wrote: post #6

Interesting talk! Bracha has some good arguments against features that I generally enjoy in programming languages, like Damas–Hindley–Milner type inference and pattern matching. Regarding Haskell: The points he makes against obtuse names based in category theory are valid, but then again, Haskell has its roots in research programming languages. Math-based terminology makes more sense for an academic audience.

>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…

> Are we seriously so pathetic as an industry that learning 3 new technical terms is a problem?

We are even more pathetic than that. If the underlying concepts are misleading but evoke a warm and fuzzy sense of familiarity (objects), we will accept them wholeheartedly. If the underlying concepts are mathematical, we will reject them as disconnected with our everyday needs.

Re: Deconstructing Functional Programming [video]

#22

Post by thinkpad20 »

asdasf wrote: post #7
jstratr wrote: post #6

Interesting talk! Bracha has some good arguments against features that I generally enjoy in programming languages, like Damas–Hindley–Milner type inference and pattern matching. Regarding Haskell: The points he makes against obtuse names based in category theory are valid, but then again, Haskell has its roots in research programming languages. Math-based terminology makes more sense for an academic audience.

>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 with a default 'zero' version, and which have a way to add two of them together", while perhaps not a perfect definition, would be much more intuitive for the majority of people.

That brings me to the second problem I see, which is that the esoteric terminology in Haskell creates a barrier between those who understand it, and those who don't, and contribute to a sense of Haskell culture being exclusionary and cult-like, which discourages cross-talk.

Criticizing Hindley-Milner, on the other hand, I'm confused by. It's such a useful and powerful system. I suppose it can make compiler errors more obscure at times, but you get used to reading them and they aren't so bad. Hindley-Milner isn't just a type inferrence system; it's a typing system which allows for the most general typing to always be used, so that the functions one writes are as general as possible, encouraging modularity and code reuse.

Re: Deconstructing Functional Programming [video]

#23

Post by carterschonwald »

chongli wrote: post #20
[deleted] wrote: post #18

[deleted]

You've probably read too many monad tutorials that make terrible analogies. Try reading this instead: http://dev.stephendiehl.com/hask/

yes, i can comfortably say "any doc by stephen diehl is worth reading" :)

Re: Deconstructing Functional Programming [video]

#24

Post by catnaroek »

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…

What is so scary about monoid? A classical monoid is precisely a category with one object, hence the name. "Addable" and "Joinable" do not quite cut it - not all monoids are defined on numbers (or generalizations of them such as vectors or matrices) or sets (or generalizations of them such as categories or topological spaces).

Re: Deconstructing Functional Programming [video]

#26

Post by thinkpad20 »

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 actually simpler in some ways, because we know that "a" must have arity 1. What we know is that "a" should be a function which takes a "b", that "a b" should be a function which takes a "c", and "a b c" should take a "d".

As a practical consideration, this rarely if ever becomes an issue, and if it does, the type checker will tell you straight away.

Type annotations can make clear what isn't intuitively clear with a function's signature, and since the correctness of the type checker is rigorously proven, I don't see anything particularly wrong with "relying" on the type checker.

Re: Deconstructing Functional Programming [video]

#27

Post by paulkoer »

[deleted] wrote: post #18

[deleted]

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.

Re: Deconstructing Functional Programming [video]

#28

Post by chongli »

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…

This is not a problem in Haskell, as it makes a distinction between the types of all these different functions. The uncurried forms take tuples (a distinct type) as arguments whereas the curried form does not.

Re: Deconstructing Functional Programming [video]

#30

Post by sethev »

asdasf wrote: post #7
jstratr wrote: post #6

Interesting talk! Bracha has some good arguments against features that I generally enjoy in programming languages, like Damas–Hindley–Milner type inference and pattern matching. Regarding Haskell: The points he makes against obtuse names based in category theory are valid, but then again, Haskell has its roots in research programming languages. Math-based terminology makes more sense for an academic audience.

>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…

Part of his critique is that they do use terms that people are familiar with but which are misleading, like "return".
Post reply on HN