
Image Processing with Comonads - emillon
http://jaspervdj.be/posts/2014-11-27-comonads-image-processing.html
======
tomwilde
Why do Haskell programmers see it as a good thing to package their
abstractions in syntactic sugar?

Stop doing that. It makes it incredibly difficult to participate -- you
basically need to learn 3 syntaxes on top of Haskell's own to contribute to
any non-trivial project.

I'm referring to the article the post's author recommends:
[http://www.haskellforall.com/2013/02/you-could-have-
invented...](http://www.haskellforall.com/2013/02/you-could-have-invented-
comonads.html)

~~~
boothead
Which syntaxes are you referring to?

Without knowing which one's you mean, can I offer a suggestion: Instead of
looking at these syntaxes and more overhead, (feeling that you need to somehow
mentally parse them into whatever they de-sugar to) try to treat them more as
a chunking [1] opportunity.

So for example, when you see code in a monadic do block, don't try to mentally
de-sugar it to the function calls it results in. Rather think of it slightly
like imperative code where x <\- someMonad ~ x = someMonad(). This of course
isn't what's going on really, but in many cases it's close enough for you to
use it and move on.

[1]
[http://en.wikipedia.org/wiki/Chunking_%28psychology%29](http://en.wikipedia.org/wiki/Chunking_%28psychology%29)

~~~
tomwilde
Thanks. I am referring to, for instance, the 'method notation' introduced in
that article.

I think I know what you mean by chunking. It is my understanding that it is a
counter-productive thing, though. Just like how with 'frameworks' imperative
programmers lose perception of the technical debt they incur by not knowing
what their code actually does.

Maybe this line of thought is not universal but I'd presume the majority of
programmers would be afraid to submit code to a project where they don't
really know the notational mix and syntactic sugar in use.

~~~
tel
Syntax sugar in Haskell tends to be different than other languages. Since it's
essentially just do-notation and do-notation follows monads and monads are
required to follow a hearty chunk of behavioral laws... It's actually quite
similar across the board what do-notation means. This makes chunking _far_
more effective.

------
vinkelhake
Seeing as this was presented as an example of how comonads can be used in
real-world scenarios: what's the performance like?

