Re: Proposal: Deep Dive into the Guile Docs & Makeover Proposal

[Blake Shaw <blake@nonconstructivism.com>]

Daniel Tornabene <d.t.peters777@gmail.com> writes:

> just a simple guile user here, sitting next to my printed out 2.2.6
> manual. I'm interested in this topic as well though I'd say my own
> experience with the documentation is less a problem with it as it is
> then with its organization. Perhaps I'm an anomaly, but I enjoy and
> appreciate a manual with significant, bordering on completeness of
> coverage of not simply the language, but the relevant api.  I'd also
> add that the small examples littered throughout the text which add to
> the length have however been quite helpful to me personally, and
> demonstrating multiple possible paths one might take given a language
> construct is a good thing in a lisp, especially one that attempts to
> be as approachable as guile does. The comparisons to racket and rust
> printed manuals are enlightening though, and I'd be very interested in
> a "close reading", as it were, that susses out the structural and
> stylistic details in a comparative way. Successfully done that in and
> of itself would be both a major accomplishment for our corner of the
> PL world and other software communities with a serious commitment to
> documentation and even to non programmers wanting to understand how
> such complicated endeavours such as a community developed programming
> language effectively communicates information and practices. 
>

for sure, just to clarify as a few folks have commented on this --
& so it seems the summary i provided may have been misleading -- my
talk will deal primarily with the structure of the docs, not what can
be cut out. i'm really focused here on the user experience, and cutting
out not length but instead inconsistencies: in language, layout, order,
and style so that users can anticipate a general cadence and thus
navigate with greater ease. in fact, i think the end result may be a
longer manual, but one in which users will have a simplified mental
map, so that amidst hacking you can navigate whether by paper of
texinfo to what you're looking for, and be in and out, back to the repl
as seamlessly as possible. the hope is to cut out downtime caused while
consulting the docs, while also preserving the deeper more essayistic
nuggets for when its time to take a plunge. 

i will offer suggestions for sets of guidelines dealing with various
aspects of structure, that intend to both add and preserve existing
structure. so it's kind of a 'functor' approach to structuring the
docs. this is also where the feedback session will be key, as longtime
users will have the knowledge of what would be *objectively bad*.

so in a sense, I will offer *weak* or abstract guidelines, and for those
that the community agrees are beneficial we should focus on collectively
strengthening them such that they may compose as a system that is
general, concrete, and true to the language itself. 

-- 
“In girum imus nocte et consumimur igni”