![]() ![]() One of the nice features of Haskell is that you can use the type system to make impossible states unrepresentable or enforce invariants to guarantee proper use. You can definitely have the build check that type signatures or doctests are correct, but anything more elaborate usually requires human intervention to keep up to date.ĭisclaimer: I'm biased here because I'm a huge proponent of documenting things well. Extensive documentation is very expensive to keep up to date with a package because documentation is difficult to machine check in general. "Small negative" - Things that turn me offĮxcellent documentation is one of the strongest signals of maintainer commitment to a package."Irrelevant" - Things I never pay attention to when judging package quality. ![]() "Small positive" - Positive features that make me more likely to adopt."Large positive" - Things that impress me.I've organized the metrics I use into five categories: Even if you are a veteran programmer in another language you still might find some useful tidbits here when approaching the Haskell ecosystem for the first time. Some of these guidelines work for other programming languages, too, but some of them are unique to Haskell. deciding whether to depend on a package at all.choosing between multiple similar packages.This post summarizes the rough heuristics that I use for evaluating Haskell packages. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |