You need to be able to "wrap" values and then also "wrap" functions in the way you expect. That's literally it.
Btw, the list monad example is stupid imo and borderline misleading. The promise/nullable/Either examples are better. you "wrap" a function by putting it as the only value in a list, and "map" pretty much acts as your function wrapper, but technically this you need to jump through a couple hoops to make it monadic, and I'm just not sure the metaphor is helpful here
For some monads the "wrap" gets awfully metaphorical (for State it's a function that produces the value and updated state, for Const there is no value, etc) but I don't think that's actually a problem, just a thing to be aware of. There is certainly no expectation that you can actually get your hands on the thing.
A bigger issue is that you're missing a piece. If you can "wrap" values and "wrap" functions such that they operate on wrapped values, you (probably) have a functor. To be a monad you also need to have the ability to turn multiple layers of wrapping into one layer of wrapping. For lists, that's "flatten".
I said "probably" above because there are rules these pieces need to follow to behave well. They're pretty simple but I don't think we need to dig into them at this level of discussion.
Agree about the list monad. I have never used it in actual code. I always felt it was so arbitrary, and "implicit", in the sense that if you haven't learnt beforehand that it makes "joins", then it's certainly not obvious that it should work that way
λ> do { a <- [1,2]; pure a; }
[1,2]
-- oh so it returns the list unchanged
λ> do { a <- [1,2]; b <- [3,4]; pure a; }
[1,1,2,2]
-- no what is this spooky action at a distance
λ> do { a <- [1,2]; b <- [3,4]; pure [a]; }
[[1],[1],[2],[2]]
-- ...
λ> do { a <- [1,2]; b <- [3,4]; c <- []; pure [a]; }
[]
λ> do { a <- [1,2]; b <- [3,4]; c <- [5]; pure [a,b,c]; }
[[1,3,5],[1,4,5],[2,3,5],[2,4,5]]
Somehow I hear this all the time, but the haskell people have to realize that code patterns are absolutely a thing in all languages, ever? A lack of syntactic sugar doesn't mean monads don't exist in other languages.
Typeclasses are a distraction, the point is computation ignoring annoying contexty stuff (file not found errors, null on failure, etc) and there's dozens of examples in literally every language ever.
Not all problems are solved with a technical definition.
> the haskell people have to realize that code patterns are absolutely a thing in all languages, ever? A lack of syntactic sugar doesn't mean monads don't exist in other languages.
Where did you get the impression that Haskell people don't realize that code patterns are a thing in other languages, or that monads don't exist in other languages?
Besides the syntactic sugar of "do notation", what Haskell has that most other languages don't have is the ability to abstract over monads, since it has higher kinded types. That is, you can write a generic operation like
mapM :: (Traversable t, Monad m) => (a -> m b) -> t a -> m (t b)
that works for all monads. Most other type languages force you to write mapM separately for each monad you want it to work with.
Like many things in life it is far easier to give examples than it is to describe the thing.
Examples of monads are Promises and Elvis operators (for values that can be nullptrs). In a sense exceptions as well. Having heard this I think if you do a second pass at the type definitions, I think you may be able to parse them out
It really is just "a wrapper for values that sticks around when you do something to the values".
Think of it as a coding pattern, and it's much easier to grok
It's handy for IO because, well, did you see the examples I gave? A monad lets you basically ignore the failure mode/weirdness (the async stuff in the context of promises, null type in the case of Elvis) and worry about the computation you actually want to be doing.
Other places you might apply these would be fileio (file not found? cool, don't care, deal with it later) or networking (as long as the connection's good, do this.)
Sorry I never understood the functional approach outside of LISP being cool, because code is data.
Promises are wrappers, I see that. How are exceptions wrappers? They stop the code at the point the exception occurs and unwind the stack. They don't allow you to continue doing stuff and deal with it later.
> A monad lets you basically ignore the failure mode/weirdness
I just don't see how this works out in practice?
Ok, I defer dealing with file not found. Does that mean I know perform heavy computation and parsing on something that does not even exist. Wouldn't it be way easier to just do an early return and encode that the file exists in the type? And how does it play out to let the user wait for you doing something and you at the end coming around, well actually the input file was already missing?
And then you have some intermediate layer that needs to store all the computation you are doing until you now whether something succeeded or not. All this to save a single return statement.
It's not about saving a single return statement, even in the elvis case. How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.
Elvis ops are a small QoL change, Promises are essential to async
Exceptions (much of the time) are kind of a "catch it pass it on" logic for me, and man do I wish I didn't need to write it every time.
With networking this really shines, or really just anything async etc
> How many times have you written code along the lines of "if this isn't null do this, otherwise return. If the result of that isn't null, do this, otherwise return" etc etc.
Yeah that sucks, but why would you write it that way. I thought it is common to write "if this is null return, anyways: do this, do that."
> Promises are essential to async Exceptions
I don't see that either. If errors are specific to functions then there is only one case where I handle them, so it doesn't save something to put these checks elsewhere. If they can be accumulated over many calls, then they should be just part of the object state (like feof), so I can query them in the end.
I mean, you can just... Not annotate something if creating the relevant type is a pain. Static analysis \= type hints, and even then...
Besides, there must be some behavior you expect from this object. You could make a type that reflects this: IntIndexable or something, with an int index method and whatever else you need.
This feels like an extremely weak argument. Just think of it as self-enforcing documentation that also benefits auto-complete; what's not to love? Having an IntIndexable type seems like a great idea in your use case.
It depends on the tool. Generally, lending tools is not cheap where I live, but I once did lend a concrete sander because it was still cheaper than buying it (four digits, and likely won't ever need it again).
This is significant in general because I personally would love to get these things to code-switch into "hackernews poster" or "writer for the Economist" or "academic philosopher", but I think the "chat" format makes it impossible. The inaccessibility of this makes me want to host my own LLM...
Ultimately, all actions multinational companies take are rooted in greed.
Questioning that feels a lil naive?
Are you honestly of the opinion that big tech isn't primarily motivated by money and is instead being run like a family business with an upstanding owner that has the well-being of their employees at heart?
Being motivated by money isn't greed. Per Merriam-Webster, greed is an "excessive desire for more of something (such as money) than is needed". The key qualifiers there are excessive and more than is needed. How do we determine what excessive employment is?
I'm not even sure how companies can be greedy. Many animals will gorge themselves on food far beyond what they "need" in the moment. There's nothing guaranteeing their next meal, so it's an adaptive strategy. In a competitive free market, growth is a survival strategy. Companies can and do die when their old sources of revenue decline and they failed to discover and grow new sources. Not only do they lose out on profits, but they have to fire employees. Avoiding or minimizing layoffs and the toll they take on lives is absolutely something many executives and managers have in mind, even at large corporations, when running a business.
We don't normally ascribe greed to animals, and it doesn't make much sense to do so for corporations, particularly commercial corporations. But to the extent we can equivocate the entity and the people who manage it, underlying motivations are mixed, complicated, and varied.
And I'd argue that not all corporations, even multinationals, are similarly aggressive and "ruthless", so clearly there are complex social dynamics beyond profit maximization. Corporations aren't moral agents in the same way we consider people, yet they're not pure profit maximizing automatons, either.
> Being motivated by money isn't greed. Per Merriam-Webster, greed is an "excessive desire for more of something (such as money) than is needed". The key qualifiers there are excessive and more than is needed. How do we determine what excessive employment is?
Turn it around. How do we determine what "enough" is? Ask any business person who is beholden to shareholders to define "enough" and they will tell you there is no such word.
> How do we determine what excessive employment is?
Idk perhaps we have a slight hint in the tens of thousands of workers Microsoft _alone_ has laid off in the past year? I'm sure there is no way to intuit that big tech has indeed been over hiring with a clear disregard for its individuals beyond their utility at fixed points in time.
Yeah, the parent comments feel confused, it's kind of a truism that corporations make decisions based on greed. Capitalism, at it's best, tries to align personal/corporate self-interest with the interests of society. If you can't beat 'em, try to direct their interest towards things that benefit society. Keyword here is "try", I mean it's better than feudal lords pursuing self interest by constantly killing each other. The article does a good job of showing how that drive has really made a mess of the job market, and criticizing it because it blames all this stuff on corporate greed is really confusing since both critics and proponents of capitalism agree corporate decisions are all driven by self-interest, they just disagree on the outcomes.
They're identifying a driving force, greed, behind a range of actions. That's no more "unfalsifiable" than the claim that gravity is variously responsible for objects falling, orbits, spherically symmetric bodies, and stars collapsing.
So what would be impossible to explain in a world where “corporate greed” is indeed what causes all these things? The answer can’t be “nothing”—or “corporate greed” doesn’t mean anything.
I can say, for example, that under gravity, an object will not accelerate upwards when entering else stays down; if you show me that happening, I either have to say gravity didn’t cause it, or that gravity is not what we thought it was (and we should probably get a new word for whatever it has).
Any corporate behavior that doesn’t lead fairly directly to increased share price, profit, revenues, or market share would qualify.
But in the American corporate model, corporations almost by definition don’t do muck of that, because there’s an entrenched belief that increasing shareholder value is their primary mission. Positions to the contrary, like https://corpgov.law.harvard.edu/2012/06/26/the-shareholder-v..., are not widely understood or accepted.
The argument your link suggests is legal, not empirical. Legally speaking, there is no mandate, and acting like there is is almost surely bad for society. So I don't disagree there.
And as to the existence of exceptions, that is what makes humanities hard. Unlike physics, it is never all, it's always most, it's always shades and never direct. I use absolutist words in these discussions because it makes the points stick better, but I obviously do not mean them totally.
I think corporations maximizing profit is the default, and so writing an op-ed about how corporate greed caused something to happen seems pretty dumb to me.
How is this framing unfalsifiable? It is up to you to demonstrate that. Otherwise, I question whether you even understand what falsifiability means and why it is relevant.
Something can be falsifiable without being false. F=ma is falsifiable but not false. With humanities stuff it's less clear cut, but I'm inclined to be skeptical of ideas that explain too many things.
Falsifiability is relevant because I'm not saying the framing is wrong (I'm not even convinced it can possibly be proven wrong), I'm saying it's not very useful. In practice this has the same effect as me saying that "corporate greed" is axiomatic, so blaming it for things is like blaming water for flowing downhill.
It would be much more productive to frame this as an example, say, of market failure. Or a discussion of short-term thinking, or lacking negative feedback. All would be interesting.
PS: the author has now stated his post was AI slop written to make the front page of HN. I feel extremely validated.
Blender is nothing like chromium. It's not made by a big company, it sprung up in an extremely for-profit niche (and it has like 4 serious competitors that are all actively in use)
