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

81–90 of 116 posts

Re: Deconstructing Functional Programming [video]

#81

Post by Peaker »

agentultra wrote: post #55
catnaroek wrote: post #46

Earlier quoted context omitted.

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

I think the comparison to type classes is specious and ends there. They look similar but they tackle very different problems. You've actually explained why rather well. > Not really. The regulars in #haskell - now they are frigging smart. Don't sell yourself short.

It seems to me type classes have a superset of the features of CL multimethods. Why not compare them?

Re: Deconstructing Functional Programming [video]

#82

Post by Peaker »

catnaroek wrote: post #73
munificent wrote: post #68

Earlier quoted context omitted.

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

It is not syntactic sugar. It is one of two demonstrably equivalent ways to emulate functions of two arguments. The demonstrable equivalence comes from the equational theory of cartesian closed categories. The need to emulate functions of more than one variable comes from the fact that only functions of one variable are a native concept.

The word is encode, not emulate. Native support isn't any more concise, in fact it is more verbose when partial application is involved.

So why complicate the language with native support for a feature whose encoding on top of one argument functions is concise, elegant, and works well?

Re: Deconstructing Functional Programming [video]

#83

Post by Peaker »

Gilad Bracha sounds like he hasn't used a typed language long enough to stop struggling with basic type errors.

As such, it is of a position of extreme ignorance that he speaks of the uselessness of type checking and inference.

Claiming Smalltalk has the best closure syntax shows he doesn't understand call by need. Haskell defines easier to use control structures than Smalltalk.

Claiming patterns don't give exhaustiveness, ignoring their extra safety shows Gilad doesn't understand patterns.

Claiming monads are about particular instances having the two monad methods, when they are about abstracting over the interface, shows Gilad doesn't understand monads.

Claiming single argument functions have the inflexibility of identical Lego bricks shows he doesn't understand the richness of function types and combinators.

In short, Gilad sounds to me very much like a charlatan who'd benefit greatly from going through lyah.

Re: Deconstructing Functional Programming [video]

#84

Post by the_af »

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…

Indeed, I found his talk pretty poor as well. A lot of it comes down to not wanting to learn new terminology, and forgetting that a lot of "common sense" terminology from, say, Java, is also learned. I don't get more insight from "FlatMappable" than from "Monad"; in both cases I must learn about them first, and neither is intuitive without prior knowledge.

It is instructive to read Bracha's blog too, mostly for the comments where readers refute a lot of what he claims.

His argument against Hindley-Milner seems to be that "he hates it", and that type errors are sometimes hard to understand. It is true IMO that they are hard to understand (even though, like everything in programming, you get better with practice), but what is the alternative? Debugging runtime errors while on production?

He also presents Scala as a successful marriage between OOP and FP, but in reality this is a controversial issue. Some of the resistance to Scala (witnessed here in Hacker News, for example) is due to it trying to be a jack of all trades and master of none. Scala's syntax is arguably _harder to read_ than that of other FP languages.

Some of his "funny" remarks sounded mean-spirited to me. Nobody in his right mind claims that FP invented map or reduce, for example.

The only point of his talk I somewhat agree with is that language evangelists are annoying. Oh, and that "return" is poorly named.

Re: Deconstructing Functional Programming [video]

#85

Post by catnaroek »

Peaker wrote: post #82
catnaroek wrote: post #73

Earlier quoted context omitted.

It is not syntactic sugar. It is one of two demonstrably equivalent ways to emulate functions of two arguments. The demonstrable equivalence comes from the equational theory of cartesian closed categories. The need to emulate functions of more than one variable comes from the fact that only functions of one variable are a native concept.

The word is encode, not emulate. Native support isn't any more concise, in fact it is more verbose when partial application is involved. So why complicate the language with native support for a feature whose encoding on top of one argument functions is concise, elegant, and works well?

> Native support isn't any more concise, in fact it is more verbose when partial application is involved.

I only know too well. Everytime I write stuff like

    using std::placeholders;
    std::bind(foo, bar, _1, _2, baz, _3, _4);
I wish I were using an applicative language instead.

Re: Deconstructing Functional Programming [video]

#86

Post by taeric »

asdasf wrote: post #65
taeric wrote: post #61

Earlier quoted context omitted.

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.

I should have put a smiley on that, then. While feeling trolled, I highly suspect this is just a rather amusing case of poor communication.

At no point was I trying to describe or discuss monads. That is something a response to me thought I was trying to do. When referring to "simulating" a system, I was referring to where the video refers to the process of reading "dead code" in a text editor. There is a large rant on monads in the video where the argument appears to be that the problem is strictly with the name. The reason given that it takes something understood, and hides it behind non-obvious names. I extrapolated this to be that it makes the program and the idea "hard to simulate" for the coder reading the code.

Re: Deconstructing Functional Programming [video]

#87

Post by the_af »

bunderbunder wrote: post #66

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

I'd say static typing and purity as advocated by FP are some of the tools one wants when trying to engineer larger, more complex systems.

I wasn't familiar with the Mars Climate Orbiter case, but a cursory reading suggests one of the causes was a type error (confusing newtons with pound-force).

Re: Deconstructing Functional Programming [video]

#88

Post by codygman »

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…

> all things are good in moderation

What about poison? Rabies? Rabies in moderation actually sounds quite appealing.

Re: Deconstructing Functional Programming [video]

#89

Post by platz »

thinkpad20 wrote: post #34
[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 wo…

The container analogy does break down in some instances. For example, using monads to model a workflow. I've come to accept 'Computational Context' as the best descriptor so far.

Re: Deconstructing Functional Programming [video]

#90

Post by platz »

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…

probably because 'mappend' was defined while thinking about usage for lists, but is hardly appropriate for the general case. So, 'Appending' 5 to 3 gives 8; it could be better.
Post reply on HN