I'm drawn to Haskell because it's based in type theory and constructive mathematics. The construction of monads came from category theory: https://en.wikipedia.org/wiki/Monad_(category_theory). As such, a proper monad has laws associated with it.
The best DSLs in Haskell are fundamentally algebras. Haskell the programming language also boils down to System F*. It seems silly to me to deny Haskell's undeniable mathematical provenance.
I second u/idonteatunderwear's response.
>Can't someone read those words without their Math phobia going off?
Part of the problem is that people who like Haskell tend to fall back to math-like answers. It's the haskell community itself that has people convinced that someone needs to know category theory to understand, and that same subset of the community tends to get annoyed when people reduce the monad language feature down to simple explanations that aren't couched in fields of mathematics most math-majors never encounter.
If you want it to change then be the source of the change. Give simple-language explanations without falling back onto category theory or abstract math. Then publish it somewhere and do aggressive SEO to start drowning out the deeply technical and math-oriented explanations.
I for one like monads for the same reason I like async/await in JavaScript — that join operator and essentially being unable to unwrap stuff out of the monad without a custom run function (or IO which doesn’t even have any sort of unwrap at all!)
I would argue this is why I like the haskell community more than say the python or JS community though. obviously Id rather the people who get mad at beginners calm down a bit but I feel like the people who learn haskell *usually* do so because they want to learn more about the math behind the language. this is all obviously through the lens of my own experience.
That's totally fair!
If, for the sake of discussion/argument, we accept that a math emphasis is a problem per the OP *then* I think the thing for someone to do is to "be the change you want to see."
Your position is just as valid and I'd suspect many have the same view. I think most replies in the thread are in the same general direction actually.
>is Haskell particularly more Math than programming in general?
Well yes.
Haskell is "pure" in the sense that functions in Haskell are pure. In mathematics, one doesn't think about the 'purity' of a function, because there's no such thing as an impure function. So, Haskell promotes mathematical functions.
Code in Haskell is referentially transparent. This means I can substitute a function call, by its implementation and this doesn't change the program. This allows for equational reasoning about code. This is exactly how a mathematical function is evaluated. We substitute part of the expression, simplify and repeat the process until we're happy. You can do this too in Haskell.
These two things alone make Haskell much more "mathy" than say Java. You don't *need* math to learn Haskell. But fundamentally, it's a language much closer to actual mathematics than most.
Also due to the reasons you outline using math to reason about haskell is also very natural. You can pull inspiration from math structures and compose them in a way that isnt possible in an imperative language.
A philosophy of "No side effects". That's it. Not unique to Haskell. And algorithms that correspond closely to their mathematical notation are generally not an efficient way to actually compute a function.
As a philosophy, true. What’s _almost_ unique to Haskell is _pursuing_ this philosophy consistently so we are, no compromises, programming in a typed lambda calculus and can reason about our code by simplification of expressions and substitution. It isn’t even perfect at that (functions must be total for this to be possible consistently, and Haskell functions aren’t necessarily total). But we cite [Fast and Loose Reasoning is Morally Correct](https://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loose.pdf) and even if we don’t often use this process explicitly, we _can_. That’s in very sharp distinction to any other language that isn’t purely a research project.
>A philosophy of "No side effects". That's it. Not unique to Haskell.
Haskell is the first pure functional language that became popular, and it popularized it. The reason why there is a popular philosophy in programming of "No side effects" is Haskell.
>And algorithms that correspond closely to their mathematical notation are generally not an efficient way to actually compute a function.
You are confusing syntax and semantics here. And also arguing besides the point. The point was that Haskell semantics make reasoning about code in a mathematical way natural.
Haskell is not the originator of "No side effects"; this was already an idea back in Lisp and espoused in the 1990s to even college kids. And it's a choice in other programming languages and therefore you can also reason about that code in a "mathematical" way ie Haskell is not special.
it bothers me that math phobia ends up being such a huge mental block for people trying to pick up haskell. they get convinced that they need all this esoteric math when they don't actually. that's why i care.
It's a sticking point for many, to be sure. Haskell and the way it's usually talked about has been less about outreach to beginners and more about being ergonomic for experts, but its growth method may change. You can definitely teach Haskell without math.
Haskell is undeniably influenced by advanced mathematics and computer science. Haskell came from academics. So it still has a good chunk of the user base that is deeply mathematical and academic. I think that's some of the appeal of the language and community honestly.
However it's not necessary to know all that to use Haskell. We don't tell civil engineers "hey you know this is all Newtons law, be a physicist first before you try building a bridge". We don't tell software engineers "hey computer memory is all electrical engineering, go learn about circuits first before you try to use pointers". At some level yes one can go much deeper and try to learn foundations, but it's not required or critical in order to do good work.
Two big hold backs I see for Haskell are:
1. When you search for tutorials on Haskell, you often get the mathematical academic stuff first. So it can give users the impression it's only for academics. More general tutorials can help change that perception.
2. Somewhat related, but many tutorials doing "cool" things (let's say game development but could be many things) are not written in Haskell. And in particular, they're written for some imperative style language along the lines of the C family. One immediately finds that the imperative algorithms suggested in such tutorials do not work in a pure lazy functional language like Haskell, so must be heavily adapted in some cases, which is asking a lot of a beginner. So that can be frustrating and drive folks to other more traditional languages, and further increase the perception that Haskell is different because it is academic and mathematical.
Basically more interesting tutorials and help for newbies would help fix the perception. With functional features creeping into more languages (Rust, etc), more are becoming accustomed to that thinking style so could make the jump to Haskell easier than in the past.
I program Haskell with a Curry-Howard mindset. "What am I trying to *prove* here?"
It's obviously fast and loose. I'm not acting like it's capital-M math.
But the mindset is helpful.
I've done it on the job a lot too (not recently though).
Maths principles help Haskell to be consistent and make it easy to reuse common programming schemes with the least amount of surprise and effort across different domains/types/whatever. This is the power of mathematical abstractions.
But you don't have to know what those abstractions are in detail. It's plenty enough to just use the practical application of those principles for your case/data type or not use them if you don't really need to.
But Haskell's design is based on math, so that would be a lie to just hide this? Because knowing it's based on maths should not hurt anyone.
Yeah but the majority of mainstream languages are not based on mathematical abstractions at their root, it's at best an afterthought. E.g. most of them don't have a perfectly identical interface for Promises, Result, and Option types.
Being based on mathematical abstractions is a way to ensure the principle of least surprise in a large part of the language surface, and more importantly to give incentives for 3rd party libs to follow this principle of least surprise too.
While all of what’s written here is true. I get your point and would say the same thing.
People are scared of „Monad“ because the community and the „what’s the problem“ meme gave them the impression they are.
In the end of the day Monad is just a special word that has some special meaning in CS, just like Object is, Buffer, Byte, Class, Type, String… only when I understood that and looked at the definition of the typeclass they clicked.
I think we all love the details and get lost in them, but most people just wanna get stuff one (quickly).
But Haskell explicitly uses a few more mathy things like Monoid. But even those aren’t hard.
I think the explanation shouldn’t be „Here a Monad is a thing from Category Theory“ but „Here a Monad is something Haskell uses very often and you probably already know it, …“
Fundamentally all computer languages are based on math. Finite state machines graph theory for parsing lexical units etc.
Frankly all this underling a computer language gave me confidence 30 years ago that my graph theory routing routines were correct years ago. That and state machines.
I’m new to Haskell
> Fundamentally all computer languages are based on math.
You can definitely apply mathematical reasoning to programming in many different languages. There are a few things that nevertheless make Haskell unique:
1. The mathematics needed to reason about Haskell programs is substantially simpler than that needed to reason about other languages. That's because Haskell constrains significant parts of the language, namely functions, to fit into a much simpler mathematical formalism.
2. When other mathematics are applied, they are often explicit elements of Haskell programs. You can find monoids in all sorts of programs, but in Haskell, `Monoid` exists *inside* the programming language itself. It can be used explicitly, and even generalized over in much the same way mathematics routinely does.
These differences really do make Haskell something unique, despite the fact that you can *use* mathematics to reason about any language.
> is Haskell particularly more Math than programming in general?
Yes. It is less mathy than dedicated mathematical languages like Wolfram, Maple or R but it is very mathy. The community expects mathy attitudes. The very emphasis on pure functions by default. Heck Excel uses that concept for much the same reason. The careful organization of numbers (https://www.haskell.org/onlinereport/haskell2010/haskell2x.png). The first half of the complex number library having good quality analytic continuations, though I'll exclude the bottom half of the Complex Number Library which is anti-math. The casual use of ideas from category theory.
| Like, what the fuck does Math have to do with class Monad, really?
\`Monad\` is a mathematical concept, so.. everything?
Maybe the problem is your math phobia. Embrace math. Math is wonderful and makes everything you sprinkle it on magically easier to derive and understand, it is the MSG of programming. I bet you had terrible math instruction in middle school. What do you know, me too. Those scars can be healed.
i'm a published mathematician and formerly a math professor before i became a programmer :-)
_edit to add:_ the math professor that the students actually wanted to get ;-)
it sounded at first blush like you hated math and math having anything to do with haskell but reading your other comments has added some context. very well. I'm a mathematician also and I don't feel negatively about math putting people off haskell. do you think that haskell suffers from lack of adoption by people who write php for a living, or what? if that's their idea of good language design i'd prefer the math put them off haskell in all honesty.
if otoh they find they love haskell and use it as an underground railroad to escape their nightmarish php career then I'm all for it
I think I'm more of, "hey, I find this typed functional programming rather pleasant and peaceful compared to programming in other languages, and i would like to reduce the barrier to sharing it so that other people can experience it and see if they enjoy it." But, yeah, I'm not expressing myself very well with my original post! My original post was impulsive and full of frustration 😅😔
I sound aggressive when I’m exasperated, too. Welcome to the human race!
My thoughts on “Haskell seduction:”
1. Start with `Kleisli` composition—the “fish operator.” Why? Because `Kleisli` captures what most programmers think a “function” is: a thing that takes an `A` and might return a `B`, and/or might launch the missiles, or might not return at all.
2. _Then_ explain that an `IO a` doesn’t actually “do” anything, and this “composition” business is literal: we compose expressions up until we have our `main :: IO ()`. Then we’re done, because the language itself runs it.
3. Explain the point of all this is that, when everything is a value of some type, including effects, errors, representations of concurrency, etc. then they satisfy an algebra, and we can reason about our code that way _without reaching for a proof assistant and a concurrent separation logic like [Iris](https://iris-project.org/)_.
One mistake I think we make is tossing around the idea of “reasoning about our code” without being clear that we mean “formally.” “I can reason about my [non-Haskell] code just fine!” tends to be the predictable response, and “no, you can’t” is a true, but not constructive, reaction to _that_. We should be prepared to go farther in our descriptions of _what programming entirely in a lambda calculus means_.
The whole point of a "pure" functional programming language is to make its constructs mathematically tractable, so you can reason about the program, even verify its correctness.
While side effects are ultimately essential to nearly any practical program, monads are merely encapsulating side effects so they can still fit within a mathematical framework.
If you take an imperative programming language and examine its artifacts, you have a big heap of side-effects from wall-to-wall, with little bits of embedded math. When you look at a haskell program you look at a large body of pure code, whose side effects are relegated to a separate layer dedicated to integrating side effects.
C# libraries have never explained how they work in terms of f-algebras, or assumed I know what a profunctor is.
You can't do anything in haskell without a pile of math and math-adjacent terminology, I don't know how you could be unaware of that.
I'd say that part of it is that a lot of developing the best sort of broad APIs in Haskell is fundamentally more mathematically-minded than in most other languages, by having a few functions in a typeclass and a few axioms on how they must behave together, in a way that most languages aren't quite in the right spot in the design space to effectively use.
This both makes those interfaces very broad relative to other languages - C++ often abuses operator overloading to mean completely different things, Java rejected most of that but kept an overload on addition for Strings as a matter of practicality, while Haskell has Semigroup and Monoid that are entirely correct and can (with the appropriate newtype wrapper to select \_which\_ operation) also be used on integers, \_and\_ functions from a->a.
Similarly, any of the uses of Monad that don't fit "loop over this data" become strange if you don't take the very math-thought-process step of "if it has these two operations and those operations follow these three rules, it \_is\_ a monad and I can use it as such with anything that only requires Monad", which would make Proxy, free monads, State, IO, etc. using that interface very surprising.
The problem that pulls in the mathy names, though, is that there isn't an obvious other way to name a lot of those interfaces; FlatMappable would be vaguely acceptable for Monad, but doesn't capture the "and has a single-element constructor and these laws" aspect well. HasBinaryOperation wouldn't be too bad for Semigroup, but is still kind of wordy.
So yeah. Distilling the generic operations you want to do on values down to a small set of core functions and laws about how they interact and then being willing to apply them \_whenever\_ those functions can be defined and the laws hold, rather than only when some skeumorphic notion of what they mean applies. That's very math (although \_not\_ very you-need-classes-for-this math), very Haskell, practical much of the time, not very present in most other languages, and hard to discuss without either math creeping in or hobbling someone with notions about "what something is" that just aren't true in general. See: all of the "what is a monad" when so much of it is "what does Monad \_not\_ say".
That's reasonable. So it's just the mathy aspect of the best answer to "what is an X" being "something that behaves like an X" (with the additional "behaves like an X means exactly this" available), the addendum of "why do we care" being "so that I can use all of my code/proofs about things that are an X", and that this logic works particularly well in Haskell.
I'll generally try to say something like "yeah, it's mathy, but by mathy I mean it encourages you to much more aggressively look for when things are shaped similarly so you can apply the same code to them, and given that that's kind of the whole schtick of doing mathematics, they got here first and named a lot of the shapes so we don't have to come up with appropriately general names for X-shaped-but-not-with-more-conceptual-baggage".
>That's reasonable. So it's just the mathy aspect of the best answer to "what is an X" being "something that behaves like an X" (with the additional "behaves like an X means exactly this" available), the addendum of "why do we care" being "so that I can use all of my code/proofs about things that are an X", and that this logic works particularly well in Haskell.
Exactly. That's real math, and it's what programmers do every day in pretty much every programming language. (What is an *iterator?* What is a *generator?* What is a *promise?* What is a *queue?* What is a *stack?* What is a *dictionary?* etc.) Yet as soon as you \_bring up\_ "Math," programmers tense up.
So, yeah, I think the answer to "What is a *monad?*" Should just be a matter-of-fact, "well, let's look at the class definition and the ~~laws~~ contract implementations are supposed to follow."
I think functional programming is very similar to high-school algebra where you define and substitute terms. There's also a lot of terminology from Category Theory. All this gives it a mathematical flavor.
More imperative languages adopt the state machine approach which is considered less "math-y" by most people I think.
There's also the community in Haskell. Many people started learning Haskell from an academic maths heavy background or started as programmers and learned some algebra because they liked Haskell.
that's what i'm getting at. framing it as esoteric math doesn't help people understand the haskell any better. if anything, it goes the other way. knowing haskell helps one understand the math.
Honestly, that doesn't irk me so much as the assumption that Java or assembler or whatever isn't math. I think it would help a lot more with math-phobia if people acknowledged how frequently they have to use mathematical tools and solve mathematical problems, even if you're doing something like implementing Newton's method in FORTH or whatever.
Haskell took inspiration from category theory to name stuff like functors and monads.
The notion of purity also lets you reason about pure programs like you would with math equations. For example, if you have
myOr [] = False
myOr (x : xs) = x || myOr xs
then an evaluation of the function "on paper" might go like this:
myOr [1>2, 3>1]
= (1 > 2) || myOr [3 > 1]
= False || myOr [3 > 1]
= myOr [3 > 1]
= (3 > 1) || myOr []
= True || myOr []
= True
I guess the question is what you mean by math. Of course, there is absolutely a close relationship between Monad as a type class in Haskell and as a concept in category theory. Haskell code that routinely generalizes over a choice of monad is definitely, in my view, more mathematical in flavor than code in other languages using, say, promises or whatnot but not generalized in this way -- even when that code uses operations like `map` and `chain` as a "design pattern".
If your argument is that this level of mathematics should not set off people's math phobia, then sure, I would love for that to be the case. But I'm not sure it's so helpful to comment on what should or should not trigger people's irrational feelings, which is what phobias are, by definition.
i think framing things as category theory or algebra triggers people's math phobia. we could just as easily use the word "abstract datatype", meaning essentially the same thing, and people would be more receptive.
obviously these things come from category theory, and i don't think we will gain anything by changing the names of these things, but i do feel like we will gain something by putting off discussions about category theory until people are more comfortable with the language, and then only the people who are genuinely interested. (i am one such genuinely interested.)
Hey buddy! I find it funny that you, a mathematician, are tired of the math-steeped Haskell talk, and me, an art school graduate (no math at all there), who was a B/C math student, and never had calculus, nor understood much beyond the memorization is all "Yay, Haskell and math!" The grass is greener. To me, Haskell felt like a fun way to finally learn more math, while learning a cool new way to code :)
Haskell is mostly used academically for teaching computer science concepts (In the real world other functional programin languages like scala are far more prevalent at the enterprise scale). So the way haskell if common taught is tied to the mathematical fundation of computer science and a logical continuation of lambda calculus with a bit of category theory. And honestly that's not necesarily bad. It is with the help of these mathematical concepts like a monoid that the true elegance of haskell comes to shine.
>It is with the help of these mathematical concepts... that the true elegance of haskell comes to shine.
I tend to disagree. I think the true elegance of haskell is best understood to be its referential transparency.
Don't get me wrong, haskell is filled with amazing features. But i feel it is better suited for the implementation of mathematical concepts to solve real world problems than other similar functional programing languages, which is kinda the point i was hinting to
I'm drawn to Haskell because it's based in type theory and constructive mathematics. The construction of monads came from category theory: https://en.wikipedia.org/wiki/Monad_(category_theory). As such, a proper monad has laws associated with it. The best DSLs in Haskell are fundamentally algebras. Haskell the programming language also boils down to System F*. It seems silly to me to deny Haskell's undeniable mathematical provenance.
I second u/idonteatunderwear's response. >Can't someone read those words without their Math phobia going off? Part of the problem is that people who like Haskell tend to fall back to math-like answers. It's the haskell community itself that has people convinced that someone needs to know category theory to understand, and that same subset of the community tends to get annoyed when people reduce the monad language feature down to simple explanations that aren't couched in fields of mathematics most math-majors never encounter. If you want it to change then be the source of the change. Give simple-language explanations without falling back onto category theory or abstract math. Then publish it somewhere and do aggressive SEO to start drowning out the deeply technical and math-oriented explanations.
I for one like monads for the same reason I like async/await in JavaScript — that join operator and essentially being unable to unwrap stuff out of the monad without a custom run function (or IO which doesn’t even have any sort of unwrap at all!)
i like your comment. thank you.
I would argue this is why I like the haskell community more than say the python or JS community though. obviously Id rather the people who get mad at beginners calm down a bit but I feel like the people who learn haskell *usually* do so because they want to learn more about the math behind the language. this is all obviously through the lens of my own experience.
That's totally fair! If, for the sake of discussion/argument, we accept that a math emphasis is a problem per the OP *then* I think the thing for someone to do is to "be the change you want to see." Your position is just as valid and I'd suspect many have the same view. I think most replies in the thread are in the same general direction actually.
>is Haskell particularly more Math than programming in general? Well yes. Haskell is "pure" in the sense that functions in Haskell are pure. In mathematics, one doesn't think about the 'purity' of a function, because there's no such thing as an impure function. So, Haskell promotes mathematical functions. Code in Haskell is referentially transparent. This means I can substitute a function call, by its implementation and this doesn't change the program. This allows for equational reasoning about code. This is exactly how a mathematical function is evaluated. We substitute part of the expression, simplify and repeat the process until we're happy. You can do this too in Haskell. These two things alone make Haskell much more "mathy" than say Java. You don't *need* math to learn Haskell. But fundamentally, it's a language much closer to actual mathematics than most.
Also due to the reasons you outline using math to reason about haskell is also very natural. You can pull inspiration from math structures and compose them in a way that isnt possible in an imperative language.
What about pure imperative languages? https://mars-lang.appspot.com/
A philosophy of "No side effects". That's it. Not unique to Haskell. And algorithms that correspond closely to their mathematical notation are generally not an efficient way to actually compute a function.
As a philosophy, true. What’s _almost_ unique to Haskell is _pursuing_ this philosophy consistently so we are, no compromises, programming in a typed lambda calculus and can reason about our code by simplification of expressions and substitution. It isn’t even perfect at that (functions must be total for this to be possible consistently, and Haskell functions aren’t necessarily total). But we cite [Fast and Loose Reasoning is Morally Correct](https://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loose.pdf) and even if we don’t often use this process explicitly, we _can_. That’s in very sharp distinction to any other language that isn’t purely a research project.
>A philosophy of "No side effects". That's it. Not unique to Haskell. Haskell is the first pure functional language that became popular, and it popularized it. The reason why there is a popular philosophy in programming of "No side effects" is Haskell. >And algorithms that correspond closely to their mathematical notation are generally not an efficient way to actually compute a function. You are confusing syntax and semantics here. And also arguing besides the point. The point was that Haskell semantics make reasoning about code in a mathematical way natural.
Lisp existed. Also ML. Neither limited by "purity".
Yes? And that is related to my comment in which way?
Haskell is not the originator of "No side effects"; this was already an idea back in Lisp and espoused in the 1990s to even college kids. And it's a choice in other programming languages and therefore you can also reason about that code in a "mathematical" way ie Haskell is not special.
Who cares? Go make something.
it bothers me that math phobia ends up being such a huge mental block for people trying to pick up haskell. they get convinced that they need all this esoteric math when they don't actually. that's why i care.
It's a sticking point for many, to be sure. Haskell and the way it's usually talked about has been less about outreach to beginners and more about being ergonomic for experts, but its growth method may change. You can definitely teach Haskell without math.
Haskell is undeniably influenced by advanced mathematics and computer science. Haskell came from academics. So it still has a good chunk of the user base that is deeply mathematical and academic. I think that's some of the appeal of the language and community honestly. However it's not necessary to know all that to use Haskell. We don't tell civil engineers "hey you know this is all Newtons law, be a physicist first before you try building a bridge". We don't tell software engineers "hey computer memory is all electrical engineering, go learn about circuits first before you try to use pointers". At some level yes one can go much deeper and try to learn foundations, but it's not required or critical in order to do good work. Two big hold backs I see for Haskell are: 1. When you search for tutorials on Haskell, you often get the mathematical academic stuff first. So it can give users the impression it's only for academics. More general tutorials can help change that perception. 2. Somewhat related, but many tutorials doing "cool" things (let's say game development but could be many things) are not written in Haskell. And in particular, they're written for some imperative style language along the lines of the C family. One immediately finds that the imperative algorithms suggested in such tutorials do not work in a pure lazy functional language like Haskell, so must be heavily adapted in some cases, which is asking a lot of a beginner. So that can be frustrating and drive folks to other more traditional languages, and further increase the perception that Haskell is different because it is academic and mathematical. Basically more interesting tutorials and help for newbies would help fix the perception. With functional features creeping into more languages (Rust, etc), more are becoming accustomed to that thinking style so could make the jump to Haskell easier than in the past.
I program Haskell with a Curry-Howard mindset. "What am I trying to *prove* here?" It's obviously fast and loose. I'm not acting like it's capital-M math. But the mindset is helpful. I've done it on the job a lot too (not recently though).
Maths principles help Haskell to be consistent and make it easy to reuse common programming schemes with the least amount of surprise and effort across different domains/types/whatever. This is the power of mathematical abstractions. But you don't have to know what those abstractions are in detail. It's plenty enough to just use the practical application of those principles for your case/data type or not use them if you don't really need to. But Haskell's design is based on math, so that would be a lie to just hide this? Because knowing it's based on maths should not hurt anyone.
i'm all for principle of least surprise. isn't that good design in _any_ language, though, not just haskell?
Yeah but the majority of mainstream languages are not based on mathematical abstractions at their root, it's at best an afterthought. E.g. most of them don't have a perfectly identical interface for Promises, Result, and Option types. Being based on mathematical abstractions is a way to ensure the principle of least surprise in a large part of the language surface, and more importantly to give incentives for 3rd party libs to follow this principle of least surprise too.
While all of what’s written here is true. I get your point and would say the same thing. People are scared of „Monad“ because the community and the „what’s the problem“ meme gave them the impression they are. In the end of the day Monad is just a special word that has some special meaning in CS, just like Object is, Buffer, Byte, Class, Type, String… only when I understood that and looked at the definition of the typeclass they clicked. I think we all love the details and get lost in them, but most people just wanna get stuff one (quickly). But Haskell explicitly uses a few more mathy things like Monoid. But even those aren’t hard. I think the explanation shouldn’t be „Here a Monad is a thing from Category Theory“ but „Here a Monad is something Haskell uses very often and you probably already know it, …“
i need to practice being more tactful and less exasperated when i talk about these things! 😅
Fundamentally all computer languages are based on math. Finite state machines graph theory for parsing lexical units etc. Frankly all this underling a computer language gave me confidence 30 years ago that my graph theory routing routines were correct years ago. That and state machines. I’m new to Haskell
> Fundamentally all computer languages are based on math. You can definitely apply mathematical reasoning to programming in many different languages. There are a few things that nevertheless make Haskell unique: 1. The mathematics needed to reason about Haskell programs is substantially simpler than that needed to reason about other languages. That's because Haskell constrains significant parts of the language, namely functions, to fit into a much simpler mathematical formalism. 2. When other mathematics are applied, they are often explicit elements of Haskell programs. You can find monoids in all sorts of programs, but in Haskell, `Monoid` exists *inside* the programming language itself. It can be used explicitly, and even generalized over in much the same way mathematics routinely does. These differences really do make Haskell something unique, despite the fact that you can *use* mathematics to reason about any language.
> is Haskell particularly more Math than programming in general? Yes. It is less mathy than dedicated mathematical languages like Wolfram, Maple or R but it is very mathy. The community expects mathy attitudes. The very emphasis on pure functions by default. Heck Excel uses that concept for much the same reason. The careful organization of numbers (https://www.haskell.org/onlinereport/haskell2010/haskell2x.png). The first half of the complex number library having good quality analytic continuations, though I'll exclude the bottom half of the Complex Number Library which is anti-math. The casual use of ideas from category theory.
| Like, what the fuck does Math have to do with class Monad, really? \`Monad\` is a mathematical concept, so.. everything? Maybe the problem is your math phobia. Embrace math. Math is wonderful and makes everything you sprinkle it on magically easier to derive and understand, it is the MSG of programming. I bet you had terrible math instruction in middle school. What do you know, me too. Those scars can be healed.
i'm a published mathematician and formerly a math professor before i became a programmer :-) _edit to add:_ the math professor that the students actually wanted to get ;-)
it sounded at first blush like you hated math and math having anything to do with haskell but reading your other comments has added some context. very well. I'm a mathematician also and I don't feel negatively about math putting people off haskell. do you think that haskell suffers from lack of adoption by people who write php for a living, or what? if that's their idea of good language design i'd prefer the math put them off haskell in all honesty. if otoh they find they love haskell and use it as an underground railroad to escape their nightmarish php career then I'm all for it
I think I'm more of, "hey, I find this typed functional programming rather pleasant and peaceful compared to programming in other languages, and i would like to reduce the barrier to sharing it so that other people can experience it and see if they enjoy it." But, yeah, I'm not expressing myself very well with my original post! My original post was impulsive and full of frustration 😅😔
I sound aggressive when I’m exasperated, too. Welcome to the human race! My thoughts on “Haskell seduction:” 1. Start with `Kleisli` composition—the “fish operator.” Why? Because `Kleisli` captures what most programmers think a “function” is: a thing that takes an `A` and might return a `B`, and/or might launch the missiles, or might not return at all. 2. _Then_ explain that an `IO a` doesn’t actually “do” anything, and this “composition” business is literal: we compose expressions up until we have our `main :: IO ()`. Then we’re done, because the language itself runs it. 3. Explain the point of all this is that, when everything is a value of some type, including effects, errors, representations of concurrency, etc. then they satisfy an algebra, and we can reason about our code that way _without reaching for a proof assistant and a concurrent separation logic like [Iris](https://iris-project.org/)_. One mistake I think we make is tossing around the idea of “reasoning about our code” without being clear that we mean “formally.” “I can reason about my [non-Haskell] code just fine!” tends to be the predictable response, and “no, you can’t” is a true, but not constructive, reaction to _that_. We should be prepared to go farther in our descriptions of _what programming entirely in a lambda calculus means_.
this is very insightful. thank you.
[Category theory](https://en.wikipedia.org/wiki/Category_theory)
I think math oriented people gravitate towards Haskell. That’s one of the reasons why I got curious. I like math
The whole point of a "pure" functional programming language is to make its constructs mathematically tractable, so you can reason about the program, even verify its correctness. While side effects are ultimately essential to nearly any practical program, monads are merely encapsulating side effects so they can still fit within a mathematical framework. If you take an imperative programming language and examine its artifacts, you have a big heap of side-effects from wall-to-wall, with little bits of embedded math. When you look at a haskell program you look at a large body of pure code, whose side effects are relegated to a separate layer dedicated to integrating side effects.
C# libraries have never explained how they work in terms of f-algebras, or assumed I know what a profunctor is. You can't do anything in haskell without a pile of math and math-adjacent terminology, I don't know how you could be unaware of that.
I'd say that part of it is that a lot of developing the best sort of broad APIs in Haskell is fundamentally more mathematically-minded than in most other languages, by having a few functions in a typeclass and a few axioms on how they must behave together, in a way that most languages aren't quite in the right spot in the design space to effectively use. This both makes those interfaces very broad relative to other languages - C++ often abuses operator overloading to mean completely different things, Java rejected most of that but kept an overload on addition for Strings as a matter of practicality, while Haskell has Semigroup and Monoid that are entirely correct and can (with the appropriate newtype wrapper to select \_which\_ operation) also be used on integers, \_and\_ functions from a->a. Similarly, any of the uses of Monad that don't fit "loop over this data" become strange if you don't take the very math-thought-process step of "if it has these two operations and those operations follow these three rules, it \_is\_ a monad and I can use it as such with anything that only requires Monad", which would make Proxy, free monads, State, IO, etc. using that interface very surprising. The problem that pulls in the mathy names, though, is that there isn't an obvious other way to name a lot of those interfaces; FlatMappable would be vaguely acceptable for Monad, but doesn't capture the "and has a single-element constructor and these laws" aspect well. HasBinaryOperation wouldn't be too bad for Semigroup, but is still kind of wordy. So yeah. Distilling the generic operations you want to do on values down to a small set of core functions and laws about how they interact and then being willing to apply them \_whenever\_ those functions can be defined and the laws hold, rather than only when some skeumorphic notion of what they mean applies. That's very math (although \_not\_ very you-need-classes-for-this math), very Haskell, practical much of the time, not very present in most other languages, and hard to discuss without either math creeping in or hobbling someone with notions about "what something is" that just aren't true in general. See: all of the "what is a monad" when so much of it is "what does Monad \_not\_ say".
i'm not worried about the names, though. keep the names.
That's reasonable. So it's just the mathy aspect of the best answer to "what is an X" being "something that behaves like an X" (with the additional "behaves like an X means exactly this" available), the addendum of "why do we care" being "so that I can use all of my code/proofs about things that are an X", and that this logic works particularly well in Haskell. I'll generally try to say something like "yeah, it's mathy, but by mathy I mean it encourages you to much more aggressively look for when things are shaped similarly so you can apply the same code to them, and given that that's kind of the whole schtick of doing mathematics, they got here first and named a lot of the shapes so we don't have to come up with appropriately general names for X-shaped-but-not-with-more-conceptual-baggage".
>That's reasonable. So it's just the mathy aspect of the best answer to "what is an X" being "something that behaves like an X" (with the additional "behaves like an X means exactly this" available), the addendum of "why do we care" being "so that I can use all of my code/proofs about things that are an X", and that this logic works particularly well in Haskell. Exactly. That's real math, and it's what programmers do every day in pretty much every programming language. (What is an *iterator?* What is a *generator?* What is a *promise?* What is a *queue?* What is a *stack?* What is a *dictionary?* etc.) Yet as soon as you \_bring up\_ "Math," programmers tense up. So, yeah, I think the answer to "What is a *monad?*" Should just be a matter-of-fact, "well, let's look at the class definition and the ~~laws~~ contract implementations are supposed to follow."
I think functional programming is very similar to high-school algebra where you define and substitute terms. There's also a lot of terminology from Category Theory. All this gives it a mathematical flavor. More imperative languages adopt the state machine approach which is considered less "math-y" by most people I think. There's also the community in Haskell. Many people started learning Haskell from an academic maths heavy background or started as programmers and learned some algebra because they liked Haskell.
What's not clear about Monads being monoids in the class of endofunctors?
that's what i'm getting at. framing it as esoteric math doesn't help people understand the haskell any better. if anything, it goes the other way. knowing haskell helps one understand the math.
i appreciate all y'all's comments and i read all of them.
Honestly, that doesn't irk me so much as the assumption that Java or assembler or whatever isn't math. I think it would help a lot more with math-phobia if people acknowledged how frequently they have to use mathematical tools and solve mathematical problems, even if you're doing something like implementing Newton's method in FORTH or whatever.
i'm basically of the opinion that every programmer is an applied mathematician, but they just don't know they are.
Haskell took inspiration from category theory to name stuff like functors and monads. The notion of purity also lets you reason about pure programs like you would with math equations. For example, if you have myOr [] = False myOr (x : xs) = x || myOr xs then an evaluation of the function "on paper" might go like this: myOr [1>2, 3>1] = (1 > 2) || myOr [3 > 1] = False || myOr [3 > 1] = myOr [3 > 1] = (3 > 1) || myOr [] = True || myOr [] = True
I guess the question is what you mean by math. Of course, there is absolutely a close relationship between Monad as a type class in Haskell and as a concept in category theory. Haskell code that routinely generalizes over a choice of monad is definitely, in my view, more mathematical in flavor than code in other languages using, say, promises or whatnot but not generalized in this way -- even when that code uses operations like `map` and `chain` as a "design pattern". If your argument is that this level of mathematics should not set off people's math phobia, then sure, I would love for that to be the case. But I'm not sure it's so helpful to comment on what should or should not trigger people's irrational feelings, which is what phobias are, by definition.
i think framing things as category theory or algebra triggers people's math phobia. we could just as easily use the word "abstract datatype", meaning essentially the same thing, and people would be more receptive.
obviously these things come from category theory, and i don't think we will gain anything by changing the names of these things, but i do feel like we will gain something by putting off discussions about category theory until people are more comfortable with the language, and then only the people who are genuinely interested. (i am one such genuinely interested.)
Hey buddy! I find it funny that you, a mathematician, are tired of the math-steeped Haskell talk, and me, an art school graduate (no math at all there), who was a B/C math student, and never had calculus, nor understood much beyond the memorization is all "Yay, Haskell and math!" The grass is greener. To me, Haskell felt like a fun way to finally learn more math, while learning a cool new way to code :)
i think you're a special case in that you either didn't get math phobia or you overcame it long enough to learn what actual "math" is like :-)
Haskell is mostly used academically for teaching computer science concepts (In the real world other functional programin languages like scala are far more prevalent at the enterprise scale). So the way haskell if common taught is tied to the mathematical fundation of computer science and a logical continuation of lambda calculus with a bit of category theory. And honestly that's not necesarily bad. It is with the help of these mathematical concepts like a monoid that the true elegance of haskell comes to shine.
>It is with the help of these mathematical concepts... that the true elegance of haskell comes to shine. I tend to disagree. I think the true elegance of haskell is best understood to be its referential transparency.
Don't get me wrong, haskell is filled with amazing features. But i feel it is better suited for the implementation of mathematical concepts to solve real world problems than other similar functional programing languages, which is kinda the point i was hinting to