4 ms·

This is a good and well-written article, but it's worth noting that I think many of the ideas here cut slightly against the grain of current Haskell best pract

This is a good and well-written article, but it's worth noting that I think many of the ideas here cut slightly against the grain of current Haskell best practices. Which is not to say any specific part is right, but for example the entire discussion on QuickCheck is hard to really make sense of and arbitrary is a famously good use of type classes. Probably the most countercultural paragraph is the paragraph on recommending you make a fresh type rather than reuse an existing type. I think that you lose so many useful operations eschewing maybe for your uniquely named Maybe [1] that a type alias is probably a much better call there, and also captures what you meant more generically. Further, stuff like Maybe over a more specific instance works much better with valuable tools like Compose. Similarly, the redundant constraint on Empty is the sort of thing that will only trip you up in the real world. All in all, great article tho. [1]: People underestimate the compiler cost of deriving instances. It adds up very fast if you derive lots of functors and foldables in your quest for unique names everywhere.

davidmr 9y ago
Thanks for your commentary too. I’m starting to learn Haskell, and the nature of the language seems to lead to less “best practices” articles out there. Seeing knowledgeable people comment on things written by other knowledgeable people seems to be the best way to learn how Haskell is done in the wild (i.e. anything outside the text I’m learning Haskell from at the moment)!
- KirinDave 9y ago
  Full disclosure, I _like_ ConstraintKinds and constraint oriented programming in many cases, and you can find evidence of that in my comment history.
moomin 9y ago
There's quite a few people who don't like arbitrary, though, aren't there? Hedgehog is growing in popularity as an alternative to the quickcheck approach.
- KirinDave 9y ago
  I know there is a contingent of people who feel this way, but to be honest I've never heard a compelling argument out of them other than the vague complaints about type classes. You can certainly do things the way Hedgehog does and it's great. I think many of the nice parts of Hedgehog are not incompatible with quickcheck.
  - pseudonom- 9y ago
    One semi-real problem with `Arbitrary` is that quickcheck itself can only define a fairly small set of instances since it doesn't want to incur a dependency on all of Hackage. Likewise, other packages are unlikely to bring in quickcheck as a dependency just to define the instance. This means these instances must be defined in standalone packages where they're necessarily orphans. The cultural prohibition against orphans means there aren't as many of these orphan instances packages as you'd like so you can end up redefining instances in every consumer project. With the Hedgehog approach, there's no problem whatsoever with creating separate packages for these instances.
harpocrates 9y ago
> People underestimate the compiler cost of deriving instances. It adds up very fast if you derive lots of functors and foldables in your quest for unique names everywhere. Do you pay this price when you derive via a `newtype`? Or does GHC figure out that the instance it would write out would be identical (modulo coercions)?
- acomar 9y ago
  It can generate the instance for you for particular typeclasses with an extension. See DeriveGeneric and DeriveAnyClass. The penalty applies when you're unwilling to use these extensions or when you create a type with the `data` keyword.
alien_at_work 9y ago
>the entire discussion on QuickCheck is hard to really make sense of and arbitrary is a famously good use of type classes I found it understandable but for me the issue was: all the problems that author pointed out are true but you're not forced to make an instance of Arbitrary. I rarely do in my tests. But some times it really does make sense and in those cases it's nice to have.

davidmr 9y ago

Thanks for your commentary too. I’m starting to learn Haskell, and the nature of the language seems to lead to less “best practices” articles out there. Seeing knowledgeable people comment on things written by other knowledgeable people seems to be the best way to learn how Haskell is done in the wild (i.e. anything outside the text I’m learning Haskell from at the moment)!

KirinDave 9y ago
Full disclosure, I _like_ ConstraintKinds and constraint oriented programming in many cases, and you can find evidence of that in my comment history.

moomin 9y ago

There's quite a few people who don't like arbitrary, though, aren't there? Hedgehog is growing in popularity as an alternative to the quickcheck approach.

KirinDave 9y ago
I know there is a contingent of people who feel this way, but to be honest I've never heard a compelling argument out of them other than the vague complaints about type classes. You can certainly do things the way Hedgehog does and it's great. I think many of the nice parts of Hedgehog are not incompatible with quickcheck.
- pseudonom- 9y ago
  One semi-real problem with `Arbitrary` is that quickcheck itself can only define a fairly small set of instances since it doesn't want to incur a dependency on all of Hackage. Likewise, other packages are unlikely to bring in quickcheck as a dependency just to define the instance. This means these instances must be defined in standalone packages where they're necessarily orphans. The cultural prohibition against orphans means there aren't as many of these orphan instances packages as you'd like so you can end up redefining instances in every consumer project. With the Hedgehog approach, there's no problem whatsoever with creating separate packages for these instances.

harpocrates 9y ago

> People underestimate the compiler cost of deriving instances. It adds up very fast if you derive lots of functors and foldables in your quest for unique names everywhere. Do you pay this price when you derive via a `newtype`? Or does GHC figure out that the instance it would write out would be identical (modulo coercions)?

acomar 9y ago
It can generate the instance for you for particular typeclasses with an extension. See DeriveGeneric and DeriveAnyClass. The penalty applies when you're unwilling to use these extensions or when you create a type with the `data` keyword.

alien_at_work 9y ago

>the entire discussion on QuickCheck is hard to really make sense of and arbitrary is a famously good use of type classes I found it understandable but for me the issue was: all the problems that author pointed out are true but you're not forced to make an instance of Arbitrary. I rarely do in my tests. But some times it really does make sense and in those cases it's nice to have.