i don’t think i’ll ever understand monads even though I literally spent years studying category theory in grad school but I really liked this paper “What we talk about when we talk about monads” https://tomasp.net/academic/papers/monads/monads-programming.pdf
I love that it talks about cases where monads have been misapplied and the social aspects of how they’re used
(please do not try to explain monads to me and please no links to your favourite monad explanation)
my other favourite paper is "Some Were Meant for C". It's really stuck with me because it helped me understand why I feel so much love for C even though I have no desire (or ability really!) to write C programs
@cross I find C really useful for communication, for example yesterday I added a section to the README of this Rust crate explaining how it works https://github.com/rbspy/read-process-memory. It felt much simpler to use C to talk about how the crate works than Rust.
the paper helped me understand better why C is useful to me and why I often feel like I want to use C instead of Rust/Go/etc to talk about how systems programs work.
@b0rk thanks for your perspective. Would it be safe to say that, in this context, you're using C as something of a pseudo-language to describe low-level behavior?
Regarding the 'Meant for C' paper itself, an example of one of the things that I took issue with is the walk_instrs function in section 5.2, along with this text:
>This tiny piece of code is doing something that would
be completely inexpressible in any current safe language I
know.
But this doesn't follow. First, as written, it is essentially impossible to use tiny bit of code safely: For one thing, there is no guarantee that the pointer comparisons it uses are meaningful, as there's nothing that guarantees that the pos and end arguments refer to the same object. For another, there's no way to detect errors in a meaningful way. Then there's the use of unsigned as a primitive type to encode a length; there's already a perfect good type for that (size_t). In practice none of this matters (any reasonable implementation is likely going to either compile this in the expected way or provide options that let one compile it in the expected way...), but the paper was about C, not implementations.
Anyway, I digress: the thrust of the paper, to me, was a statement that C allows one to communicate in a way that other languages do not, but I think that's specious and the paper itself doesn't really support it as a conclusion.
Anyway, sorry, I don't mean to detract from your larger point, but I did not find the 'Meant for C' paper convincing.
As an aside, I wrote a response about that paper to a few colleagues a few years back where I translated the walk_insns function to idiomatic, safe Rust code. I'm sad that I didn't keep a copy of that note; in fairness, one of my colleagues wrote me back saying, "I ain't reading all of that." 😄
(it's a playground that takes a C program and lets you click on any line and inspect its memory, basically it's just a very thin wrapper around lldb)
I used C mostly because I didn't know how to provide a similar interface for Go or Rust, I just don't really understand how debuggers interact with those languages and I always get confused by it.
@b0rk@cross It should be somewhat simple. The way a debugger works for these cases is that the compiler encodes an extra translation table between the program text, the executing state of the program, and the original program text. The debugger takes queries about the program text and uses the translation table to answer the corresponding question about the program state.
The complexity mostly comes down to the fidelity of the translation table and the sensibility of the question
@b0rk@cross The biggest problem is that the translation table, and the questions debuggers support, are pretty heavily C/C++-biased, since that's those are the languages with the most robust debugger use historically
So I started studying category theory to see what the fuss was about and it turns out the connection with functional programming is really quite thin (or in any case hidden away).
@OscarCunningham@b0rk I didn't really feel I understood functional-programming monads until I'd worked through the category theory definition and some standard Haskell examples (List, Maybe, IO) in conjunction, and painstakingly matched up every part of the definitions.
But then it all went out of my head again, of course! I did keep notes, but reading and absorbing them again would probably take me almost as long as the first time round.
@b0rk I'm kinda curious, what's your framework for deciding when it's just fine to not understand something? I'm assuming you must have one if you haven't gone entirely insane by now...:D
@b0rk I wrote my masters thesis on quaternions and while most game developers use them they do not understand even a small fraction of the theory around them -- and no one expects them to do so. Monads are worse. Thanks for the link, social aspects are important here indeed.
@b0rk If only I could "like" this toot more than once. Nothing about Monads is easy to get your head around...including a 28 page paper explaining how the term is misapplied.
I have a strong suspicion that no one knows what a monad is, and those that claim they do are simply holding their nerve for longer in a game of monad-chicken.
@martinpeck I'm still waiting for the Monads Explained at 5 Levels video. They are chameleons. Some people find them useful for analytical reasons (e.g. compiler writers) and others find them useful for practical reasons (e.g. functional programmers not wanting giant param lists) but the implications on each side of this prism look wrong from the other side. So even two people who both genuinely understand them can disagree on many aspects.
It feels, to me, like an unhelpful term for this reason, or that the term "monad" should be replaced with a selection of terms that describe the different problems being addressed, or the ways the solutions address them.
Add comment