Clojurians Log v2

Good morning!

morning

👋

måning

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

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

mogge

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

^ this

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

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

😂

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

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

right

but back to simple made easy

it's simple

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. http://learnyouahaskell.com/chapters helped some, but probably most important was playing with code particulary funcool/cats and its deferred monad http://funcool.github.io/cats/latest/#manifold-deferred , perhaps because that was directly relevant to the problem i had at the time (building an async codebase)

thanks!

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 https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf that and working with funcool/cats

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

I've heard good things about https://haskellbook.com/ - haven't had a chance to read it though

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

yes it is, surprisingly readable too

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

Yup ^.

oh really?

blimey

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

this one is great as well: A History of Haskell: Being Lazy With Class https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=https%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf

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.

Mornin

and Mornin @russ.anderson

Morning everyone!

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.

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

there were lawyers involved

Found my answer in #beginners 🙂

Doesn't he do training?

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

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?