Fork me on GitHub

Good morning!

Alex J Henderson09:11:27

morning, nice to get some sun, blue sky & frost for a change

👍 3

y'know i was thinking about the whole 'simple made easy' thing and much as it pains me to say it but if you follow that idea to its conclusion i'm p sure you end up with monads


although concede that this may be a form of the 'everything is a monad once you start thinking about monads' fallacy


I am not sure that's true at all. Please go on @alex.lynham


well the problem of composition gets pushed from programmer discipline onto the compiler


That seems impossible.


A compiler cannot prove that your program is composable.


but if your program is structured as a bunch of monadic functions then they are provably composable


But it didn't take out discipline in that case.


It also doesn't make the composition useful.


it automated most of the discipline, but it didn't make the programmer obsolete


🙈 6
😂 3

pushing as much discipline as possible onto the compiler seems like a good thing - humans are not very good at it


How is this different from programming against interfaces?


yeah this is kinda what i'm seeing from trying to a) scale out something in js/ts which is eek as always b) continually field questions about code style/how to handover


if you instead shrug and go 'the monads drive you to an opinionated pattern' then other people have to go that way and the compiler will force them to do so


& it's not incompatible with the data-first orientation of e.g. clojure a lens is kinda just a fancy get-in :D


though equally i do wonder if i'm driven in this direction by the limitations of the typescript language and whether in cljs i'd be like eh not a problem


I know it gives me a warm glow when the business value I provide is mathematically rigourous

😂 3

I mean, how do monads make you simple. Let's think of the places where things get rough, like I/O.


In clojure I'd consider code simple if it used a Stream or Reader/Writer, and then there were function(s) which process that. I could complect those same functions by taking a filename string and internally creating the interface. Monads seem no different?


no, but you get the type guarantee that you can just say

pipe thing1 thing2 thing3 thing4
to get your result


i have a system map and a function that takes that and interacts with the database, i make it a Reader. i make every fn like that a Reader, then i can chain a bunch of them together as one composed Reader


it's like the kinda stuff you can do with the threading macros in clj, just typesafe and with a context that may or may not represent external dependencies


the monad insulates your from plumbing code, in a similar way to how transducers let you focus on the reduction rather than the transport


and when you use it, you know your functions will compose nicely - it's really just another sort of interface


^ a better explanation than mine haha


lots of the monad instance definitions are embarrassingly simple - e.g. in the sequence monad return = (fn [v] [v])and bind = mapcat, and you would use them anyway if you were composing functions over sequences, but the common interface lets you compose your functions without even thinking about it, and further even lets you compose the effects represented by particular monad types (i.e. monad transformers or compound monads), and if you have a language which supports macros, then a bind syntax makes all the plumbing just disappear into the background


but back to simple made easy


I think it’d be hard to argue that monads aren’t simple; but wouldn’t that be true of essentially any elegant mathematical concept governed by a small set of rigorously distinct axioms?


well... yeah


that's what i mean


i think it would be very hard to argue that spec is more simple than monads for ex


and given the selector stuff is going in the direction of lenses too 🤷


"One day I will find the right words, and they will be simple."


the quest continues


Well, I wonder if your feeling is essentially because a large part of mathematics essentially boils down to being a rigorous discipline for decomposing things into small pieces and composing them together. Finding the simplest formulation of an idea etc. Therefore anything sufficiently mirroring mathematical formalisms will almost by definition be simple in the sense Rich means. I think spec meets actually meets a similar theoretical standard to monads. Though monads and spec tackle different problems so it’s a bit apples and oranges, and unfair to say monads are simpler (better or more elegant) than spec, because the complexity of the initial problem is different. Still, spec is based on pretty rigorous foundations (parsing with derivatives) which describes how specs can be composed from simple predicate functions. I also think when you’re comparing monads to spec there; you’re actually comparing the trade offs in the implementations rather than the theoretic underpinnings. spec definitely makes a bunch of easy compromises by complecting certain non-theoretical things. For example being able to reuse specs for generative testing, or having a global registry of specs etc, maybe also the syntax being a bit verbose etc.


yeah that's fair


i guess i've used both and found monads + plumatic schema to be the most natural fit for what i want to do but maybe the crossover between monads + spec isn't quite as clear cut as it feels to me


they feel like they sit enough in the same space that they don't coexist well


whereas schema is hands-off enough to be a natural build on the essential power of homoiconicity for the kinda serialisation/deserialisation/run time validation i wanna do in a composable way :thinking_face:


I don’t think of monads and spec as being particularly related. The closest I can probably put my finger on is that in a strongly type checked language like Haskell, a monad, or essentially any pattern imposed in types, would prevent you from doing a bunch of things (they’d also imply you can do other things of course). Specs I guess are about you preventing certain shapes of data. Also both are compositional systems,… so perhaps similar in those ways; but ultimately I think very different. I’d say spec is more similar to type systems than to monads (which are in Haskell at least an abstraction expressed as types within that type system). Monads enable a specific type of composition; but I’d say the typed lambda calculus is really the thing providing the compositional similarity between monads and spec that I think you’re highlighting.


but lots of faff to get all the types lined up


so it's not easy


hence my original shower thought


@mccraigmccraig where can I learn more about this? any particular book or other resource you would recommend?


there isn't a single resource which really gelled the concepts for me... there are a million impenetrable articles around the web, but they mostly didn't help me. helped some, but probably most important was playing with code particulary funcool/cats and its deferred monad , perhaps because that was directly relevant to the problem i had at the time (building an async codebase)


i’ll look at these


the haskell book is.... okay? it's still in prerelease tho


this is the one that made it make sense for me that and working with funcool/cats


oh, that's the original paper which kicked it all off isn't it @alex.lynham ?


yes it is, surprisingly readable too


I've heard good things about - haven't had a chance to read it though


that's the one i mean ^ it's still prerelease tho and quite dense


it’s as ready as it’ll be afaik? the authors are no longer speaking to each other

Ben Hammond14:11:24

in a > we've had a falling out/splitting up sense, or just a > we independently (and amicably) moved on to other projects sense?


IIRC I got the impression that one of the authors was a chud


Might be wrong about that


yeah there might have been some issue around all the white supremacy stuff in haskell


iirc they took different positions on the whole lambdaconf thing


He is super toxic and treated her like crap. She no longer gets money from the sales of the book as they came to some kind of settlement/agreement.


there were lawyers involved


okay, won't recommend that book in future then


what an arsehole


To be fair, it is a good book. But Julie Moronuki has also written a book with a guy called Chris who probably isn't a knob


what is it about the haskell community, sheesh


to quote lisa simpson, "this is why we can't have nice things"


there are two Chrises in the story, coauthor of the Haskell Book is Chris Allen, Joy of Haskell is co-written with Chris Martin:


well it was worth what i paid for it i guess, although like craig i found it was other things that cemented the concepts better tbh


as an aside, p sure ~43 mins into the Maybe Not talk, Rich is talking about lenses


off topic... but does someone know how to reach Sam Aaron, of Overtone fame? I have sent him several DM's on twitter already, but no response unfortunately.


Doesn't he do training?


No, perhaps not. I'd grab his email from github commits perhaps?


Morning everyone!


How would you model this in clojure?


(input.get() & 0xFF)
                | ((input.get() & 0xFF) << 8)
                | ((input.get() & 0xFF) << 16)
                | ((input.get() & 0xFF) << 24)


I'll ask in beginners too 🙂


bit-and , bit-or and bit-shift-left


Found my answer in #beginners 🙂