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

31–40 of 116 posts

Re: Deconstructing Functional Programming [video]

#31

Post by catnaroek »

sethev wrote: post #30
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…

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

So call it "pure". I agree that "return" is not the most fortunate term.

Re: Deconstructing Functional Programming [video]

#32

Post by catnaroek »

chongli wrote: post #28
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…

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.

In ML, they are all different functions as well.

Re: Deconstructing Functional Programming [video]

#34

Post by thinkpad20 »

[deleted] wrote: post #18

[deleted]

As someone who went through the same thing, my best advice is, don't read monad tutorials; just write monadic code. Reading too much can just be confusing and might make you feel like an idiot for not understanding it yet. In the beginning it might be weird, and you'll no doubt spend a great deal of time puzzling over obscure type errors, but it will eventually become intuitive, if you're actually writing code and working through it. Haskell is a theory-heavy language, but it's still a programming language, which is actually meant to do things. There's no substitute for experience.

Perhaps try going through "Write Yourself a Scheme" which uses monads from the outset, or look at "Monad Transformers Step-by-Step" (be warned though, it starts off mostly simple but then makes a sudden and somewhat jarring leap forward). Try to implement a stack with "push" and "pop" monadic operations (use this as a starting point: http://brandon.si/code/the-state-monad-a-tutorial-for-the-co... but keep in mind it's much more important to WRITE the code, and play with it, than to try to understand how it's all working just via explanations).

For what it's worth, here's my ten cent explanation of monads:

A monad is interface for containers. A type which implements this interface must have two methods, `return` which inserts an object into a container, and `bind` which says what should happen when we use the value in one container to create a new container.

Re: Deconstructing Functional Programming [video]

#35

Post by Peaker »

catnaroek wrote: post #19
agentultra wrote: post #3

This is a brilliant talk. It's getting far too easy to annoy the FP cult(ure). As an aside, Scala is not unique in marrying a FP approach with an OO system. CL has had CLOS, IMO one of the better implementations of "OO" outside of Smalltalk, for much longer than Scala. Definitely watch this!

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.

Re: Deconstructing Functional Programming [video]

#36

Post by agentultra »

catnaroek wrote: post #19
agentultra wrote: post #3

This is a brilliant talk. It's getting far too easy to annoy the FP cult(ure). As an aside, Scala is not unique in marrying a FP approach with an OO system. CL has had CLOS, IMO one of the better implementations of "OO" outside of Smalltalk, for much longer than Scala. Definitely watch this!

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 rigorously defined term and is subject to interpretation. Which leads to bikeshedding over language features and a lot of hype.

I believe it also leads to a lot of misplaced faith in the purity and completeness of mathematics (it's almost as if the popular notion of FP is being reborn as a modern Principia Mathematica).

CL obviously cannot be called an, "FP," language since its inception seems to predate the popular notion of the term. Scala may suffer in the same way due to its reliance on the JVM and the expression semantics it has carried over from Java. However many of the features one tends to associate with modern FP languages (though not all) are present in both languages.

As for your aside, how so? Perhaps a discussion we can have over email if you're interested. You sound smart. However I don't understand your statement and would like to know more.

Re: Deconstructing Functional Programming [video]

#37

Post by Peaker »

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…

"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, I'd hope so! (Monoids aren't commutative). Does this mean it has a negation? No. So it is not "addition", why use a misleading name for the sake of some false sense of "intuition"?

The actual explanation of what a Monoid is precisely is so short and simple, it makes no sense to try to appeal to inaccurate intuitions.

Re: Deconstructing Functional Programming [video]

#38

Post by latk »

thinkpad20 wrote: post #26
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 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 overhead.

Re: Deconstructing Functional Programming [video]

#39

Post by thinkpad20 »

catnaroek wrote: post #24
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…

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).

Like I said, it's a scary term, because hearing the word "monoid" conveys exactly zilch about what it is, and it sounds strange and abstract. And like I said, the definition I gave is not a precise one, but it's an intuitive one. Once you have an intuitive understanding as a starting point, you can abstract to other things.

This is just my opinion, of course.

Re: Deconstructing Functional Programming [video]

#40

Post by Peaker »

sethev wrote: post #30
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…

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

This is a very valid critique, but I don't remember ever hearing that (except from Haskellers!)
Post reply on HN