Unhelpful library documentation

I don't know if everyone has seen this, so I thought I'd mention this: http://lukeplant.me.uk/blog.php?id=1107301692
"Haskell API docs suck. A lot."
"Haskell API documentation is very lacking for newbies. For instance, I want to understand how to create and use regexes. If you start at Text.Regex.Posix documentation, it tells you that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all!" "Since Haskell libraries are almost always implemented by Haskell gurus, and they implement them with themselves in mind (I have no objection to this, they are enthusiasts working for free), they use lots of clever code and advanced Haskell techniques. But this means that if you want people to actually use these libraries (and by consequence Haskell itself), the documentation for Haskell libraries has to be about an order of magnitude better than anything you'd find anywhere else. I suspect it is at least an order of magnitude worse than for something like .NET APIs, which means that relatively speaking the documentation of Haskell is currently in an absolutely dire state." These are all interesting points, but I found most interesting the conclusion: "Moving forward, I guess one problem is contributing to a library's documentation. There is nothing on the API doc pages that shows you how to do this. I suspect you need to check out the source with darcs (not something I do normally, I just use cabal) and then start email patches or something. Even then, I don't know if I would contribute any documentation -- 'howto' style documentation seems out of place on the API pages, but it is desperately needed." So, what can be done here? Offhand, I want to suggest adding a link to some sort of tutorial module or wiki page. Each page *does* mention that 'Maintainer libraries@haskell.org', but this really isn't helpful; it doesn't tell you where to get the original library source code, how to edit, what libraries@ *is* (anyone with a brain in their head is going to know that libraries@ is some sort of group interface, and is going to refrain from emailing it until they know that they aren't cluelessly spamming/offending potentially hundreds of Haskellers), and so on. Even better would be a link in the Description to the source: 'Control.Concurrent.QSemN is a module in the concurrent package; you can 'darcs get' it from http://foo.... For contributing, please module Contributing/wiki page haskell.org/wiki/Contributing_to_libraries', etc. Thoughts? -- gwern plutonium industrial UHF Reaction and data POCSAG Finksburg Merlin fake

Gwern Branwen wrote:
I don't know if everyone has seen this, so I thought I'd mention this: http://lukeplant.me.uk/blog.php?id=1107301692
"Haskell API docs suck. A lot."
"Haskell API documentation is very lacking for newbies. For instance, I want to understand how to create and use regexes. If you start at Text.Regex.Posix documentation, it tells you that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all!"
"Since Haskell libraries are almost always implemented by Haskell gurus, and they implement them with themselves in mind (I have no objection to this, they are enthusiasts working for free), they use lots of clever code and advanced Haskell techniques. But this means that if you want people to actually use these libraries (and by consequence Haskell itself), the documentation for Haskell libraries has to be about an order of magnitude better than anything you'd find anywhere else. I suspect it is at least an order of magnitude worse than for something like .NET APIs, which means that relatively speaking the documentation of Haskell is currently in an absolutely dire state."
These are all interesting points, but I found most interesting the conclusion:
"Moving forward, I guess one problem is contributing to a library's documentation. There is nothing on the API doc pages that shows you how to do this. I suspect you need to check out the source with darcs (not something I do normally, I just use cabal) and then start email patches or something. Even then, I don't know if I would contribute any documentation -- 'howto' style documentation seems out of place on the API pages, but it is desperately needed."
So, what can be done here? Offhand, I want to suggest adding a link to some sort of tutorial module or wiki page. Each page *does* mention that 'Maintainer libraries@haskell.org', but this really isn't helpful; it doesn't tell you where to get the original library source code, how to edit, what libraries@ *is* (anyone with a brain in their head is going to know that libraries@ is some sort of group interface, and is going to refrain from emailing it until they know that they aren't cluelessly spamming/offending potentially hundreds of Haskellers), and so on.
Even better would be a link in the Description to the source: 'Control.Concurrent.QSemN is a module in the concurrent package; you can 'darcs get' it from http://foo.... For contributing, please module Contributing/wiki page haskell.org/wiki/Contributing_to_libraries', etc.
Thoughts?
I think the haskell.org wiki would be a good place to document how to use APIs. In my opinion the Haddock-generated documents are better kept purely as reference documentation with a pointer to the entry-point on the wiki for the library in question. I suppose something similar should be encouraged for libraries on Hackage as well. Here's what I'll do with the only library I have on there (dataenc): 1. Set the 'homepage' cabal property to point to the wiki page I created on the wiki to describe the library (http://www.haskell.org/haskellwiki/Library/Data_encoding). 2. Add a link in the Haddock comments of every module to point to the same page. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts

On 2008.08.09 21:33:01 +0100, Magnus Therning
I think the haskell.org wiki would be a good place to document how to use APIs. In my opinion the Haddock-generated documents are better kept purely as reference documentation with a pointer to the entry-point on the wiki for the library in question.
That seems like one of the best choices to me as well. Thoughts from everyone else? Suggestions about how to actually do it? (Do we add a link to the introduction, hack haddock output in some way to add links at the bottom perhaps, or just use the usual headers - is 'homepage' one of the possible fields?)
I suppose something similar should be encouraged for libraries on Hackage as well. Here's what I'll do with the only library I have on there (dataenc):
1. Set the 'homepage' cabal property to point to the wiki page I created on the wiki to describe the library (http://www.haskell.org/haskellwiki/Library/Data_encoding). 2. Add a link in the Haddock comments of every module to point to the same page.
/M
A useful example; post a link to the Haddock when you do it, would you? -- gwern Goodwin Bunny Blowpipe Montenegro Bechtel SLIP SAAM NSA Ufologico Comverse

Gwern Branwen wrote:
On 2008.08.09 21:33:01 +0100, Magnus Therning
scribbled 4.2K characters: ...
[..]
I suppose something similar should be encouraged for libraries on Hackage as well. Here's what I'll do with the only library I have on there (dataenc):
1. Set the 'homepage' cabal property to point to the wiki page I created on the wiki to describe the library (http://www.haskell.org/haskellwiki/Library/Data_encoding). 2. Add a link in the Haddock comments of every module to point to the same page.
/M
A useful example; post a link to the Haddock when you do it, would you?
It took me a while to get around to get around to it, but now it's done. I've just pushed the code to http://code.haskell.org/dataenc/devo/ and the package is uploaded to hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.11.1). The documentation will be rebuilt soon (I hope :-). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus@therning.org http://therning.org/magnus Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts

Lowering the barrier to entry for people to contribute to library documentation would be a Very Good Thing. There are lots of intelligent and motivated people out there! Fortunately, we have the Haskell wiki. Magnus's comments look spot-on to me. | I think the haskell.org wiki would be a good place to document how to | use APIs. In my opinion the Haddock-generated documents are better kept | purely as reference documentation with a pointer to the entry-point on | the wiki for the library in question. We could encourage every library author to: * Establish a page on the Haskell Wiki for the library (http://www.haskell.org/haskellwiki/Library/Data_encoding). * Set the 'homepage' cabal property to point to that wiki page (or, if the home page is elsewhere, that home page can point to the wiki) * Add a link in the Haddock comments of every module to point to the same page. * Make it clear that users are encouraged to write and improve the wiki documentation Perhaps such a practice should be explicitly encouraged in the guidelines for submitting a package to Hackage? Duncan, Don: perhaps these are ideas you could develop for the Haskell Platform? Simon | > These are all interesting points, but I found most interesting the | > conclusion: | > | > "Moving forward, I guess one problem is contributing to a library's | > documentation. There is nothing on the API doc pages that shows you | > how to do this. I suspect you need to check out the source with darcs | > (not something I do normally, I just use cabal) and then start email | > patches or something. Even then, I don't know if I would contribute | > any documentation -- 'howto' style documentation seems out of place on | > the API pages, but it is desperately needed." | > | > So, what can be done here? Offhand, I want to suggest adding a link to | > some sort of tutorial module or wiki page. Each page *does* mention | > that 'Maintainer libraries@haskell.org', but this really isn't | > helpful; it doesn't tell you where to get the original library source | > code, how to edit, what libraries@ *is* (anyone with a brain in their | > head is going to know that libraries@ is some sort of group interface, | > and is going to refrain from emailing it until they know that they | > aren't cluelessly spamming/offending potentially hundreds of | > Haskellers), and so on. | > | > Even better would be a link in the Description to the source: | > 'Control.Concurrent.QSemN is a module in the concurrent package; you | > can 'darcs get' it from http://foo.... For contributing, please module | > Contributing/wiki page haskell.org/wiki/Contributing_to_libraries', etc. | > | > Thoughts? | | I think the haskell.org wiki would be a good place to document how to | use APIs. In my opinion the Haddock-generated documents are better kept | purely as reference documentation with a pointer to the entry-point on | the wiki for the library in question. | | I suppose something similar should be encouraged for libraries on | Hackage as well. Here's what I'll do with the only library I have on | there (dataenc): | | 1. Set the 'homepage' cabal property to point to the wiki page I | created on the wiki to describe the library | (http://www.haskell.org/haskellwiki/Library/Data_encoding). | 2. Add a link in the Haddock comments of every module to point to the | same page. | | /M | | -- | Magnus Therning (OpenPGP: 0xAB4DFBA4) | magnus@therning.org Jabber: magnus@therning.org | http://therning.org/magnus

On Mon, 2008-08-11 at 09:25 +0100, Simon Peyton-Jones wrote:
Lowering the barrier to entry for people to contribute to library documentation would be a Very Good Thing. There are lots of intelligent and motivated people out there!
Fortunately, we have the Haskell wiki. Magnus's comments look spot-on to me.
| I think the haskell.org wiki would be a good place to document how to | use APIs. In my opinion the Haddock-generated documents are better kept | purely as reference documentation with a pointer to the entry-point on | the wiki for the library in question.
We could encourage every library author to: * Establish a page on the Haskell Wiki for the library (http://www.haskell.org/haskellwiki/Library/Data_encoding). * Set the 'homepage' cabal property to point to that wiki page (or, if the home page is elsewhere, that home page can point to the wiki) * Add a link in the Haddock comments of every module to point to the same page. * Make it clear that users are encouraged to write and improve the wiki documentation
Perhaps such a practice should be explicitly encouraged in the guidelines for submitting a package to Hackage?
Duncan, Don: perhaps these are ideas you could develop for the Haskell Platform?
Hmm. I think the 'homepage' property should point to the package's homepage. For many projects that may well be a wiki site, but bigger projects often have both a homepage and some user-editable wiki. So perhaps it wants another property for wiki links. Further, haddock can link each module or entity to a different uri: --comments-base=URL URL for a comments link on the contents and index pages --comments-module=URL URL for a comments link for each module (using the %{MODULE} var) --comments-entity=URL URL for a comments link for each entity (using the %{FILE}, %{MODULE}, %{NAME}, %{KIND} or %{LINE} vars) We should think about what convention we want there. Eg single page per package with #refs for modules, though bigger packages may want a wiki page per-module with #refs for each entity. This can mostly be encoded into the url itself with var references. The slightly annoying thing is that the urls for the base, module and entity are not necessarily derivable from each other, though in many common cases they are. Perhaps that just needs a convention (like dropping the tail of the url after %{MODULE} to get the base url) eg: wiki: http://www.haskell.org/haskellwiki/Library/Data_encoding/%{MODULE}#%{NAME} gives us: --comments-base=http://www.haskell.org/haskellwiki/Library/Data_encoding/ --comments-module=http://www.haskell.org/haskellwiki/Library/Data_encoding/%{MODULE} --comments-entity=http://www.haskell.org/haskellwiki/Library/Data_encoding/%{MODULE}#%{NAME} That is, not only did we drop "%{NAME}" to get the module one, we also dropped the "#". Another example: wiki: http://wiki.project-foo.org//?module=%{MODULE}#%{NAME} This works less well since we'd get: --comments-base=http://wiki.project-foo.org/?module= --comments-module=http://wiki.project-foo.org/?module=%{MODULE} --comments-entity=http://wiki.project-foo.org/?module=%{MODULE}#%{NAME} but perhaps it's good enough. Duncan
participants (4)
-
Duncan Coutts
-
Gwern Branwen
-
Magnus Therning
-
Simon Peyton-Jones