41
top 11 comments
sorted by: hot top controversial new old
[-] lysdexic@programming.dev 13 points 7 months ago

I've submitted this link because the topic is interesting to me, and !functional_programming@programming.dev is practically dead, with the last post dating back over 10 days.

For those who are down voting the contribution, be my guest and do better: submit interesting content.

[-] xmunk@sh.itjust.works 9 points 7 months ago

Lemmy has a few perpetually online perpetual assholes that down vote anything they see - give a post a few hours and you'll see the reasonable people show up.

[-] lysdexic@programming.dev 4 points 7 months ago* (last edited 7 months ago)

Honestly, I don't mind the downvotes. What puzzles me is how some people feel strongly enough about a topic to subscribe to a community, but still feel compelled to slap down contributions in a time nothing is being submitted, as if seeing no new posts is better than seeing a post that might not tickle their fancy.

It's the difference between building up and tearing down.

[-] einsteinx2@programming.dev 2 points 7 months ago

FWIW due to Lemmy’s size, I think it’s actually more common to scroll Local or All rather than Subscriptions, so you’re probably getting votes from lots of random people rather than subscribers to this community specifically.

[-] sloppy_diffuser@sh.itjust.works 4 points 7 months ago

Have an upvote. Thanks for trying. Interesting to me also, but yeah, its dead in here.

[-] demesisx@infosec.pub 12 points 7 months ago

On the latest Haskell interlude podcast, the guest was talking about how using the ReaderT monad specifically introduces safety issues. My ears perked up because I’m right in the middle of leaning on it heavily in one of my Haskell projects.

[-] mrkeen@mastodon.social 3 points 7 months ago

@demesisx @lysdexic No safety issues mentioned around ReaderT. The speaker was talking about how stacking monad transformers mtl-style can generate unnecessary closures that GHC can't optimise away.

[-] demesisx@infosec.pub 11 points 7 months ago

Thanks for the clarification.

[-] einsteinx2@programming.dev 5 points 7 months ago

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

[-] Corbin@programming.dev 1 points 7 months ago

I've recently come to appreciate monads as 2-arrows from the terminal object in a 2-category; quoting nLab:

… a monad in [a category] K is a lax 2-functor from the terminal bicategory 1 to K: the unique object * of 1 is sent to the object a, the morphism 1 becomes [the endomorphism] t, and [the unit] η and [the join] μ arise from the coherent 2-cells expressing lax functoriality.

This is a nifty demystification of the data of a monad. Why do endofunctors tend to carry monads? Because endofunctors on categories C tend to be expressible as endomorphisms in 2-categories where C is an object! Since this latter condition is typically trivial, it follows that endofunctors on C typically carry monads (and that any counterexamples depend on the structure of C and choice of 2-category.)

this post was submitted on 27 Mar 2024
41 points (87.3% liked)

Functional Programming

1389 readers
1 users here now

founded 1 year ago
MODERATORS