The more of Haskell's ideas that bleed into mainstream languages, the happier the world will become. It is just so beautiful how these higher abstractions can become so useful and powerful for tying all kinds of things together.
I've been vibe coding my own language and it's compiler is in Haskell, it's been great for the agents to be inspired by Haskell and I'm having fun just adding random language features, currently implementing prophecy ghost variables. Not really a public project but can suss it out for now at http://lsalpha.com
This is super cool! You should put a clear example implementation of a feed forward network, transformer block, loss function, or something more ML specific on the homepage, assuming you're primarily targeting that domain.
EDIT: also the links to GitHub on https://lsalpha.com/systems are 404ing for me, so I exited your site without an example of what a real implementation might look like.
Haskell is a great research language - just don't try to use it for actual production programming. ;-)
It has a lot of excellent ideas and devilishly clever abstractions, but in Haskell they tend to remain incomplete and awkward to use. They tend to only mature by translation to other languages.
One of the best features of Idris 2 has nothing to do with its dependent types or quantities or proof search: it's the standard library which is very much like a cleaned-up Haskell standard library, with proper overloading to avoid naming conflicts, and even the ability to select among multiple interface implementations for the same type.
Just imagine the billions of value you could've generated with a more programmer-friendly language!
All jokes aside, it isn't impossible to use Haskell for a commercial project, but in my opinion you are making things needlessly difficult for yourself - especially in the pre-AI era. There's only a certain hours in a week, so do you want to spend those writing business logic, or building libraries to make up for the gaps in the ecosystem?
Take Ruby, for example. It is by most metrics not exactly a great language, and I reckon there are very few applications where the language itself is the best option. But take Ruby on Rails and you've suddenly got an opinionated batteries-included web app stack, where you can spend 99% of your time writing only the business logic that matters. No need to spend days fighting with Servant to get its not-quite-there-yet typed DSL to let you write basic CRUD, you can just focus on your MVP.
Want to send some email? You can either write your own Haskell integration of their REST API - orrr use their first-party C# SDK. Rinse and repeat for a dozen dependencies.
And all of that is before it turns out that some of your developers aren't the 20x rockstars you thought they were, and some of their clever high-level abstractions are horribly broken and doing more harm than good...
Haskell for me is "the one that got away". I really like the core language and I really want to use it for absolutely everything, but the ecosystem and culture around it just make that impossible.
While I agree, I also think that with agents the programming language fun is over, as we migrate to formalisms to drive them to perform the desired actions themselves.
Sure some folks will be able to look under the hood, like the ones writing language runtimes nowadays, transitioning into writing agentic runtimes.
I've long suspected that one of the things that makes monads notoriously difficult to explain to people outside of the Haskell ecosystem is that very few other languages even have a kind system that you are allowed to manipulate in code (and in some, like C++, it's so esoteric that you basically never see it). First explaining that you can even abstract over "type->type" kinded things gets you a lot of the way towards monads without actually describing monads.
The problem is not monads. Any programmer understands the need to represent "the world". It is the need to keep that representation modular that leads to monad transformers, which makes regular people (like me) simply check out and go back to C++
Monads have no inherent connection to any notion of "the world"; that's just a thing for Haskell's IO monad specifically (and perhaps derivatives thereof) because what that abstracts over is effects that are external to the program.
A monad is any construct of abstraction that obeys the Monad Laws. This may seem a useless definition, but my point is that deriving a useful intuition for the concept of the monad is necessarily challenging because they cannot readily be boiled down any further than that without loss of information.
The best intuitive explanation I've developed so far is that a monad is an abstraction over structures of ordered computations. The most ready examples for non-functional programmers are probably exceptions (and their handlers) and nullable types (typically called "optional types" in languages with first-class handling of such things, unlike Java).
Interesting. I come from a math background and for me, monads capture a notion of "things that depend on a type". So for every type X you can think about Lists/Records/Trees/... of X. And if you're lucky this gadget let's you do two things: 1. You can turn every instance x of X into a primitive List/Record/Tree/... of Xs. 2. You can flatten Lists of Lists of Xs into plain Lists of Xs, etc.
This is something you see a lot once you know what you're looking for.
And if you're really lucky, these two are nicely compatible:
For example there are two ways to get from L(L(L(X))) to L(X): By either flattening first in the inside or first on the outside.
And for a monad, you get the same result either way.
And the computational part is then really more of a consequence: If you've got some function of type X->L(Y) and another one of type Y->L(Z) then you can compose them to a function of type X->L(Z).
Not sure if going back to C++ is the answer, given how much Haskell like code one can write since C++20, and it has gotten even better with newer standards.
That may be true for functions which operate on a generic Monad typeclass, but typeclasses (Higher kinded types) aren't required to implement concrete Functor / Applicative / Monad instances for a particular type, e.g. Maybe:
fmap f Nothing = Nothing
fmap f (Just x) = Just (f x)
pure x = Just x
Nothing >>= f = Nothing
Just x >>= f = f x
Agreed. But there's a big difference between parametric polymorphism (List<A>) and ad-hoc polymorphism like typeclasses. It would be very painful to have to write a new list type for any kind of value type it might hold, but with monads you have many fewer distinct implementations (mainly just Maybe / Either / List / State / IO) and their actions are so different that you almost have to know exactly which monad you are using in the code, so "generic" code that can operate with any monad is less useful.
It seems that in java you could write `ArrayList<A>`. I think this type is actually of kind "type -> type". But in java it seems that we cannot have the type `A<B>`, and functors and monads require that..
I think most of the difficulty in explaining monads is the IO monad specifically. Leave that off and monads seem almost trivial. Add it back and whatever trivial mental model you just built stops working altogether.
It's about as difficult as describing vectors in math. Vectors aren't really "little arrows" or "things with magnitude and direction" (because then functions wouldn't count), I think there's a similarly cryptic saying that "a vector is just an element of a vector space" or "a tensor is anything that transforms like a tensor".
In both cases what they really are is an abstract concept defined by things that satisfy some definitions, but in practice it's easier to just look at a few concrete examples like Maybe.
Some OO languages have a parallel concept in "Metaclass" (https://en.wikipedia.org/wiki/Metaclass) i.e. the class of a class which is structurally similar to "Kind" though of course the mechanics are quite different.
I still have an old book Putting Metaclasses to Work - A New Dimension in Object-Oriented Programming by Forman et.al somewhere.
No, monads are largely a solution to problems introduced by pure functional programming, problems that impure languages don’t have in the first place.
I like monads as a concept, but in practice I find them frustrating and unnecessarily complicated. I worked on a large game written in Haskell and eventually gave up because dealing with monads made development so cumbersome.
I love the idea, but for real-world projects I’d rather avoid the complexity.
It's odd, the stereotype of software developers is a know-it-all attitude, but start talking about types and you get excuses that boil down to 'I'm incapable of learning to understand the thing you learned to understand'.
There is a video called A New Programming Fundamentals Course that contains some concepts that are very helpful to understand cases like these. I'd recommend you watch, it's free: https://www.youtube.com/watch?v=EV13CNrq4ZA
Namely, the section on "Mapping knowledge webs" (around 3:33). It explains people can struggle to adopt concepts that are too far outside their current knowledge, but that it can still be possible for them to pick it up if they can build a path to it from their current knowledge. (This often presents itself as the "depth-first" learning style)
A lot of commenters here, talking about how monads are so simple and how not being able to learn them is just lazy, are misunderstanding how learning fundamentally works. You have to expand the knowledge graph in the direction of monads before it will be easy to pick up monads. You have to build a path. You cannot simply teach monads right off the bat and expect someone to intuitively "get it". People who intuitively "get it" are people who already have a path.
I used to be a big Haskell fan and had a lot of fun writing and using monads. And I agree that once you get them, the basic idea is quite simple. I’ve even used monads to prove a small compiler correct in Lean.
But in practice, I think monads are a poor tool for large-scale software development. I spent a long time trying to build a large game in Haskell and eventually gave up out of frustration with the complexity they introduced.
Monads make sense as a way to manage effects in pure languages like Haskell/Lean/Idris/Agda. But outside that context, I don’t think the additional abstraction is worth the cost.
Understanding how monads work is one thing. Understanding why they’re needed in the first place, and when they’re not, is another.
OCaml isn't pure and neither is F# iirc do you see a bit less monad heavy code in large codebases there?
What sort of situations would you want to give up a little purity or error handling at the type level? Maybe at a boundary where you can just write a very ugly imperative but quarantined section to give it a simpler type?
> The thing that makes monads difficult is laziness and the anti math circle jerk.
That's quite a hateful way to describe lack of knowledge.
There are some prerequisites that make it easier to understand monads, and a lot of programmers don't even know those. That can make learning monads difficult right off the bat.
Your math explanation starts with a math concept that the vast, vast, vast majority of people will have never even heard of, even in math-adjacent fields. It's not anti-math reasoning. It's a lack of self-awareness that your background is very math heavy, which makes that particular explanation make sense to you. I've gone my entire schooling, as a student who was always one of the few who were "good at math", all the the way through my CS education, without ever having heard of a functor until I came across the Haskell monad explanation meme.
Your next step could be to blame the school systems if you want, but that doesn't help the situation at hand.
>> You start from a functor which is a data type that admits a map operation.
Then you add of, or pure, to make an applicative functor, and then you add flatmap to make a monad.
> Your math explanation starts with a math concept that the vast, vast, vast majority of people will have never even heard of, even in math-adjacent fields
Let me take this apart.
1. a data type that admits a map operation
Present in most languages including JavaScript. Not a mathematical issue.
2. add of, or pure, to make an applicative functor
I had to look this up. It was new content for me, maybe 5 or 10 minutes believing I would get it.
3. add flatmap
This didn’t scare me but maybe it scares others. Not a mathematical issue here, though. Being in C++ doesn’t make this concept mainstream, I guess?
I majored in mathematics and I learned category theory before touching any serious Haskell, and I still found most of the "monad tutorials" kind of opaque and handwavy, and I think there are inherently non-trivial details unrelated to the notion of functor etc.
No there are no trivial details, and you don't need a mathematics major or category theory to understand what a functor is.
It's a pair of a type constructor F(a) and a map operation a -> b to get an F(b).
The two "non-trivial" details are the fact that the map operation has to respect identity, map(id) = id, and function composition: map(g ∘ f) = map(g) ∘ map(f)
None of those concepts is any difficult, nor requires any "math major" or non-trivial details, because the are not there.
Most of the stuff you just explained is absent from your explanation of monads. So it turns out monads are not so simple after all for people who don't already understand functors...
FWIW I dropped out of high school to pursue programming more directly. I regret it now because of the job market crash, but it's also too late for me to go back.
You can try to blame lack of knowledge on anything you want, but at the end of the day Hacker News is for intellectual curiosity and even HN readers don't all know what monads are.
One thing I've noticed since I've become an engineer who gets to design the architecture:
No matter what I do, eventually algebraic structures like semi-groups and monads along with categorical structure like lenses and traversals keep popping up.
It seems like the sort of thing that system designers could benefit from understanding, but the ordinary users of a system shouldn't need to know about it.
What is the article actually saying? It doesn't seem the author actually knows.
It seems a tale about abstraction land, and how it never allows you to exit it again. How you pay taxes for every day spent in it, sold to you as a solution to a problem you didn't think you had.
As any problem can be expressed in C, how would what the author did look like in C? KISS. Abstraction land clearly protects one from such vulgarities.
The gist is that "kinds" allow you to write generic types which themselves take generic types as type parameters.
For a concrete example, suppose that you want to define a data type for JSON objects. You would likely need to choose a type to represent JSON arrays (such as `ArrayList`, in Java), as well as a type to represent JSON objects (such as `HashMap`). However, what if the client wanted to use `TreeMap` instead of `HashMap`?
With "kinds," you would be able to define the JSON data type as something abstract like `JSON<ArrayType, MapType>`, and allow the client to instantiate it as `JSON<ArrayList, HashMap>` or `JSON<ArrayList, TreeMap>`. Unfortunately, in a language such as Java, this is not possible, because `ArrayList`, `HashMap`, and `TreeMap` are themselves generic types, while only non-generic types (such as `Integer`, `String`, or `HashMap<String, Integer>`) can be type parameters. However, in a language with higher-kinded types, such as Scala, this becomes possible.
In these higher-kinded languages, a type such as `Integer` or `HashMap<String, Integer>` would have a "kind" of `*`, while a generic type such as `ArrayList` would have a kind of `* -> *` (meaning: a generic type of one, non-generic type parameter), and `HashMap` and `TreeMap` would both have a "kind" of `* -> * -> *` (meaning: a generic type of two, non-generic type parameters).
C++'s templates permit a similar abstraction to higher-kinded types, and the library nlohmann::json (https://json.nlohmann.me/api/basic_json/) in fact does something very similar to the JSON example that I describe. Namely, it uses `std::vector` as the default for `ArrayType` and `std::map` as the default for `MapType`, but also allows the client to parameterize the underlying container of choice. However, C++ templates need to be fully expanded in order to be typechecked, leading to compile-time error messages that can be long and difficult to read. A "kind" system basically solves this issue by imposing a proper type system onto templates, allowing for more understandable error messages.
You don't. Or less snarky, I imagine you'd have to use macros to generate wrapper functions, in order to generate a new function of a user provided type.
I really like the concept of dependent types, all type systems that I use rust or haskell have a very limited set of dependent types, but I do like the things that it let's you do
My main problem with Haskell is that it never fully embraced dependent types. Instead, it kept adding one type system extension after another, making the language unnecessarily complicated.
I used to be a big Haskell fan, until I discovered languages like Lean, Agda, and Idris 2 and realized how much cleaner and more coherent the whole thing could be with dependent types built in from the start.
I highly recommend Haskell fans explore Lean/Agda/Idris. They make Haskell feel like a pile of spaghetti by comparison.
> These are the constructs we manipulate in our programs, things like 1, 2, True, "hello", etc… In functional programming contexts, they're also called "terms."
This is not correct. Terms are syntactic expressions in a program. For example, 1+2 is a term, but it’s not a value. At runtime, it evaluates to 3. As such, some terms correspond directly to values - like 1 - but other terms represent computations that will be performed at runtime.
tl;dr: terms are a syntactic concept, values are a runtime concept. Terms evaluate to values.
Why do you think so? It's a completely standard usage. For example, we can ask MathWorld:
> In logic, a term is a variable ['a', 'f'], constant ['1', '"hello"'], or the result of acting on variables and constants by function symbols ['1+2', 'f(a)'].
In particular, note that by this wording, if you're looking at '1+2', the "term" is not the string '"1+2"' but the result of adding '1' to '2', which is '3'.
You can talk about 'terms' in the context of how a compiler views source code. Or you can talk about 'terms' in the context of how type theory applies to some computation. They'll be called 'terms' either way; you seem to have staked out the position that the compiler context is obligatory and the type theory context is somehow in error.
Your quote points out that a term can be a variable. A variable represents a value, but it is not a value itself. The same goes for compound expressions. There are distinctions between variables, values, and expressions, and these distinctions are significant. You may have a sloppy head canon that blurs all these concepts together, but that’s not how they’re treated formally.
Terms are a syntactic concept while Values are a semantic runtime concept. The key to understanding is that Values are Terms which have been reduced (i.e. evaluated) to normal form and hence cannot be reduced further. The nuance lies in the fact that while both unreduced Terms and reduced Values can have semantic meanings, only at the Value stage is it canonical and fully computed.
In fact the "Calculus of Constructions" (CoC) derived from Typed Lambda Calculus unifies everything into a Term like so;
Term ::= variable | lambda abstraction | lambda application | dependant product | sorts (type of types)
But "term" is not a term that is restricted to computation. In normal mathematical usage, all values are always 'fully computed'. You may not personally know what they are, but that doesn't matter. These are just different names that we give to a single object.
True. But even in Mathematical Logic, a Term is a syntactical construct. You need to apply a "interpretation function" (mapping to a specific domain) to get a Value.
In Computation this is just made explicit and clear using a "eval function".
> you seem to have staked out the position that the compiler context is obligatory and the type theory context is somehow in error.
I used the compiler to illustrate the issue to people who clearly aren’t familiar with type theory. You imply that you are, but in that case, how do you justify the nonsense quoted above?
Following on from the above, this statement is also incomplete at best:
> Types are groups of related values.
This is an operational perspective which misses one of the most important aspects of types: in a statically typed language, types are a way to classify terms, i.e. they're not just about values.
As an example of why this distinction matters, consider this expression: 1 + "hello". In most statically typed languages, this will be rejected at compile time. It doesn't have to be evaluated (i.e. at runtime) to be rejected - it's invalid because the types of the terms - 1 and "hello" - aren't compatible.
This compile-time rejection is only possibly because types apply to terms, and terms aren't values. This is critical to the usefulness of statically-typed languages - without this, they'd have to run the program to detect type errors.
Benjamin Pierce's book "Types and Programming Languages" has some great coverage of this topic.
In "Simply Typed Lambda Calculus" (STLC) there are two grammars for a legal expression.
1) Type Grammar - Type ::= inbuilt types | Type1->Type2 (function)
2) Term Grammar - Term ::= constant | variable | lambda abstraction : "Type" | lambda application.
Note how in (2) above "Type" comes into the picture. During compilation, the expression's structure is analyzed and verified against the Typing Rules aka "Type Checking". Once this is passed the expression is considered sound and can be evaluated at runtime.
In "Calculus of Constructions" (CoC) the two grammars are unified into one which gives us powerful concepts like dependent types, polymorphism etc. - https://news.ycombinator.com/item?id=50137880
> Do you mean that if types had only to do with values, you would have to evaluate the term to determine type?
Exactly. And if that were the case, you couldn't do very much type checking at compile time.
Javascript, or more specifically Typescript, is precisely why I wrote "In most statically typed languages..."
In Typescript, you can write `1 + "hello"` and the type system will infer that the type of that term is 'string'. It doesn't change anything I wrote above.
The more of Haskell's ideas that bleed into mainstream languages, the happier the world will become. It is just so beautiful how these higher abstractions can become so useful and powerful for tying all kinds of things together.
I've been vibe coding my own language and it's compiler is in Haskell, it's been great for the agents to be inspired by Haskell and I'm having fun just adding random language features, currently implementing prophecy ghost variables. Not really a public project but can suss it out for now at http://lsalpha.com
This is super cool! You should put a clear example implementation of a feed forward network, transformer block, loss function, or something more ML specific on the homepage, assuming you're primarily targeting that domain.
EDIT: also the links to GitHub on https://lsalpha.com/systems are 404ing for me, so I exited your site without an example of what a real implementation might look like.
That is a great suggestion, and you are correct, so I will do what you said!
Neatly summarises my experience of most vibe coded projects unfortunately.
Presumably the repo is private...
Haskell is a great research language - just don't try to use it for actual production programming. ;-)
It has a lot of excellent ideas and devilishly clever abstractions, but in Haskell they tend to remain incomplete and awkward to use. They tend to only mature by translation to other languages.
One of the best features of Idris 2 has nothing to do with its dependent types or quantities or proof search: it's the standard library which is very much like a cleaned-up Haskell standard library, with proper overloading to avoid naming conflicts, and even the ability to select among multiple interface implementations for the same type.
For some simple examples see https://github.com/stefan-hoeck/idris2-tutorial
> Haskell is a great research language - just don't try to use it for actual production programming. ;-)
Oops, your advice came ten years and millions of dollars of value generated too late for me :(
Just imagine the billions of value you could've generated with a more programmer-friendly language!
All jokes aside, it isn't impossible to use Haskell for a commercial project, but in my opinion you are making things needlessly difficult for yourself - especially in the pre-AI era. There's only a certain hours in a week, so do you want to spend those writing business logic, or building libraries to make up for the gaps in the ecosystem?
Take Ruby, for example. It is by most metrics not exactly a great language, and I reckon there are very few applications where the language itself is the best option. But take Ruby on Rails and you've suddenly got an opinionated batteries-included web app stack, where you can spend 99% of your time writing only the business logic that matters. No need to spend days fighting with Servant to get its not-quite-there-yet typed DSL to let you write basic CRUD, you can just focus on your MVP.
Want to send some email? You can either write your own Haskell integration of their REST API - orrr use their first-party C# SDK. Rinse and repeat for a dozen dependencies.
And all of that is before it turns out that some of your developers aren't the 20x rockstars you thought they were, and some of their clever high-level abstractions are horribly broken and doing more harm than good...
Haskell for me is "the one that got away". I really like the core language and I really want to use it for absolutely everything, but the ecosystem and culture around it just make that impossible.
Some examples of those?
While I agree, I also think that with agents the programming language fun is over, as we migrate to formalisms to drive them to perform the desired actions themselves.
Sure some folks will be able to look under the hood, like the ones writing language runtimes nowadays, transitioning into writing agentic runtimes.
I've long suspected that one of the things that makes monads notoriously difficult to explain to people outside of the Haskell ecosystem is that very few other languages even have a kind system that you are allowed to manipulate in code (and in some, like C++, it's so esoteric that you basically never see it). First explaining that you can even abstract over "type->type" kinded things gets you a lot of the way towards monads without actually describing monads.
The problem is not monads. Any programmer understands the need to represent "the world". It is the need to keep that representation modular that leads to monad transformers, which makes regular people (like me) simply check out and go back to C++
https://en.wikipedia.org/wiki/Monad_transformer
Monads have no inherent connection to any notion of "the world"; that's just a thing for Haskell's IO monad specifically (and perhaps derivatives thereof) because what that abstracts over is effects that are external to the program.
A monad is any construct of abstraction that obeys the Monad Laws. This may seem a useless definition, but my point is that deriving a useful intuition for the concept of the monad is necessarily challenging because they cannot readily be boiled down any further than that without loss of information.
The best intuitive explanation I've developed so far is that a monad is an abstraction over structures of ordered computations. The most ready examples for non-functional programmers are probably exceptions (and their handlers) and nullable types (typically called "optional types" in languages with first-class handling of such things, unlike Java).
Interesting. I come from a math background and for me, monads capture a notion of "things that depend on a type". So for every type X you can think about Lists/Records/Trees/... of X. And if you're lucky this gadget let's you do two things: 1. You can turn every instance x of X into a primitive List/Record/Tree/... of Xs. 2. You can flatten Lists of Lists of Xs into plain Lists of Xs, etc.
This is something you see a lot once you know what you're looking for.
And if you're really lucky, these two are nicely compatible:
For example there are two ways to get from L(L(L(X))) to L(X): By either flattening first in the inside or first on the outside.
And for a monad, you get the same result either way.
And the computational part is then really more of a consequence: If you've got some function of type X->L(Y) and another one of type Y->L(Z) then you can compose them to a function of type X->L(Z).
Not sure if going back to C++ is the answer, given how much Haskell like code one can write since C++20, and it has gotten even better with newer standards.
That may be true for functions which operate on a generic Monad typeclass, but typeclasses (Higher kinded types) aren't required to implement concrete Functor / Applicative / Monad instances for a particular type, e.g. Maybe:
"Generic" and "for a particular type" cancel out.
You don't need List<A> to write an IntList, nor do you need + to work on different integers in order to have a particular integer.
Agreed. But there's a big difference between parametric polymorphism (List<A>) and ad-hoc polymorphism like typeclasses. It would be very painful to have to write a new list type for any kind of value type it might hold, but with monads you have many fewer distinct implementations (mainly just Maybe / Either / List / State / IO) and their actions are so different that you almost have to know exactly which monad you are using in the code, so "generic" code that can operate with any monad is less useful.
When people say they don’t understand Monad, my first assumption is that they are wearing their ignorance as a badge of honor.
Otherwise memorize a little bit and dispose of the mystery. It’s not that far out.
It seems that in java you could write `ArrayList<A>`. I think this type is actually of kind "type -> type". But in java it seems that we cannot have the type `A<B>`, and functors and monads require that..
Just to polish that,
ArrayList's kind is type->type
ArrayList<A>'s kind is type.
The A is what plugs into type on the LHS of the arrow, leaving only the RHS remaining.
I think most of the difficulty in explaining monads is the IO monad specifically. Leave that off and monads seem almost trivial. Add it back and whatever trivial mental model you just built stops working altogether.
> things that makes monads notoriously difficult to explain to people outside of the Haskell ecosystem
Huh, I thought a monad is just a monoid in the category of endofunctors, what's the problem?
It's about as difficult as describing vectors in math. Vectors aren't really "little arrows" or "things with magnitude and direction" (because then functions wouldn't count), I think there's a similarly cryptic saying that "a vector is just an element of a vector space" or "a tensor is anything that transforms like a tensor".
In both cases what they really are is an abstract concept defined by things that satisfy some definitions, but in practice it's easier to just look at a few concrete examples like Maybe.
And here I was convinced that they’re burritos!
I will say that explaining functors to my coworkers was always much simpler, and then naturally led to monads
I suspect all branches of tech have their rite of passage.
For haskellers, it is writing a monad tutorial
For javascripters, it is writing a framework
For make-stuff-with-LLM people, it is producing a diagram explaining your code generation factory
... and so on
Some OO languages have a parallel concept in "Metaclass" (https://en.wikipedia.org/wiki/Metaclass) i.e. the class of a class which is structurally similar to "Kind" though of course the mechanics are quite different.
I still have an old book Putting Metaclasses to Work - A New Dimension in Object-Oriented Programming by Forman et.al somewhere.
There is also the classic The Art of the Metaobject Protocol by Kiczales et.al which is quie relevant here - https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...
The key difference is that the Type guys do it at compile time (correctness) while the OO guys do it at runtime (flexibility).
No, monads are largely a solution to problems introduced by pure functional programming, problems that impure languages don’t have in the first place.
I like monads as a concept, but in practice I find them frustrating and unnecessarily complicated. I worked on a large game written in Haskell and eventually gave up because dealing with monads made development so cumbersome.
I love the idea, but for real-world projects I’d rather avoid the complexity.
The thing that makes monads difficult is laziness and the anti math circle jerk.
You start from a functor which is a data type that admits a map operation.
Then you add of, or pure, to make an applicative functor, and then you add flatmap to make a monad.
It's odd, the stereotype of software developers is a know-it-all attitude, but start talking about types and you get excuses that boil down to 'I'm incapable of learning to understand the thing you learned to understand'.
There is a video called A New Programming Fundamentals Course that contains some concepts that are very helpful to understand cases like these. I'd recommend you watch, it's free: https://www.youtube.com/watch?v=EV13CNrq4ZA
Namely, the section on "Mapping knowledge webs" (around 3:33). It explains people can struggle to adopt concepts that are too far outside their current knowledge, but that it can still be possible for them to pick it up if they can build a path to it from their current knowledge. (This often presents itself as the "depth-first" learning style)
A lot of commenters here, talking about how monads are so simple and how not being able to learn them is just lazy, are misunderstanding how learning fundamentally works. You have to expand the knowledge graph in the direction of monads before it will be easy to pick up monads. You have to build a path. You cannot simply teach monads right off the bat and expect someone to intuitively "get it". People who intuitively "get it" are people who already have a path.
I used to be a big Haskell fan and had a lot of fun writing and using monads. And I agree that once you get them, the basic idea is quite simple. I’ve even used monads to prove a small compiler correct in Lean.
But in practice, I think monads are a poor tool for large-scale software development. I spent a long time trying to build a large game in Haskell and eventually gave up out of frustration with the complexity they introduced.
Monads make sense as a way to manage effects in pure languages like Haskell/Lean/Idris/Agda. But outside that context, I don’t think the additional abstraction is worth the cost.
Understanding how monads work is one thing. Understanding why they’re needed in the first place, and when they’re not, is another.
OCaml isn't pure and neither is F# iirc do you see a bit less monad heavy code in large codebases there?
What sort of situations would you want to give up a little purity or error handling at the type level? Maybe at a boundary where you can just write a very ugly imperative but quarantined section to give it a simpler type?
> The thing that makes monads difficult is laziness and the anti math circle jerk.
That's quite a hateful way to describe lack of knowledge.
There are some prerequisites that make it easier to understand monads, and a lot of programmers don't even know those. That can make learning monads difficult right off the bat.
No there's no complexity behind monads except laziness and anti math circle jerk.
It's really basic concepts, much easier than the analysis you do in high school.
But people would rather sit through monad as boxes or burritos cringe tutorials.
Your math explanation starts with a math concept that the vast, vast, vast majority of people will have never even heard of, even in math-adjacent fields. It's not anti-math reasoning. It's a lack of self-awareness that your background is very math heavy, which makes that particular explanation make sense to you. I've gone my entire schooling, as a student who was always one of the few who were "good at math", all the the way through my CS education, without ever having heard of a functor until I came across the Haskell monad explanation meme.
Your next step could be to blame the school systems if you want, but that doesn't help the situation at hand.
>> You start from a functor which is a data type that admits a map operation. Then you add of, or pure, to make an applicative functor, and then you add flatmap to make a monad.
> Your math explanation starts with a math concept that the vast, vast, vast majority of people will have never even heard of, even in math-adjacent fields
Let me take this apart.
1. a data type that admits a map operation
Present in most languages including JavaScript. Not a mathematical issue.
2. add of, or pure, to make an applicative functor
I had to look this up. It was new content for me, maybe 5 or 10 minutes believing I would get it.
3. add flatmap
This didn’t scare me but maybe it scares others. Not a mathematical issue here, though. Being in C++ doesn’t make this concept mainstream, I guess?
https://en.cppreference.com/cpp/container/flat_map
I majored in mathematics and I learned category theory before touching any serious Haskell, and I still found most of the "monad tutorials" kind of opaque and handwavy, and I think there are inherently non-trivial details unrelated to the notion of functor etc.
No there are no trivial details, and you don't need a mathematics major or category theory to understand what a functor is.
It's a pair of a type constructor F(a) and a map operation a -> b to get an F(b).
The two "non-trivial" details are the fact that the map operation has to respect identity, map(id) = id, and function composition: map(g ∘ f) = map(g) ∘ map(f)
None of those concepts is any difficult, nor requires any "math major" or non-trivial details, because the are not there.
When there are 100 explanations of some topic, maybe it's not so trivial, after all, even when the bare axioms seem trivial.
Most of the stuff you just explained is absent from your explanation of monads. So it turns out monads are not so simple after all for people who don't already understand functors...
FWIW I dropped out of high school to pursue programming more directly. I regret it now because of the job market crash, but it's also too late for me to go back.
Lack of knowledge is not the problem at all. Anti-intellectualism is.
You can try to blame lack of knowledge on anything you want, but at the end of the day Hacker News is for intellectual curiosity and even HN readers don't all know what monads are.
I think you missed the “not”.
Nope.
One thing I've noticed since I've become an engineer who gets to design the architecture:
No matter what I do, eventually algebraic structures like semi-groups and monads along with categorical structure like lenses and traversals keep popping up.
It seems like the sort of thing that system designers could benefit from understanding, but the ordinary users of a system shouldn't need to know about it.
In my experience such categories pop up when dealing with immutable data, which is common in many domains.
What is the article actually saying? It doesn't seem the author actually knows.
It seems a tale about abstraction land, and how it never allows you to exit it again. How you pay taxes for every day spent in it, sold to you as a solution to a problem you didn't think you had.
As any problem can be expressed in C, how would what the author did look like in C? KISS. Abstraction land clearly protects one from such vulgarities.
The gist is that "kinds" allow you to write generic types which themselves take generic types as type parameters.
For a concrete example, suppose that you want to define a data type for JSON objects. You would likely need to choose a type to represent JSON arrays (such as `ArrayList`, in Java), as well as a type to represent JSON objects (such as `HashMap`). However, what if the client wanted to use `TreeMap` instead of `HashMap`?
With "kinds," you would be able to define the JSON data type as something abstract like `JSON<ArrayType, MapType>`, and allow the client to instantiate it as `JSON<ArrayList, HashMap>` or `JSON<ArrayList, TreeMap>`. Unfortunately, in a language such as Java, this is not possible, because `ArrayList`, `HashMap`, and `TreeMap` are themselves generic types, while only non-generic types (such as `Integer`, `String`, or `HashMap<String, Integer>`) can be type parameters. However, in a language with higher-kinded types, such as Scala, this becomes possible.
In these higher-kinded languages, a type such as `Integer` or `HashMap<String, Integer>` would have a "kind" of `*`, while a generic type such as `ArrayList` would have a kind of `* -> *` (meaning: a generic type of one, non-generic type parameter), and `HashMap` and `TreeMap` would both have a "kind" of `* -> * -> *` (meaning: a generic type of two, non-generic type parameters).
C++'s templates permit a similar abstraction to higher-kinded types, and the library nlohmann::json (https://json.nlohmann.me/api/basic_json/) in fact does something very similar to the JSON example that I describe. Namely, it uses `std::vector` as the default for `ArrayType` and `std::map` as the default for `MapType`, but also allows the client to parameterize the underlying container of choice. However, C++ templates need to be fully expanded in order to be typechecked, leading to compile-time error messages that can be long and difficult to read. A "kind" system basically solves this issue by imposing a proper type system onto templates, allowing for more understandable error messages.
Great Explanation!
See also: Concepts for higher-kinded types in C++20 - https://mmore500.com/cse-491/blog/2020/02/24/concepts-monads...
> As any problem can be expressed in C, how would what the author did look like in C? KISS
This is C.
How do you express "the thing you get back has the same type as the thing you're looking for"?You don't. Or less snarky, I imagine you'd have to use macros to generate wrapper functions, in order to generate a new function of a user provided type.
I really like the concept of dependent types, all type systems that I use rust or haskell have a very limited set of dependent types, but I do like the things that it let's you do
My main problem with Haskell is that it never fully embraced dependent types. Instead, it kept adding one type system extension after another, making the language unnecessarily complicated.
I used to be a big Haskell fan, until I discovered languages like Lean, Agda, and Idris 2 and realized how much cleaner and more coherent the whole thing could be with dependent types built in from the start.
I highly recommend Haskell fans explore Lean/Agda/Idris. They make Haskell feel like a pile of spaghetti by comparison.
Are those languages ready for production use?
Missed opportunity to say "Kinds of kindness". ;-)
- 404 on posts? https://thunk.blog/posts/
> These are the constructs we manipulate in our programs, things like 1, 2, True, "hello", etc… In functional programming contexts, they're also called "terms."
This is not correct. Terms are syntactic expressions in a program. For example, 1+2 is a term, but it’s not a value. At runtime, it evaluates to 3. As such, some terms correspond directly to values - like 1 - but other terms represent computations that will be performed at runtime.
tl;dr: terms are a syntactic concept, values are a runtime concept. Terms evaluate to values.
> This is not correct.
Why do you think so? It's a completely standard usage. For example, we can ask MathWorld:
> In logic, a term is a variable ['a', 'f'], constant ['1', '"hello"'], or the result of acting on variables and constants by function symbols ['1+2', 'f(a)'].
(I've added the bracketed material, which provides examples of the senses that MathWorld gives. https://mathworld.wolfram.com/Term.html )
In particular, note that by this wording, if you're looking at '1+2', the "term" is not the string '"1+2"' but the result of adding '1' to '2', which is '3'.
You can talk about 'terms' in the context of how a compiler views source code. Or you can talk about 'terms' in the context of how type theory applies to some computation. They'll be called 'terms' either way; you seem to have staked out the position that the compiler context is obligatory and the type theory context is somehow in error.
Your quote points out that a term can be a variable. A variable represents a value, but it is not a value itself. The same goes for compound expressions. There are distinctions between variables, values, and expressions, and these distinctions are significant. You may have a sloppy head canon that blurs all these concepts together, but that’s not how they’re treated formally.
Terms are a syntactic concept while Values are a semantic runtime concept. The key to understanding is that Values are Terms which have been reduced (i.e. evaluated) to normal form and hence cannot be reduced further. The nuance lies in the fact that while both unreduced Terms and reduced Values can have semantic meanings, only at the Value stage is it canonical and fully computed.
In fact the "Calculus of Constructions" (CoC) derived from Typed Lambda Calculus unifies everything into a Term like so;
Term ::= variable | lambda abstraction | lambda application | dependant product | sorts (type of types)
For reference see Brandl's work that i list here - https://news.ycombinator.com/item?id=50028902
But "term" is not a term that is restricted to computation. In normal mathematical usage, all values are always 'fully computed'. You may not personally know what they are, but that doesn't matter. These are just different names that we give to a single object.
True. But even in Mathematical Logic, a Term is a syntactical construct. You need to apply a "interpretation function" (mapping to a specific domain) to get a Value.
In Computation this is just made explicit and clear using a "eval function".
Your own quote tells you why that’s wrong.
Do you seriously want to argue this point?
> you seem to have staked out the position that the compiler context is obligatory and the type theory context is somehow in error.
I used the compiler to illustrate the issue to people who clearly aren’t familiar with type theory. You imply that you are, but in that case, how do you justify the nonsense quoted above?
Following on from the above, this statement is also incomplete at best:
> Types are groups of related values.
This is an operational perspective which misses one of the most important aspects of types: in a statically typed language, types are a way to classify terms, i.e. they're not just about values.
As an example of why this distinction matters, consider this expression: 1 + "hello". In most statically typed languages, this will be rejected at compile time. It doesn't have to be evaluated (i.e. at runtime) to be rejected - it's invalid because the types of the terms - 1 and "hello" - aren't compatible.
This compile-time rejection is only possibly because types apply to terms, and terms aren't values. This is critical to the usefulness of statically-typed languages - without this, they'd have to run the program to detect type errors.
Benjamin Pierce's book "Types and Programming Languages" has some great coverage of this topic.
To clarify further;
In "Simply Typed Lambda Calculus" (STLC) there are two grammars for a legal expression.
1) Type Grammar - Type ::= inbuilt types | Type1->Type2 (function)
2) Term Grammar - Term ::= constant | variable | lambda abstraction : "Type" | lambda application.
Note how in (2) above "Type" comes into the picture. During compilation, the expression's structure is analyzed and verified against the Typing Rules aka "Type Checking". Once this is passed the expression is considered sound and can be evaluated at runtime.
In "Calculus of Constructions" (CoC) the two grammars are unified into one which gives us powerful concepts like dependent types, polymorphism etc. - https://news.ycombinator.com/item?id=50137880
Do you mean that if types had only to do with values, you would have to evaluate the term to determine type?
Also, 1 + "hello" is "1hello", obviously. Have you never read JavaScript? :)
I gather it goes through an intermediate coercion step where it is "1" + "hello".
What trips us up is having existing expectations for what an operator called + should do.
> Do you mean that if types had only to do with values, you would have to evaluate the term to determine type?
Exactly. And if that were the case, you couldn't do very much type checking at compile time.
Javascript, or more specifically Typescript, is precisely why I wrote "In most statically typed languages..."
In Typescript, you can write `1 + "hello"` and the type system will infer that the type of that term is 'string'. It doesn't change anything I wrote above.