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

41–50 of 116 posts

Re: Deconstructing Functional Programming [video]

#41

Post by Peaker »

latk wrote: post #38
thinkpad20 wrote: post #26

Earlier quoted context omitted.

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

The argument that every function has arity 1 is technically true (this is the whole point of currying) but is not useful when definitions like "let a b c = ..." suggest other semantics. It's possible you've had a difference experience with this, but I tend to get confused when the semantic argument list isn't delimited. There is nothing wrong with relying on the type checker, except that it tends to add cognitive ove…

"let a b c = ..." doesn't suggest other semantics. It's saying: "a applied to b, and then applied to c, equals ...". Note Haskell makes an effort to have the LHS of definitions imitate the exact syntax of function application. Patterns use the same syntax as data constructor applications.

Re: Deconstructing Functional Programming [video]

#42

Post by lmm »

paulkoer wrote: post #27
[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.

FWIW I'll post mine: http://m50d.github.io/2013/01/16/generic-contexts.html

Re: Deconstructing Functional Programming [video]

#43

Post by catnaroek »

Peaker wrote: post #35
catnaroek wrote: post #19

Earlier quoted context omitted.

Scala and Common Lisp are not particularly functional languages. Functional programming in Scala is doable, although it takes a nontrivial amount of effort (see: scalaz), and it is outright impractical in Common Lisp. As an aside, CLOS multimethods resemble Haskell's multiparameter type classes (except CLOS is dumber: you cannot provide any guarantee that the same types will provide two or more common operations) mor…

Multimethods are not quite as powerful as type-classes. Type-classes can dispatch on any part of the type signature, whether it is an argument, result type, parameter to a type, etc.

Agreed there. But give me a little break, I only said "resemble", not "are the same as". :-)

Re: Deconstructing Functional Programming [video]

#44

Post by thinkpad20 »

Peaker wrote: post #37
thinkpad20 wrote: post #22

Earlier quoted context omitted.

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…

"Addable" will not actually be more informative than "Monoid", to someone who doesn't know "Monoid". "Monoid" will be very informative to anyone who learned it from mathematics. A "Monoid" is a type which supports an associative operation (`m -> m -> m`) and a neutral element (`m`) which forms its identity element. "Addable" suggests it is an "addition". Does this mean it is commutative? For the sake of preciseness,…

That's a completely valid point of view. You're not wrong at all. I'm guessing, though, that you had learned it before from mathematics. My point is one of pragmatic, not theoretical, distinction. To those without a mathematical background (most people are not going to learn monoid unless they've studied abstract algebra), or who are less interested in mathematics in general, an obscure term like that is discouraging. I know that the Haskell community is heavily mathematical, and have little interest in "dumbing down" the language for the sake of those who are put off by theory, but it is a real tradeoff and one of the things that is likely to impede the introduction of Haskell into the mainstream.

Re: Deconstructing Functional Programming [video]

#45

Post by taeric »

catnaroek wrote: post #17
taeric wrote: post #4

First, thanks for all involved in getting this posted! I'm somewhat curious on why the industry has such an aversion to simulating things in our mind. Especially when this seems to be one of the arguments employed against monads in this speech. That it basically couches something known in an odd name that is not known. Isn't this just stating that it is bad because it confuses the simulator that is the reader? That s…

Monads have nothing to do with simulating anything. They are just a commonly recurring pattern of computational contexts (more precisely, functors) that also provide two basic operations: 1. entering the context (pure :: a -> m a) 2. collapsing nested contexts into one (join :: m (m a) -> m a) Together with some coherence laws that ensure that these operations do exactly, no more or less, than entering the context an…

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 the code in your head.

This progression seems somewhat interesting to me. As does the desire to not have to simulate code in your head.

Re: Deconstructing Functional Programming [video]

#46

Post by catnaroek »

agentultra wrote: post #36
catnaroek wrote: post #19

Earlier quoted context omitted.

Scala and Common Lisp are not particularly functional languages. Functional programming in Scala is doable, although it takes a nontrivial amount of effort (see: scalaz), and it is outright impractical in Common Lisp. As an aside, CLOS multimethods resemble Haskell's multiparameter type classes (except CLOS is dumber: you cannot provide any guarantee that the same types will provide two or more common operations) mor…

It is a common mistake I've heard from many CL newbies that believe CL is a "FP" language. The best descriptor I can find to date (of CL) is, "programmable programming language," which allows it to encompass almost every desired feature one may need; including many that fall under the FP umbrella which may be where the confusion stems from. However one of the opening points of the talk was that, "FP," is not a rigoro…

> As for your aside, how so?

CLOS multimethods do not "belong" to an object or even to a class declaration. Particular implementations of generic methods are declared globally, just like Haskell type class instances. Although, as Peaker noted, type classes can dispatch on any part of the type signature. It is impossible to make a CLOS multimethod with signature:

    (SomeClass a b) => String -> (a, b)
> Perhaps a discussion we can have over email if you're interested.

Sorry, I never check email. But I am almost always on Freenode. My nick is pyon.

> You sound smart.

Not really. The regulars in #haskell - now they are frigging smart.

Re: Deconstructing Functional Programming [video]

#47

Post by thinkpad20 »

latk wrote: post #38
thinkpad20 wrote: post #26

Earlier quoted context omitted.

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

The argument that every function has arity 1 is technically true (this is the whole point of currying) but is not useful when definitions like "let a b c = ..." suggest other semantics. It's possible you've had a difference experience with this, but I tend to get confused when the semantic argument list isn't delimited. There is nothing wrong with relying on the type checker, except that it tends to add cognitive ove…

In my experience, the more you use currying, the more intuitive it becomes (surprise, surprise). In any case, you very quickly develop an understanding that `let foo bar baz = qux` is just syntactic sugar for `let foo = \bar -> \baz -> qux`. Of course, if you want to simulate higher-arity functions, you could just use tuples. It's perfectly acceptable to write `let foo(bar, baz) = qux`.

Re: Deconstructing Functional Programming [video]

#49

Post by jstratr »

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?

For most people, yeah, I think monads are a big hurdle. They look intimidating to outsiders.

I still have to admit that I like the approach Haskell has taken. Sure, it's harder to grasp the concepts if you don't have a background in math, but it's not like monads, monoids, arrows, and functors were thrown in there just to be pretentious. There's a whole lot of useful theory surrounding those concepts that can be used to the programmer's advantage.

Re: Deconstructing Functional Programming [video]

#50

Post by asdasf »

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…

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 literally giving it an incorrect and misleading name. All that does is confuse people. You have to learn what monoids actually are even if you call them "addable"s. Rather than learning a misleading name for them, it is quite simple to learn a new term like "monoid". Considering there is really only 3 that people need to learn (monoid, functor, monad) this is not an overwhelming burden.
Post reply on HN