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

51–60 of 116 posts

Re: Deconstructing Functional Programming [video]

#51

Post by groovy2shoes »

thinkpad20 wrote: post #39
catnaroek wrote: post #24

Earlier quoted context omitted.

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.

Hearing the word "dog" conveys exactly zilch about what it is, and it sounds strange and abstract. Maybe we should call these animals "barkables".

Re: Deconstructing Functional Programming [video]

#52

Post by Peaker »

thinkpad20 wrote: post #44
Peaker wrote: post #37

Earlier quoted context omitted.

"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've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary.

Monad is simple and hard, but Monoid is simple and easy.

Re: Deconstructing Functional Programming [video]

#53

Post by thinkpad20 »

groovy2shoes wrote: post #51
thinkpad20 wrote: post #39

Earlier quoted context omitted.

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.

Hearing the word "dog" conveys exactly zilch about what it is, and it sounds strange and abstract. Maybe we should call these animals "barkables".

Except that it doesn't sound strange and abstract, because it's a word that everyone is familiar with. My point is about accessibility, not theoretical correctness.

Re: Deconstructing Functional Programming [video]

#54

Post by thinkpad20 »

Peaker wrote: post #52
thinkpad20 wrote: post #44

Earlier quoted context omitted.

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've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary. Monad is simple and hard, but Monoid is simple and easy.

With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematically inclined to write articles explaining how "actually, what we call the Joinable type class is known in abstract algebra as a Monoid, and its use extends beyond just joining things; for example..."

My point isn't really specifically about monoids; they're just an example of what often goes on in Haskell, which is that people put theory before practicality and mathematical (and hence often esoteric) definitions before practical, real-world definitions. Like I've said a few times, this isn't incorrect at all. Nor is it surprising given Haskell's origins, nor is it without purpose since it deepens your understanding of what's going on in the language. It's just a simple fact that the mathematical jargon is a turn-off to newcomers and those who don't feel they want to be forced to learn math while they're programming, or might think they're incapable of doing so.

As it turns out, I'm not one of those people; I love the mathematical side of Haskell and I love that I've learned what a Monoid is and developed an interest in type theory, category theory and all kinds of other things. But not everyone is like that, and that's the point I'm making.

Re: Deconstructing Functional Programming [video]

#55

Post by agentultra »

catnaroek wrote: post #46
agentultra wrote: post #36

Earlier quoted context omitted.

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

Re: Deconstructing Functional Programming [video]

#56

Post by asdasf »

taeric wrote: post #45
catnaroek wrote: post #17

Earlier quoted context omitted.

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

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

But none of that has anything to do with monads.

Re: Deconstructing Functional Programming [video]

#57

Post by asdasf »

thinkpad20 wrote: post #54
Peaker wrote: post #52

Earlier quoted context omitted.

I've learned Monoid in Haskell, not maths. It's just so simple and easy that there's really no dumbing down necessary. Monad is simple and hard, but Monoid is simple and easy.

With respect to monoid, you're right. It's really quite simple when you get down to it. I don't have any arguments there. In fact, the fact that monoids are really so simple is kind of my point. In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use; it would be the purview of the mathematica…

>In almost any other language, were such a thing to exist, monoids would not be called monoids but by some descriptive term which conveyed an intuitive sense of their meaning and use

There is no such term, that is the point. Offering up misleading terms that do not convey a sense of their meaning is much worse than a word that is unfamiliar.

>My point isn't really specifically about monoids; they're just an example of what often goes on in Haskell, which is that people put theory before practicality and mathematical (and hence often esoteric) definitions before practical, real-world definitions.

But it isn't an example of that. It is quite bizarre to see people insist that this goes on, and give examples that do not support that claim, while being fully convinced in their proof.

>As it turns out, I'm not one of those people; I love the mathematical side of Haskell and I love that I've learned what a Monoid is and developed an interest in type theory, category theory and all kinds of other things. But not everyone is like that, and that's the point I'm making.

You don't need to be like that, that is the point we're making. I am not a math person. I am not a CS person. I am a high school drop out who taught himself to code in PHP and C. I learned haskell just fine. I learned monoids and functors and monads just fine. I am no more mathematically inclined now than I was before. I know nothing of category theory, and care nothing of it. They are very general abstractions that do not reflect a narrow, specific use case, and thus do not benefit from a word that describes some narrow, specific use case.

Re: Deconstructing Functional Programming [video]

#58

Post by [deleted] »

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…

[deleted]

Re: Deconstructing Functional Programming [video]

#59

Post by gnuvince »

thinkpad20 wrote: post #39
catnaroek wrote: post #24

Earlier quoted context omitted.

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.

Most of what you learn in CS is a bunch of words you have no idea what they mean until someone gives you a precise definition. Deterministic Finite Automata, regular expression, static typing, serialization, compilation, singleton pattern, etc. are all terms we use every day in our profession, but it's not clear what they mean. But we read the definition, forget it, someone reminds us, we forget it again, we implement it and we remember. Same with monoids, functors or monads, we need to take some time to learn what they mean and then we can include them in our vocabulary.

Re: Deconstructing Functional Programming [video]

#60

Post by groovy2shoes »

thinkpad20 wrote: post #53
groovy2shoes wrote: post #51

Earlier quoted context omitted.

Hearing the word "dog" conveys exactly zilch about what it is, and it sounds strange and abstract. Maybe we should call these animals "barkables".

Except that it doesn't sound strange and abstract, because it's a word that everyone is familiar with. My point is about accessibility, not theoretical correctness.

My point is that a monoid is a monoid. It's an abstraction that's so basic that it cannot be broken down. It's a concept that you learn, like how you learn what a dog is or what integers, loops, functions, sets, hashmaps, etc are.

A very large part of our job is to apply abstractions. I don't often hear lawyers complaining about how accessible the name of some law is, or from doctors about how accessible the name of some disease is. I've never heard an American football player say "We should call the pistol formation something else. Calling it pistol is potentially confusing". They just learn what a pistol formation is and carry on.

As programmers, abstraction is a very large part of our job. We owe it to ourselves to learn the basics and to improve our abilities with respect to our craft, even though sometimes it's hard.

Post reply on HN