Fork me on GitHub
#clojure-uk
<
2020-11-04
>
dharrigan06:11:41

Good morning!

Alex J Henderson09:11:27

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

👍 3
alexlynham09:11:12

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

alexlynham09:11:41

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

dominicm10:11:34

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

alexlynham10:11:13

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

dominicm10:11:34

That seems impossible.

dominicm10:11:04

A compiler cannot prove that your program is composable.

mccraigmccraig10:11:16

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

dominicm10:11:44

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

dominicm10:11:05

It also doesn't make the composition useful.

mccraigmccraig10:11:07

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

alexlynham10:11:18

🙈 6
😂 3
mccraigmccraig10:11:53

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

dominicm10:11:22

How is this different from programming against interfaces?

alexlynham10:11:36

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

alexlynham10:11:29

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

alexlynham10:11:59

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

alexlynham10:11:59

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

Conor11:11:45

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

😂 3
dominicm11:11:28

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

dominicm11:11:35

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?

alexlynham11:11:33

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

pipe thing1 thing2 thing3 thing4
to get your result

alexlynham11:11:39

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

alexlynham11:11:18

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

mccraigmccraig11:11:36

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

mccraigmccraig11:11:41

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

alexlynham11:11:43

^ a better explanation than mine haha

mccraigmccraig11:11:16

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

alexlynham12:11:33

but back to simple made easy

rickmoynihan22:11:06

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?

alexlynham09:11:17

well... yeah

alexlynham09:11:22

that's what i mean

alexlynham09:11:06

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

alexlynham09:11:22

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

alexlynham09:11:43

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

alexlynham09:11:47

the quest continues

rickmoynihan09:11:47

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.

alexlynham10:11:04

yeah that's fair

alexlynham10:11:56

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

alexlynham10:11:11

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

alexlynham10:11:49

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:

rickmoynihan13:11:13

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.

alexlynham12:11:46

but lots of faff to get all the types lined up

alexlynham12:11:50

so it's not easy

alexlynham12:11:00

hence my original shower thought

flefik12:11:20

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

mccraigmccraig12:11:37

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)

flefik12:11:08

i’ll look at these

alexlynham12:11:02

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

alexlynham12:11:38

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

mccraigmccraig12:11:27

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

alexlynham13:11:43

yes it is, surprisingly readable too

yogidevbear12:11:21

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

alexlynham13:11:27

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

Aleksander13:11:53

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?

Conor14:11:29

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

Conor14:11:32

Might be wrong about that

alexlynham14:11:53

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

alexlynham15:11:07

iirc they took different positions on the whole lambdaconf thing

minimal15:11:34

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.

Aleksander15:11:22

there were lawyers involved

alexlynham09:11:59

okay, won't recommend that book in future then

alexlynham09:11:02

what an arsehole

Conor09:11:38

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

alexlynham09:11:54

what is it about the haskell community, sheesh

alexlynham09:11:28

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

Aleksander10:11:08

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

alexlynham13:11:00

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

alexlynham14:11:27

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

thomas14:11:31

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.

dominicm19:11:36

Doesn't he do training?

dominicm19:11:56

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

Aleksander14:11:21

Morning everyone!

dharrigan15:11:28

How would you model this in clojure?

dharrigan15:11:30

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

dharrigan15:11:24

I'll ask in beginners too 🙂

mccraigmccraig15:11:58

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

dharrigan16:11:46

Found my answer in #beginners 🙂