Writing about Haskell is Hard

Writing about Haskell is Hard(anthony.noided.media)

10 points by danidiaz 4 years ago | 5 comments

unhammer 4 years ago |

> Let’s say I wanted to introduce Jordan at work, as part of a drive for a Haskell web service. I’d have to explain to everybody what the hell Rank-N types are

If so, that's a problem of jordan's documentation. If it's documented with enough practical examples of how to get things done, and it's not buggy, no one needs to know about how it does it, or even why we have to write "forall" here. And I see from the article that it even uses generic so you can get instances derived for you (probably don't even have to add the RankNTypes pragma in your own files). Even the hand-written examples of https://github.com/AnthonySuper/jordan/blob/master/jordan/RE... don't seem to require any esoteric knowledge. But it's probably hard to write about Haskell without showing off all the fancy features that make things work under the hood :)

I remember following http://www.serpentine.com/wreq/tutorial.html years ago for work while starting out with Haskell. It introduced the absolute minimal stuff needed for lens (I didn't delve any deeper into lens than what the tutorial showed), and I was immediately productive. Now I took a quick look at the source of wreq and the first file I see has RankNTypes, GADT's, etc. and I never knew.

josephcsible 4 years ago |

Does it matter that a blog post about an advanced Haskell topic isn't understandable by people who don't know basic Haskell? You wouldn't fault a calculus textbook for being incomprehensible to someone who doesn't know algebra. How is this any different than that?

eyelidlessness 4 years ago | |

I think it depends on your intended audience. For instance, I’m coming from a TypeScript-heavy background and:

1. I fully understood almost everything in this post, which I seldom do with typical Haskell writing, but

2. I’m also interested in Haskell, but find that level of required knowledge both off-putting and interest-reducing, and

3. This article could have completely left out TypeScript examples and still been just as informative and interesting for me, because the author cared to explain it to an audience with minimal Haskell background knowledge.

ggm 4 years ago |

Writing about fnsrgle is hard. You want to explain the floofies but whe you spronge the blaly nobody can rebinnle the magrafan.

Look, it's simple. The magrafan is the problem because speexzle but watrea 24 Avery haalso fnsrgle.

This is why reading about Haskell is hard. Because you need to explain fnsrgle using ordinary words, and then explain floofing, but you cannot use blintzes to explain floofing, or concepts like higher order types, or applicative, or any of a multitude of concepts which are alas given, to understand Haskell.

Happy rebinnle-ing

throwaway81523 4 years ago |

This is weird and confusing and the typescript stuff didn't help. The author seems to advocate a voodoo approach to Haskell, where you copy/paste code without understanding what it does. This is never a good idea. If you're in a Haskell shop, rank N types aren't that far "out there", and are maybe more easily explained in GADT syntax. The GHC manual also documents them, and including a link might have been enough.[1]

It seems to me that there are much more serious barriers than rank N types to getting a useful production service running in Haskell. I think I can understand rank N types. I would not, at the moment at least, trust myself to deploy a Haskell service in production.

Jordan, on the other hand, looks pretty cool. Data.Binary had something in the same spirit using Scrap Your Boilerplate generics (iirc), but it wasn't as flexible.

[1] https://downloads.haskell.org/ghc/latest/docs/html/users_gui...