*supported

yeah I suppose. I'm suspicious that comparator/equality is such an important part that I would usually want to control it explicitly

rather than side-step with meta

it gets painful when you have nested objects with keys which you want to discount from equality, or if you need to use objects with sets or as keys in maps

Snippets for articles are always taken from exernal projects (working and tested), with the full project code available in a GitHub repository and a link in the blog to that repository. Its ensures that people have all the details. I havent use klipse yet in cryogen.

you can load gists and libraries in klipse via data-gist-id and data-external-libs and other attributes

https://book.klipse.tech/interactive_clojure[script]_code_snippets.html

I've always taken code I developed elsewhere first, so I've not had a problem with testing it

I'd need to look at the code to see if the extra attributes are even supported 🙂

but yeah, in general I tend to write code or whatever externally, and then paste it into the post

another thing I've used was http://www.gravizo.com/

similar problem: have to write code externally, then paste into the article

Thanks =)…

fyi looking up asciidoc with clojure landed me there: https://github.com/Olical/blog

We use is a lot at JUXT

is it accurate though - i have sometimes thought of them as generalising the binding-form init-expr relationship in a clojure let, but i don't get how they are equivalent to a java ; ?

@U0524B4UW It's not accurate at all. At the very very loosest level, in the sense of "do this, then do this, then do this", there is the most tenuous of associations, but this, combined with the idea of describing ; as an "operator", made me laugh 🙂

ha, i guess in haskell, with it's pervasive laziness, you don't really get any guarantees that anything will happen in any particular order, unless you sequence operations with a monad, so maybe that's what they are trying to get at

The semi-colon thing is quite a common trope I’ve heard mentioned a few times. Here it’s just framed in a humorous antagonistic way but I’ve seen it meant sincerely too. I think it can also be quite an effective lie on the way to understanding monads, in that: 1. It points to the semi-colon as being a bit like an operator; which is a perspective most people won’t have considered. 2. It points to the monad as being like the thing between the steps; the thing that bind’s them together. 3. It illustrates that things can be composed/sequenced together. 4. You can then point to other things which can in principle being composed in the same way… error’s, state, maybe etc. Obviously it’s at best only a half truth; and doesn’t point to the laws that govern their use.

It’s certainly a much better analogy than monads are like 🌯 😁

you take a chicken burrito, you bind the ecosystem, now you have a beef burrito - you are bind, the ecosystem is a monadic function, just another monoid in the category of endofunctors 🐓🌯->:man-facepalming::partly_sunny_rain:🚜->🐮🌯

i think this points exactly to what annoys me about monads, thanks for the mental shortcut 😄

care to elaborate on what annoys you about them?

From where I'm sitting, they're an extremely elaborate way to achieve something other languages do out of the box.

(Possibly the fault of the source I used to learn Haskell; I'm at the stage where I can write something that works, but I don't see the benefits of the components that make the language the way it is)

Some languages grab you, some don't. The more I write Haskell, the more it feels like sitting on something extremely prickly and itchy: the discomfort is not great, but so annoying you want to run away screaming. The things I do like about it are pattern matching and a more expressive type system. At some point I'm gonna try ocaml, but at the moment I have other things to do.

@U82DUDVMH To some degree that’s fair — however it also kind of misses point in that: 1. They provide an abstraction across things those other languages treat as different, and kind of unknowingly did. 2. Haskell was designed to be pure wrt side effects; lazily evaluated, and strongly typed. Early versions wouldn’t even let you make side effects at all. Given that Haskell was and still is really a CS research project, it was an unsolved problem for a long time on how to “fire the missiles” or do anything other than make your cpu hotter. Monads provided a novel solution to the problem of doing useful things when you’ve purposefully tied your hands behind your back with the constraints of laziness, strong types, and purity; along with being an elegant abstraction applicable to other things too. Haskell’s motto is avoid success at all costs… I think they’re kind of failing to deliver on that promise; but it perhaps describes why you don’t like it 🙂

i haven't written any real haskell - but i have found the monad pattern useful for structuring some code in clojure and it keeps popping up as a way of thinking about some problems

I think Ocaml is a little more pragmatic and are more willing to consider the costs of their principles than in Haskell.

Yeah monads can definitely be useful outside of haskell

Personal tastes can't be fair.

It does not apply as a category.

I'm not interested in evaluating Haskell as "which language is objectively the best" because I think this kind of categorising tools is stupid

I strongly appreciate what monads do for Haskell

Haskell certainly doesn’t consider itself objectively the best… Some of their vocal users do; but the designers definitely don’t.

I also appreciate purity as a way of thinking about your functions, helping you split the problem into subproblems, and keeping things easy to mentally digest

Haskell has been amazing as a language research project

I also appreciate the problem with concurrency, and having to instruct your program that "this instruction comes after that, but for everything else it's a free-for-all"

yep 🙂 and monads are great in terms of formally explaining / defining language structure

rather than defining grammar by fiat

I found the ; analogy funny and apt, and that's about it 🙂

> I also appreciate the problem with concurrency I think that’s an area Haskell hoped to make a meaningful improvement on; and has to some degree failed to do so. They hoped that laziness/purity and the rich type information etc would allow smart compilers to parallelise work automatically; but they then found that whilst it’s ridiculously easy to apply any evaluation ordering; it’s impossibly hard to automate the parallelisation of code and make it faster. Hopefully one day they’ll solve this one; but it seems progress has been a lot slower than expected.