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

101–110 of 116 posts

Re: Deconstructing Functional Programming [video]

#101

Post by latk »

codygman wrote: post #88
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…

> all things are good in moderation What about poison? Rabies? Rabies in moderation actually sounds quite appealing.

Two words: medicines and vaccines. Of everything there is a “too little” and a “too much”, which is especially true with programming paradigms. Some people write procedural code where OOP should be used, others abuse OOP for something that should have been done in a functional manner, and sometimes functional programs should rather be expressed with procedural code.

Re: Deconstructing Functional Programming [video]

#102

Post by bunderbunder »

the_af wrote: post #87
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).

As advocated widely in the FP blogosphere. . . not necessarily as commonly practiced in FP programming culture, or supported by many FP languages.

For example, I strongly prefer F# to its cousin OCaml largely because F# uses nominal typing and OCaml uses structural typing. I've also got some misgivings about being overly reliant on type inference. Both structural typing and advanced type inference are admittedly incredibly convenient. What worries me is that they also seem to be incredibly convenient as ways to obfuscate the programmer's intent w/r/t types and their semantics.

Re: Deconstructing Functional Programming [video]

#103

Post by pacala »

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…

> explaining it further as "something with an identity and an associative operation" really doesn't help much either

My 3rd grade daughter learns about associativity and identity. Is it too much to expect adults to not get all defensive over 3rd grade terminology?

Re: Deconstructing Functional Programming [video]

#104

Post by vitd »

I'm just learning functional programming with Haskell, and it was great to hear him explain that learning Haskell is really hard because of the terminology. I feel a little (just a little) less stupid.

That said, he's a terrible presenter. His smarmy style was really off-putting, and his motives a little sketchy. He spends a good portion of the talk slamming just about every language in existence except for the two he works on (Dart and Newspeak). It seemed very disingenuous and I don't need another ranting nerd spouting venom about why something's not very good in that holier-than-thou tone. I would have rather had a straightforward talk showing the strengths and weaknesses than the bitter tone this had.

Re: Deconstructing Functional Programming [video]

#105

Post by the_af »

bunderbunder wrote: post #102
the_af wrote: post #87

Earlier quoted context omitted.

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

As advocated widely in the FP blogosphere. . . not necessarily as commonly practiced in FP programming culture, or supported by many FP languages. For example, I strongly prefer F# to its cousin OCaml largely because F# uses nominal typing and OCaml uses structural typing. I've also got some misgivings about being overly reliant on type inference. Both structural typing and advanced type inference are admittedly incr…

I'd say not so much as advocated by the blogosphere (which can be annoying, as fans of almost anything often are), but by the people actually designing and using FP languages.

In any case, there is certainly valid criticism of FP, but Bracha's just isn't it. My impression is that the guy -- as clever as he may be in other areas -- barely understands FP, and makes disparaging remarks about things he isn't familiar with. Read his blog; every assertion he makes is shown to be incorrect or misleading by people who do understand FP, like Tony Morris or (very politely) Philip Wadler himself.

Re: Deconstructing Functional Programming [video]

#106

Post by judk »

platz wrote: post #90
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…

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.

The choices are to either abuse an existing word, or make up new one (possibly a homograph).

What is '+' ? Addition? Modular addition? Logical OR? Concatenaton? Sometimes, any of these.

There where always be more concepts than distinct labels, since the space of concept is exponential combination (power set) of words.

Re: Deconstructing Functional Programming [video]

#107

Post by tel »

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…

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" monoid (they have many others, too, see this entire paper http://www.cis.upenn.edu/~byorgey/pub/monoid-pearl.pdf). It's also easy to construct monoids which don't have any spatial sense at all like set union.

Re: Deconstructing Functional Programming [video]

#108

Post by platz »

judk wrote: post #106
platz wrote: post #90

Earlier quoted context omitted.

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.

The choices are to either abuse an existing word, or make up new one (possibly a homograph). What is '+' ? Addition? Modular addition? Logical OR? Concatenaton? Sometimes, any of these. There where always be more concepts than distinct labels, since the space of concept is exponential combination (power set) of words.

I didn't say it had to be plus.

I don't have the perfect answer, but append certainly seems like choosing a specific concept , rather than trying to come up with a more general name.

Re: Deconstructing Functional Programming [video]

#109

Post by [deleted] »

mafribe wrote: post #100
newgame wrote: post #99

Earlier quoted context omitted.

> 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 pointed out that a more nominal type system is a solution. Because when you give meaningful…

Most programming languages with Damas-Hindley-Milner do not prevent you from using explicit type annotation, and inventing semantically meaningful type names. More importantly, I think the reason why error messages are sparse and not meaningful in languages with Damas-Hindley-Milner is that nobody bothered to improve the situation. And the reason why nobody botheres is that it's simply not a problem in practise. Any…

[deleted]

Re: Deconstructing Functional Programming [video]

#110

Post by judk »

jejones3141 wrote: post #92
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…

Isaac Asimov, in one of his essays, gave an analogy for those unfamiliar with, or perhaps frightened by the scary name of, the "complex" numbers: street addresses. Should programming languages get rid of that scary name and refer to complex numbers as "addressable"?

Hence why Monads have been named "Warm Fuzzy Things" in some Haskell papers about outreach.
Post reply on HN