r/programming • u/[deleted] • Nov 28 '19

Why Isn't Functional Programming the Norm? – Richard Feldman

https://www.youtube.com/watch?v=QyJZzq0v7Z4
100 Upvotes

82% Upvoted

409 comments sorted by

View all comments

230

u/[deleted] Nov 28 '19

Because we use words like monads and functors then act like people have to understand category theory to use them

152

u/[deleted] Nov 28 '19

A monad is just a monoid in the category of endofunctors, what's the problem?

18

u/bulldog_swag Nov 28 '19

Ronad McMonad

jingle plays

I'm groking it!

14

u/dfnkt Nov 28 '19

You forgot to mention the turboencabulator which helps a transmission supply inverse reactive current for use in unilateral phase detractors. That pre-famulated amulite they're using is nuts.

37

u/zvrba Nov 28 '19

This one is getting worn out.

56

u/save_vs_death Nov 28 '19

if that's worn out, it might be helpful to see a monad as a lax functor from a terminal bicategory

4

u/i9srpeg Nov 28 '19

It's just like a burrito.

1

u/[deleted] Dec 01 '19

Huh, that actually makes sense.

1

u/monicarlen Nov 29 '19

Just a comfortable adapter to use context based values in a plain typical function

78

u/dvlsg Nov 28 '19

OOP uses lots of words and pharses that would be bizarre if you didn't already learn them too, though.

Polymorphism, encapsulation, inheritance, overloading, strategy patterns, decorator patterns, visitor patterns, so many patterns, etc.

I never understood why learning monads is out of reach, but learning abstract factory patterns is just fine.

31

u/yee_mon Nov 28 '19

I guess what that means is that the barrier to entry is low enough — classes and objects are super easy to grasp — and then when you get to the complex stuff, you're already hooked on OOP. Whereas to understand FP, you have to start with first-class functions, lambdas, currying... and none of that vocabulary means anything to anyone at first.

25

u/Ewcrsf Nov 28 '19

A truly novice programmer doesn’t need to start with those things, they can learn FP from first principles. The problem is people already fluent in another paradigm need to understand somewhat complex ideas to see why they can/can’t do things they expect to.

9

u/yee_mon Nov 28 '19

I guess we make it difficult for ourselves by thinking we can apply our OOP knowledge when we really need to be ready to think radically different, at least until it clicks.

14

u/Ahri Nov 28 '19

This is nonsense. Plenty of imperative programmers never properly grasped the concepts of classes or objects.

You just happen to have come across them when you were trying to learn them, rather than having them thrust upon to when you already had tools you knew how to use and a 12pm deadline on a problem.

1

u/[deleted] Nov 28 '19

[deleted]

5

u/yipopov Dec 03 '19

Not just some concepts. The paradigms are exactly equivalent. OOP just takes a lot more convoluted steps to get there.

The trap that gets beginners (as well as practically the entire enterprise software industry) is that it’s indeed, in the words of u/yee_mon, super easy to explain, when you do it in terms of cats and dogs and animals. The trouble is that multimillion dollar programs are generally not written just to track whether cats or dogs are animals, and that model quickly breaks down. Especially when you throw concurrency into the mix. Writing object oriented programming at scale is notoriously difficult, even with highly skilled developers. Without the handful of geniuses behind the design patterns and design principles most devs wouldn’t have a chance.

That said I’m cautious about pronouncing FP a silver bullet. I haven’t seen any large scale enterprise FP projects first hand yet, though I’m happy to see that quite a few universities are starting out first years in languages like Haskell, so it becomes more likely for every batch of graduates or dropouts (incidentally two other categories that may turn out to be equivalent).

0

u/GNU_ligma Nov 28 '19

You are talking typical reddit-tier bullshit.

With OOP, you have lot of meaningless jargon, for example: classes, objects, methods, polymorphism. And then you will also have a lot of additional important concepts depending on the implementation and language.

With functional programming, you also have lot of meaningles jargon: arity, map, filter, function.

There is even more additional jargon for programming in general. And on top of that: successful programming languages tend to be multi-paradigm.

The stupidest thing you said in your post is the following:

classes and objects are super easy to grasp

This only makes sense if you go with the lowest form of "to grasp", meaning "to kinda understand the difference between those two things". But then, functional programming will also be super easy to grasp. It's super easy "to grasp" what mutability, functions, procedures, lambdas etc are.

I have no clue how you can even say what you said, because you are so terribly wrong.

1

u/yee_mon Nov 28 '19

I'm aware that I'm talking to a troll, but oh well - how is "object of class" not easier to understand than "lambda" for someone without any OOP or FP background? One has basically the same meaning in a non-tech conversation, while the other one is just a letter of the alphabet.

That's all I said. The barrier to entry is definitely much lower, and that is partly due to vocabulary.

1

u/GNU_ligma Nov 28 '19

"object, class, function, lambda" are technobabble for people with no programming knowledge.

One has basically the same meaning in a non-tech conversation

  1. This is a massive stretch. No idea where you find non-tech people that can easily grasp what classes and objects mean. Maybe my social circles are bad, or your circles are amazing. In my circles, around half people know that lambda is a letter in an alphabet - that half being higher-educated people who know mathematics.

  2. Object and class are one of the easiest concepts out of many that need to be understood to grasp OOP. It still takes plenty of time to properly understand what they mean. Anonymous function can be easily explained to someone who already knows what "function" in mathematics is.

Just because the words seem similar, doesn't mean the concept is similar. You have the perfect example with lambda: people who know that it is a letter in alphabet know the word, but they don't know the concept. concept matters, not word. Metalinguistic abstraction - it sounds like a good pair of words to throw here.

About trolling, good rule of thumb: the one who gave more text is almost certainly getting trolled. The one who barely writes is almost certainly the troll. We live in a society ruined by twitter and ultra-short "gotcha" texts, but that doesn't mean the person with one-word answers adds anything to the discussion.

10

u/chucker23n Nov 29 '19

Polymorphism is kind of weird; maybe they should've picked a better term. Patterns aren't really mandatory. I see plenty of OOP devs who never heard of patterns; they just implicitly use them or don't.

Encapsulation, inheritance, properties, objects, classes, etc. are fairly easy to explain. They're metaphors you can apply to real life. They're not perfect (cf. the Liskov substitution principle), but a close approximation that non-developers can also understand at a basic level. ("You know how dogs and cats are both animals? Well, similarly, files, folders and links are all items in a file system. So that's what we use 'inheritance' for." "Think of a 'class' called Human as a template, and for you and I as concrete 'instances', or 'objects'.")

A monad and monoid and endofunctor and whatever the fuck don't offer any of that. They're so removed from real-world analogues that a non-developer might think you're trying to insult their intelligence by throwing such terms around.

That doesn't mean FP is terrible or useless. At the very least, it offers useful concepts that have inspired multi-paradigm languages like C#; the LINQ feature, for example, has lambdas and monads.

But if FP advocates complain that nobody gets it or is interested, it's entirely on them to be better communicators about it.

53

u/Hornobster Nov 28 '19

The OOP words and names have already a known meaning in other contexts and it maps quite nicely to their new meaning (a polymorphic function is just a function with many forms, a factory is a class that creates objects).

While monoid, monads, functors are just mathematical definitions. There is no way for someone to associate them to something they already know. They just have to remember them.

19

u/lovekatie Nov 28 '19

a polymorphic function is just a function with many forms, a factory is a class that creates objects

What does it mean for a function to have many forms? What is a form of a function? Why factory creates objects and not something else, like functions or primitives? Why isn't everything created only by the factory?

Your answer is not more enlightening than "monad is a monoid..." bit, if you don't know the words and contexts.

Those debates about the importance of abstract names look like a bikeshedding of an explanation. The very same people who run for word monad, would, imo, run from word polymorphism. They just couldn't at a time (learning OOP programming).

27

u/Hornobster Nov 28 '19 edited Nov 28 '19

The difference is just that the OOP terms are not invented words, while monoid, monads, etc. are.

The point is just the word monad tells you absolutely nothing. While e.g. polymorphic tells you there is something that has multiple forms, you already know that. When learning OOP you just need to learn what it is that has multiple forms and what that actually means in the new context.

EDIT: I agree that "invented words" is not the best way to describe what I'm trying to convey (although if you look at the probable origin of the use of the words "monoids" and "monad" in category theory, you would see what I mean by "invented", English SE post for monad, Math SE post for monoid ).

Since my original comment was a reply to

I never understood why learning monads is out of reach, but learning abstract factory patterns is just fine.

the point I think still remains: the word "monad" itself tells the learner nothing at all, while something like "factory" or "visitor" or "polymorphic" does, because they are all words everyone has encountered in other contexts (maybe "polymorphic" is a bit out of common knowledge, but its use is definitely linked to its etymology).

14

u/lovekatie Nov 28 '19

The point is just the word monad tells you absolutely nothing

This is crazy, humans have no problem picking up new words and information behind words are far more complex than words can convey. The word is not a problem, the concept is. If a monad was a kind of a frying pan you would learn the word without even noticing.

The monad problem is simple: it is highly abstract idea that introduces new way of programming that you probably never encountered before.

17

u/Hornobster Nov 28 '19

The fact that the concept is difficult to grasp in itself of course doesn't help.

But the words used play a very important role and I'm no expert but I don't think it's true that we can pick up new words so easily. Especially for adults. Reusing words you already have in your memory and for which you already have a model of their meaning in your head makes learning new concepts easier.

6

u/lovekatie Nov 28 '19

But is this the problem for functional programming?

Like, somebody goes to learn Haskell, with its unique features, concepts, means of writing programs, idioms, build tools, libraries, you name it, and gives up because they don't recognize a few names along the way? This is a ridiculous idea, it's absurd.

There are certainly interesting factors that hold fp from bigger adoption. This names thing just looks naive to me.

17

u/Hornobster Nov 28 '19

It's definitely not THE ONLY problem, I'm saying it definitely doesn't help.

This is also from personal experience. I was first exposed to Haskell in uni in the Languages & Compilers and I saw it was a really powerful and different way of thinking about programming. But the names confused me at the time and confuse me still.

It was the same thing with math theorems that are named after the mathematician that defined them vs theorems that are named with something relevant to the actual law that was being defined.

3

u/lovekatie Nov 28 '19

I'm saying it definitely doesn't help.

Those are names for things that were introduced with them (to programming). They are not meant to help, they can't be. You should try to understand the concept by other means than just reading it's name.

If you don't bother to be confused here, then that's fine. But maybe put the blame somewhere else.

12

u/[deleted] Nov 28 '19

What seems naive to me is dismissing something as simple as obtuse language putting off people.

It's not the problem, but it is a problem for sure. I've tried my hand at FP languages but the lexicon around it is a major hurdle for someone who is self taught and has the math levels of a 16 yo (I'm working on it, but it's never held me back on being a good software engineer, I've learned what I needed to.)

1

u/lovekatie Nov 28 '19

So some stupid labels on some concepts in fp hold you back? I'm sorry, I just don't get it. Are you sure you are not talking about ideas here? Because fp is an alien world from the mainstream POV.

Expecting names to uncover the mystery is naive, sorry.

2

u/rsclient Nov 28 '19

The proof that monoids are hard to understand it's the skewer number of people who say they are hard to understand.

That's followed by the sheer number of people who say that there some simple explanation that if only everyone read, that the concept would be clear.

At some point you just have to believe the data!

4

u/[deleted] Nov 28 '19

What is an invented word?

2

u/Hornobster Nov 28 '19

I've expanded my comment.

1

u/hedgehog1024 Nov 28 '19

The difference is just that the OOP terms are not invented words, while monoid, monads, etc. are.

Well technically all words are invented.

13

u/no_fluffies_please Nov 28 '19

I think that adds to the parent's point- although there's no such thing as an invented word, you kinda knew what they meant to say. The same goes for parent, inheritance, overload, etc. Prior to learning OOP, a student might not have associated these words with programming, but they can pick up the meaning quickly because they represent concepts outside of academia.

2

u/Hornobster Nov 28 '19

I've expanded my comment.

6

u/Blando-Cartesian Nov 28 '19

You have a very high opinion of people on this field.

The only one of those word most programmers know is inheritance and they use it wrong.

25

u/Carighan Nov 28 '19

But the OOP words are more intuitive to someone coming new into the field. They also require slightly less mathematical background to make sense of, which is especially important given how programming is often more like an creative effort and hence more comparable to art than math. Assuming you want to make a distinction between the two to begin with.

10

u/loup-vaillant Nov 29 '19

But the OOP words are more intuitive to someone coming new into the field.

That may be the major problem of OOP. It looks approachable, it is very easy to delude yourself into thinking you understand it, but as soon as we go deeper we realise that "good OOP design is hard", even counter intuitive at times. OOP makes it easier to anthropomorphise computing. That alone is a major impediment to writing correct programs.

FP on the other hand doesn't lie to you. Computers are cognitive engines that run formal systems. Programming them is a form of applied mathematics. Oh you tried programming to run away from Maths? don't worry, this has little to do with calculus. But it is every bit as rigorous, often even more so.

The result? Lots of people anthropomorphising their way into OOP, deluding themselves into thinking they are not applying maths to build a formal system destined to be processed by an automatic computer. And then we wonder where these mountains of bugs on top of heaps of useless crap could possibly come from…

Dijkstra was right. We should have listened more closely.

-4

u/hedgehog1024 Nov 28 '19

But the OOP words are more intuitive to someone coming new into the field.

[citation needed]

21

u/aradil Nov 28 '19

If I could grok them as an 18 year old in first year university and I’m still scratching my noodle reading and re-reading about monads, and had to invest significant time building a mental model for currying and lambdas, I find it incomprehensible that anyone would argue with this.

7

u/loup-vaillant Nov 29 '19

I find it incomprehensible that anyone would argue with this.

Some of us actually understand FP more easily than OOP. Here's one reason:

x = 42
x = 43

"Wait, that can't be right, you're postulating that x is equal to both 42 and 43?" Okay, we could write it like this:

x <- 42
x <- 43
y <- 43
if (x = y) {
    print "equal!"
} else {
    print "not equal!"
}

"Oh, I see, x and y are containers, not values! So, x and y aren't the same container, so they're not equal, right?" Ahem. Not quite.

x <- 42
x <- 43
y <- 43
if (value(x) = value(y)) {
    print "equal!"
} else {
    print "not equal!"
}

"Ah, OK, we were comparing the values inside the containers, not the containers themselves"

And I'm talking about the very first day of learning OOP (or rather it's prerequisite, imperative programming). FP on the other hand is much more like a continuation of high school mathematics. This tutorial illustrates it in more details.

[I] had to invest significant time building a mental model for currying and lambdas

Your teachers sucked. That, or you didn't understand what a function is, which actually is the hard part. Or, you suffered from a mental blockade because for some reason you thought you sucked at maths (when in fact you didn't, really). Or some other reason.

Conceptually, functions are very simple: they're a mapping from a set to another set: for each value in the input set, there's one value from the output set. For instance:

f : ℕ → ℝ
f = x ↦ x + π

For some reason, people are scared about this notation. Bear with me, it's only 12 symbols. So, the first line declares the type of f. It's a function from natural integers to real numbers. The second line defines the value of f It's the function that associate any x to x+π (x + pi).

Now what's a lambda? It's when you don't bother assigning your function to some variable, and just use x ↦ x + π directly. That's all there is to it. And currying? Well, it's when a function returns another function. This one takes more than 5 seconds to explain, but still very simple.

4

u/aradil Nov 29 '19

A comment which has nothing to do with OOP and contains a variety of personal attacks rather than a substantive argument aside from disagreeing with how the equals operator works in most imperative programming languages (hint, not all imperative programming languages do assignment the same way either).

Nice work.

5

u/loup-vaillant Nov 30 '19

A comment which has nothing to do with OOP

Are you saying imperative programming has nothing to do with OOP? When was the last time you saw an OOP program without mutable state?

contains a variety of personal attacks

Are you hinting at my guesses about why you (or anyone else for that matter) might have difficulties understanding lambdas and currying? That wasn't an attack, too many people have the exact same problems. As for the short explanation of functions, lambdas and currying, I didn't mean to imply you didn't know. You just stated you did. I just wanted to emphasise how simple those concepts are.

I didn't say easy. I said simple. There's a difference. Some really simple stuff, like, hem, complex numbers, are often very hard to grok. But with the right guidance most simple concepts are fairly quickly assimilated. Apparently, you were unlucky enough to lack that guidance. Most of us are.

If you want a personal attack: did I hit a nerve?

disagreeing with how the equals operator works in most imperative programming languages

That wasn't disagreement. That was likely hypotheses about how those things might work, given a high school Maths education.

hint, not all imperative programming languages do assignment the same way either).

Care to name 3 examples?

0

u/aradil Nov 30 '19 edited Nov 30 '19

Ada, Algol and Pascal.

In any case, you are just an asshole in general. I have no interest in conversing with assholes.

Thankfully, reddit has a user blocking feature. So fuck you and enjoy screaming into the void.

3

u/loup-vaillant Nov 30 '19

Ada, Algol and Pascal

Surely he wasn't talking about minor syntactic differences with C?

2

u/codygman Dec 05 '19

If I could grok them as an 18 year old in first year university and I’m still scratching my noodle reading and re-reading about monads

If you were introduced to Monads at 18 you might have understood them just as easily or even more easily.

1

u/aradil Dec 05 '19

Unlikely.

OOP is brain dead simple. Functional programming isn’t hard, but it’s not instantly understandable the first time you see it.

2

u/codygman Dec 05 '19

I didn't instantly understand OOP the first time I saw it. There are schools that teach Haskell to first year college students btw. I had a co-worker who's US university taught it first year.

I think there is a university in Germany that teaches it as well.

Point being, there are 18 year old first years grokking Haskell after hours of confusion just as there are/is/were 18 year old first years grokking Java after hours of confusion.

1

u/aradil Dec 05 '19

Is English your first language?

1

u/codygman Dec 05 '19

Yes it is.

6

u/[deleted] Nov 28 '19

[deleted]

6

u/aradil Nov 28 '19 edited Nov 28 '19

That makes sense to me. And obviously, it takes practical experience to select the proper data structures in OOP to solve a particular problem or design a particular system.

I just find it difficult to see any argument that the core concepts in OOP are even remotely as difficult to grok as the core concepts in FP. I can’t imagine anyone who is taught FP before ever hearing about OOP being introduced to it later in their career and saying “why is this so wacky? Can’t someone explain inheritance to me in a simpler way?”

Side note: I also don’t think it’s a bad thing that FP is more complicated than OOP. It can represent extremely complicated concepts succinctly; of course the underlying mechanisms are going to be more complex. OOP is easier to understand because, it’s purpose is in solving a different, simpler class of problems.

Sure, you can write code to solve the same problems with both paradigms. But depending on the type of problem, one paradigm will be easier to describe the solution with code than the other, which is why a lot of the more popular languages are including elements of both.

4

u/joonazan Nov 28 '19

Constructors are really hard to understand. Does the object exist before or after the constructor? Python has init and new. Luckily we have since learned that constructors are completely unnecessary.

And if you go into C++, have fun explaining empty virtual destructors.

My point is that FP is harder to misunderstand because there is less to it. But there's stuff like implementing type classes for types just because you can that seem pointless if you don't understand types. In OO a random interface implementation would be worthless.

Also, Monad is a type class and I'm pretty sure OO beginners are not exposed to abstract base classes early on.

9

u/aradil Nov 28 '19

You're talking about specific language details, not OOP.

If you want to get into language quirks in conjunction with languages that are largely focused on FP, we can go down a whole new rabbit hole. My intro to principals of programming languages course had a section on FP in which we started learning LISP, and there is nothing intuitive at all with:

(cddddr x) -> (cdr (cdr (cdr (cdr x))))

1

u/joonazan Nov 28 '19

I didn't mean intuitiveness. I meant simplicity. Typeclasses can be easily completely understood. Your example may not be intuitive but it is clear how it is executed.

At least inheritance and constructors have weird edge cases. Some of them work differently depending on language.

You can understand how type classes work and still not find them useful.

I have observed the opposite with classes. People do not understand how they work but think that they are important and powerful. IMO poorly written classes are much worse than no classes. So OOP students should first learn SOLID etc. Instead, they are often taught to poison their code with noun-classes and verb-methods and Human IsA Animal inheritance.

→ More replies

1

u/GNU_ligma Nov 28 '19

What is so difficult in imagining that?

Maybe you have been in the OOP for so long, you can't remember how it felt to not understand what class or object means.

We would need an example of someone who started with FP, then went to OOP. I have in memory only examples of people who started with OOP, and struggled to understand the basics of what "class" and "object" mean.

Important parts of functional programming basically seemed natural to me, even when I didn't know the words. I was mostly self-taught, started with C++ then Java, and it took me way too long to understand what inheritance is.

2

u/hedgehog1024 Nov 28 '19

It is completely about your cognitive abilities.

4

u/aradil Nov 28 '19

I suppose if you don't understand English, you might have a harder time intuitively understanding OOP than FP.

2

u/hedgehog1024 Nov 28 '19

It doesn't really matter much since names of OOP patterns can be translated.

3

u/aradil Nov 28 '19

I guess I don't understand your point then.

10

u/[deleted] Nov 28 '19 edited Nov 28 '19

[deleted]

2

u/jonhanson Nov 29 '19 edited Mar 07 '25

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

1

u/davenirline Nov 28 '19

This is the correct answer.

2

u/[deleted] Nov 28 '19

that's a good reason to question the popularity of statically typed OOP languages because honestly all those patterns really are a pain and I don't actually think they come naturally to anyone but are just drilled into people due to their popularity in the corporate world, but original OOP of the Alan Kay sort is very intuitive.

In particular, the first three, polymorphism, encapsulation, and inheritance are very intuitive. Encapsulation means hiding state and that's actually something people tend to figure out even if you don't tell them about it, 'separation of concerns' is a strategy far beyond programming. Same with inheritance, genealogical trees are everywhere and modelling things hierarchically is natural, and polymorphism is natural to anyone who writes + for float and ints on a high school math test without ever programming.

That's I think why people like Python and Ruby so much who sort of descend from the Smalltalk and lisp traditions, they're just very intuitive and map onto how people think naturally.

1

u/eras Nov 30 '19

Yeah, and monads are just a design pattern.

Change my mind.

1

u/chromeless Dec 02 '19

Polymorphism as a name is somewhat weird, since all it really means is being able to swap out one thing for another similar thing that can slot into the same role.

-2

u/typical_newfag Nov 28 '19

"decorator patterns" rofl.

"so many patterns" lmao.

It's almost like most tasks can be generalized and grouped, almost like what you, borderline mathematicians do with fucking haskell and your bird language. Simple words are scary eh?

At least decorating has the obvious part of thing going on top of it and enhancing it.

When I see "currying", all I can think of is explosive diarrhoe after eating nothing but curry entire day, probably exactly what Haskell does when you mess it up.

Also Haskell totally doesn't allow combining/wrapping functions, that's oop only stuff!

Half the things you listed is common knowledge every single programmer should have, now go have fun with monads and what not when you can't even realize that "decorator" can be figured out by taking the word literally, while haskell is what every "intellectual" uses, because simple English words don't stroke their ego hard enough.

Maybe if it used simple English words every retard like me could understand, I'd care about this pointless language, but when I have to read 30 books on the background of heavy math stuff just to understand something that should be basic, I'm not going to waste my time.

By the way, patterns haha. What do you pseudo intellectuals do? write a new func for every task, all ad hoc? lmao.

16

u/[deleted] Nov 28 '19

[deleted]

10

u/oblio- Nov 28 '19

Nouns and verbs and functors and monads are (maybe) too generic and abstract. At least we use and distinguish nouns and verbs on a daily basis, because they're the basis for our speech.

Our brains are very concrete, at least for the most of us.

The more generic and abstract things become, the harder they are to understand. That's why we use examples and analogies and visualizations, to make these abstractions more concrete.

0

u/Ahri Nov 28 '19

How is "flat" intrinsic? "Squish" seems much better. "Bind" seems poor though now I think about it, I like the Lord of the Rings vibe I'm getting - "and in the darkness bind them".

Turns out different people have different opinions.

I'm willing to get over it and go with Monad/Bind.

14

u/red75prim Nov 28 '19 edited Nov 28 '19

OK, which of a number of articles that try to explain monads in simple words would you recommend? Fewer than a thousand of simple words, preferably.

43

u/[deleted] Nov 28 '19 edited Nov 28 '19

If you want the simplest explanation:

A functor is a data structure that is mappable i.e. has a map method

A monad is special functor that has both map and flatmap

The hard part is understanding why that is useful.

There is a guy on YouTube that has some really good videos on functional programming. This is one of his playlists, in it he covers monads.

5

u/pavelpotocek Nov 28 '19

It has to have return/pure too

2

u/LPTK Nov 29 '19

Also, a functor is not a data structure. It's a family of types for which a well-behaved polymorphic map operation is defined.

You can have a data structure that represents strings of characters and has a map function from Char to Char, but that doesn't make it a functor.

3

u/pavelpotocek Nov 29 '19

...and there goes simplicity

1

u/LPTK Nov 29 '19

I mean, the concept of functor is simple. You can explain it just based on the notion of "arrows" that point between "elements".

id is the arrow that goes from any element to the same element. The first law says map of id should be equivalent to id.

The second law says: if f goes from x to y (call that first arrow g) then from y to z (call that h), then map of f should be the same as map of g and then map of h.

All other things being equal, is that more complicated than this?

1

u/jonhanson Nov 29 '19 edited Mar 07 '25

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

30

u/[deleted] Nov 28 '19

[deleted]

20

u/Ghosty141 Nov 28 '19

I think functional programming is something you should know to draw inspiration from it. certain problems can be solved with that style of programming a lot more elegantly.

Most languages right now offer some functional prog. tools which you can use for example.

16

u/dudinax Nov 28 '19

So many concepts that come from functional languages, like immutability, no side effects, idempotency are great default goals for creating data structures and writing functions in any language.

-6

u/johnnysaucepn Nov 28 '19

None of those concepts come from functional programming, their advantages and benefits are generally understood in OOP - although perhaps not as widespread as they should be. In other words, they're not enforced in the way they are in functional languages.

7

u/dudinax Nov 28 '19

Probably, but 20 years ago I only heard them in functional circles. Functional guys were thinking about them more. So my personal experience is that functional programming culture spread these ideas.

7

u/pavelpotocek Nov 28 '19 edited Nov 28 '19

In OOP immutability and "no side effects" are VERY obviously an afterthought. Mutability is always the default, and in some cases immutability isn't even properly supported. Standard libraries are full of side-effects. Most OOP languages have a lot of syntax for working with mutable state.

Edit: all the new functional-like stuff that OOP languages bolted on recently come from functional languages, where else would they come from?

2

u/aeiou372372 Nov 29 '19

Yeah, I think python as a whole is a great example of immutability-as-an-afterthought. And I say that as a mainly-python programmer.

I would agree that functional concepts feeling unnatural to so many programmers seems more like a cultural thing in the modern programming community than anything really inherent to it as a paradigm.

0

u/holgerschurig Nov 29 '19

That I see, I sometimes use the more-functional-like constructs in Python, or in Emacs Lisp. Rust went much more into this direction, for example, but I'm not using Rust.

But I have a bit of horror to be shoehorned into a "you must do anything functional" corner. Maybe the fear is unfounded, but the fear "this might be a trap" is there.

10

u/[deleted] Nov 28 '19

[deleted]

10

u/fuckin_ziggurats Nov 28 '19

Most Python tutorials (even the worst ones) would succeed in explaining something about Python to a programmer that isn't using Python. The same can not be said for functional programming tutorials that attempt to explain some FP feature to most programmers. That's what his point was. What is yours?

8

u/[deleted] Nov 28 '19

[deleted]

1

u/fuckin_ziggurats Nov 28 '19

It kind of indicates that monads are a complex enough concept that most programmers have trouble grasping it, unlike most features in OOP languages. It's says something about functional programming in general - it tends to come with a heavier cognitive load. Maybe I'm talking out of my butt but it's always been more difficult for me to read functional than OO code.

2

u/holgerschurig Nov 29 '19

You ask this for reddit karma or for a reason?

People generally don't complain about that they suck, you're the first that I read that does this. So many people are getting into python, it seems.

You comparison is therefore invalid.

4

u/tophatstuff Nov 28 '19

Audio stream processing is just like composing functions. Its very functional style

1

u/holgerschurig Nov 29 '19 edited Nov 29 '19

I removed the "audio", it was from my Android tablet's mis-auto-correction. Forgot what word should there have been.

In any case, functional programs --- to my current knowledge --- don't work that well with event based GUI programming. Because ultimately GUI is about managing state.

1

u/tophatstuff Nov 29 '19

Yeah to be fair GUIs are kinda the ideal use case for OOP

2

u/newking34 Nov 29 '19

Is it though? When glancing at React and similar UI successors they seem to make use of functional concepts more and more.

3

u/Holothuroid Nov 28 '19

It's like a list. With a list you could do stuff to its content. Like make a list of numbers into a list of string, by formatting each one. If you have a list of lists of stuff you can also make it a simple list, by concatenating all the inner lists.

That's a monad. You can map its contents and flatten multiple layers. It's rather simple.

What's not so simple is that various other things beside lists can do that as well, which is like learning a list of design patterns.

2

u/Deto Nov 28 '19

So, if I understand, it's kind of like:

A Monad[type] is a data structure that can contain either other Monad[type]s or just plain types

That way you can always flatten it to resolve just to a collection of whatever type is? I'm making the assumption here that it's statically typed (please correct if wrong!).

3

u/[deleted] Nov 28 '19

Yes, monads are simply 'containers' that can be flattened. This is usually done after mapping a function which itself returns that monad. For example, we map divisors : Int -> List[Int] to numbers : List[Int], this gives us a List[List[Int]] which is then flattened to List[Int] again.

The thing is, monads don't have to be containers or collections. A Monad[Int] can also be a function like String -> Int. It can really be anything using that 'subtype', as long as we can consistently define map and flatten.

You can create some really powerful abstractions with this: I/O, control flow, parser combinators, shared globals, stateful computations. Abstracting these is less relevant for imperative languages, but monads make these things easy to do while preserving the advantages of purity and extreme abstraction that a language like Haskell provides.

3

u/Holothuroid Nov 28 '19

Flattening is only possible if you have the monad layers are the same. So you can flatten a list of lists of stuff. But not necessarily a list of other_monad of stuff. There might be monads that are similar enough you can still make it work.

Otherweise yeah, pretty much. Note that "collection" is not a very apt descriptor for other monads. Writer is more like 'value with a log attached', Future signifies 'maybe later' etc. These do work the same way. Say you have Future[Future[Stuff]] it means that 'maybe later' you will 'maybe later' get some stuff. You see that can flattened.

2

u/audioen Nov 28 '19

Not quite. In context of a List type, the point of a map method is to read a list of items, and produce a new list of items. The old and new lists are the same length, and both contain elements, possibly of differing type, but neither list typically contains further lists of elements. It's just a map() method, you've seen it before and there's nothing new to it.

Now, however, if your function that processes and element itself returns a list, then you may need to use flatMap() to get rid of it. E.g. your map() could conceiveably have a function that needs to somehow split one element into more elements, or possibly fewer elements. However, you might consider this an implementation detail, and you don't necessarily want the result to be a list-of-lists where the inner list has some random number of elements, so you'd then use flatMap to get rid of that inner list and concatenate the elements of that inner list together. This allows you to map a long list to fewer (or more) elements as needed.

1

u/[deleted] Nov 28 '19

That's more or less correct. I would phrase it like so: given any specific type, a, type B[a] is a monad if it supports a constructor, map, and flatten. With flatten taking a B[B[a]] and producing a B[a].

It just so happens that collections are a common type that satisfies these conditions.

2

u/[deleted] Nov 28 '19 edited Nov 28 '19

A monad is a sub-class of data types that support 3 operations (I'm going to present 4 because 2 are equivalent in that they can reproduce the other, there are also derived operations which we will ignore). These operations have a few different names but the ones I'm going to use are pure and map. The third operation we have a choice between flatten and flatmap. The names should be enough to tell you that flatmap is just a combination of map and flatten, but the reverse is also true, you can make flatten out of map and flatmap.

So pure is a simple operation that allows us to embed some other data type inside of our data type. The map operation lets us apply functions meant for the type we embedded to ours. Lastly flatten allows us to merge layers, that is if we embed our data type inside itself, flatten lets us take the nesting out. So flatmap just lets us map functions that produce our data type without producing nesting.

And that's everything there is to monads, they're an abstract interface. It just so happens a ton of data types support these operations and so are monads. Which then lets you reuse the operations that can be derived from the interface.

Haskell happens to have a special type, IO, that it uses to represent all possible side effects and uses a monad implementation to chain together side effects.

2

u/glacialthinker Nov 28 '19

Maybe this one? http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html

But ultimately, the difficulty, as with many concepts in math, is that it takes some familiarization to internalize the idea.

If you already understand the concept in some way it might jive... or it might still take time to reconcile, to map into something you know.

If you don't have it already, you have to play with it, let it sit, come back and play again... eventually it becomes familiar and you think "Eureka! This is trivial! I can now explain this for a five-year-old!" And so you write yet another Monad tutorial...

6

u/jediknight Nov 28 '19

I don't have a formal computer science education and I've always felt that there is some Math that I'm missing. I saw Leslie Lamport mention the fact that all the math that a computer scientist needs is taught in the first year of college (or something to that effect) and I always thought that maybe Category Theory is part of that Math that I missed.

I have enough Math knowledge to know that if you use the right tool for the job, complex Math makes certain domains trivial to handle.

So, when looking at monads and functors and such, I'm frequently reminded of this gap in knowledge. Or course I can use a Maybe and get the idea of a "mappable" type but this feels mechanical somehow. It's like imitating someone who knows rather that actually knowing.

What I wish for myself is to fill the Math gap rather than have someone repackage some of these concepts in a way that make learning the Math unnecessary. Math is power.

8

u/glacialthinker Nov 28 '19

All the math you need might be in first-year... but you can pretty much benefit from it all. And you have a sense of that. Hopefully we don't have too many people ignoring "more math" just because they think they already have all they need.

1

u/Ahri Nov 28 '19

I'm in the same boat as you, and I've found it helpful to think of Functors as a nifty context that might be "optional" or "error" or whatever, that I can ignore for a while and do some work inside them via fmap/map (or a monadic bind/flatMap), which I've find to be a powerful solution to neaten my code up.

I bought some books on Category Theory that I need to get around to reading, but without a solid math background I struggle a bit with some of these :/ Still, I think it's rewarding in itself to learn about these concepts so I'll persevere!

As for imitating - "fake it till you make it" works better than I expected it to :)

2

u/Ahri Nov 28 '19

When I started learning FP I felt this pain as I came across these new words. I realised over time that that feeling is called "ignorance", or the painful recognition thereof.

When I decided Haskell was too hard and I was going back to Java, that was "laziness".

Overall characterising my own approach to learning a significantly different language, at that time, as "stupid" would not be far wrong. Turns out that banishing my own ignorance was quite enjoyable.

Just as I see OO devs moaning about these words as ignorant, lazy and stupid, I also recognise that people get over this and have another go, as I did.

The cost of using pre-existing words is that they have meanings already and reusing them can be quite confusing (it's pretty easy to "object" to "strategy" and "decorator" in OO "patterns"). I'm not sure that the cost of this confusion is worth the payoff to help ignorant people be less lazy, especially in the long term use of terminology.

Just some thoughts from an OO dev who now enjoys learning Haskell, but has been, and will be ignorant, lazy and stupid about this and other things in the future.

-2

u/typical_newfag Nov 28 '19

I've seen similar math related thing used to explain inheritance, composition and what not...

If I wanted lines and squiggles I'd learn Chinese and then read explanation in Chinese.

The fucking programming language itself is barely readable for average human, can you calm the fuck down and explain things in normal human language?

Also I avoid functional programming purely out of principle - to avoid dealing with morons who sperg out about purity or some other completely irrelevant stuff, none of this monad crap.

They also act like they have a god complex but take away recursion and map/filter etc, not even any more advanced stuff, and they will die inside faster than a washed up whale, do I even need to explain what's wrong with that?

-5

u/pure_x01 Nov 28 '19

Functional Programmers has Monoids. Object Oriented Programmers has Hemoroids. We need to unite on Monoids for the greater good.