unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Blake Shaw <blake@nonconstructivism.com>, jgart <jgart@dismail.de>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Guix Documentation Meetup
Date: Mon, 13 Dec 2021 09:29:34 +0100	[thread overview]
Message-ID: <86lf0osya9.fsf@gmail.com> (raw)
In-Reply-To: <87y24s13u8.fsf@nonconstructivism.com>

Hi,

On Sat, 11 Dec 2021 at 05:40, Blake Shaw <blake@nonconstructivism.com> wrote:

> --
> tldr: is there also room to discuss contributing -- and possibly doing a
> sizeable makeover to -- the *Guile* documentation? If so, I could give a
> short 5 - 10 minutes presentation of what I think should be done (and
> would volunteer to do).
> --

Cool!

Minor comments trying to feed this worth proposal.


> I don't know if this is the correct forum for it, but I personally think
> the biggest documentation obstacle in Guix at the moment isn't so much
> in Guix, but instead in Guile. I found Guix via SICP & Racket about a
> year ago, and I remained a happy Racket hacker until a couple months ago
> when I decided to devote my free time to learning Guile in hopes of
> graduating to a Guix sensei one day.

I agree that the learning path in Guile land is not always smooth.
However, I do not think mastering Guile and/or its specificity is a
requirement to be a “Guix sensei”.  Obviously, better Guile
documentation improves the ecosystem, then it is an overall better. :-)


> While I've come to love Guile, compared to my experience with Racket its
> been quite burdensome for me to get in the hang of, something I attribute
> primarily to the structure of the docs, and not due to it being in any
> way more difficult than Racket. While with Racket I was writing
> useful programs in the standard #lang within my first week, with Guile
> I often find that what should be almost trivial winds up with a lot of
> time lost just trying to navigate and understand the docs. When I do
> figure things out, it turns out to be no more difficult than the equivalent
> in Racket, but a lack of consistency in the path that leads there in the
> docs cause hangups, which has made trivial scripts that should take an hour
> become weekend projects.

Well, I am not convinced it is because the structure of the docs.
Instead, I think it is because it is missing docs. :-)

If we compare apple to apple, here are the entry points:

    https://docs.racket-lang.org/
    https://www.gnu.org/software/guile/learn/

and so the Guile manual

    https://www.gnu.org/software/guile/manual/guile.html

is a reference manual, which correspond to, mainly

    https://docs.racket-lang.org/reference/

and also,

    https://docs.racket-lang.org/guide/

I am not convinced you started Racket by these ones. ;-)

Indeed, one document on the Guile side vs two documents on Racket side;
the Guile manual could be split, I do not know if the core issue here.
Instead, IMHO, what is missing are all the others. :-) For instance,

    https://htdp.org/

which is a really smooth introduction.  Somehow, it appears to me
that it is missing an introduction, a similar document as,

     https://www.gnu.org/software/emacs/manual/html_mono/eintr.html


> I know this isn't the Guile list, but when I've written on this topic in
> the IRC I've had no response, which make me think docs could be a
> bit of a bikeshedding topic in the community. But as Guile is
> fundamental to Guix and theres a lot of crossover btwn the communities,
> it seems like this could be a good time to raise these suggestions.

I agree.  For what it is worth, I tried once to quickly explain monad,
with the aim of “Store Monad“ in mind,

    https://guix.gnu.org/manual/devel/en/guix.html#The-Store-Monad

After several discussions with strong Guix hackers, it appears to me
that they missed the general concept of monad, at least it was vague.
Therefore, I tried to write a simple explanation,

    https://simon.tournier.info/posts/2021-02-03-monad.html

Bah, the other part has never seen the light, another story. :-)  Long
time ago, Pierre wrote down a quick introduction to Scheme, which ended
into the Cookbook,

    https://guix.gnu.org/cookbook/en/guix-cookbook.html#Scheme-tutorials

From my point of view, the missing documentation is the one between
newcomer and Reference manual.  For instance, setup a Guix/Guile
environment is not straightforward; Geiser helps, but even after some
time, I am often still fighting against it, and I do not know what
exists outside the Emacs world.


On the Guile land, one feature which really annoys me is the poor
discoverability from REPL; for an instance,

--8<---------------cut here---------------start------------->8---
$ guix repl
scheme@(guix-user)> ,a fold-packages
scheme@(guix-user)> ,use(gnu packages)
scheme@(guix-user)> ,a fold-packages
(gnu packages): fold-packages	#<procedure fold-packages (proc init #:optional modules #:key select?)>
scheme@(guix-user)> ,d fold-packages
Call (PROC PACKAGE RESULT) for each available package defined in one of
MODULES that matches SELECT?, using INIT as the initial value of RESULT.  It
is guaranteed to never traverse the same package twice.
--8<---------------cut here---------------end--------------->8---

well, IPython, GHCi, UTop (to name some I use) provide a complete
different experience.  Well, maybe resuming this discussion [1] is
worth.

1: <https://yhetil.org/guix/86d00evkmr.fsf@gmail.com/>


> I've jotted down some notes on several concrete examples of where the docs
> diverge from stylistic consistency, as well as some light analysis as to
> why such seemingly small inconsistencies can lead to such hangups in the learning
> process. If folks would be interested in me presenting a short 5-10min
> presentation of these notes, I'd be happy to share.

I would be interested to listen your ideas, here, there or overthere. :-)


Cheers,
simon




  parent reply	other threads:[~2021-12-13  8:36 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 22:40 Guix Documentation Meetup Blake Shaw
2021-12-10 23:18 ` Ryan Prior
2021-12-11 18:55   ` Katherine Cox-Buday
     [not found]     ` <87lf0q2m7n.fsf@nonconstructivism.com>
2021-12-13  3:50       ` Katherine Cox-Buday
2021-12-30 21:52         ` adriano
2022-01-06 15:58           ` Katherine Cox-Buday
2021-12-13  8:29 ` zimoun [this message]
2021-12-14 16:01   ` Katherine Cox-Buday
2021-12-14 17:38     ` Luis Felipe
2021-12-14 17:52       ` Katherine Cox-Buday
2021-12-20 17:45 ` Guile documentation Ludovic Courtès
2021-12-21 11:01   ` Blake Shaw
2021-12-21  6:41 ` Guix Documentation Meetup adriano
  -- strict thread matches above, loose matches on Subject: below --
2022-03-10 17:02 Raghav Gururajan
2022-03-10 17:11 ` Raghav Gururajan
     [not found] <mailman.34870.1641617883.18145.guix-devel@gnu.org>
2022-01-08  8:42 ` calcium
2022-01-08 11:35   ` Ricardo Wurmus
2022-01-08 11:49     ` calcium
2022-01-08 16:24     ` Matt
2022-01-08 18:58       ` Ricardo Wurmus
2022-01-08 19:06       ` Leo Famulari
2022-01-09 21:12         ` Matt
2022-01-10  9:05           ` André A. Gomes
2022-01-10 13:40             ` Matt
2022-01-10 16:05               ` André A. Gomes
2022-01-11 18:45                 ` Matt
2022-01-12 18:41           ` Leo Famulari
2022-01-13  0:04             ` Matt
2022-01-13  0:22       ` Leo Famulari
2022-01-13 13:15         ` ilmu
2022-01-08 13:41   ` Matt
2022-01-08 14:09     ` Julien Lepiller
2022-01-08 14:54       ` Matt
2022-01-08 14:39     ` Josselin Poiret
2022-01-08  4:52 Matt
2022-01-10  9:47 ` Oliver Propst
2022-01-10 13:15   ` Matt
2022-01-11 16:24     ` jgart
2022-01-12  0:59       ` Matt
2022-01-12  1:20         ` jgart
2022-01-12  2:57           ` Matt
2022-01-12  3:10             ` Matt
2021-12-13 13:45 Blake Shaw
2021-12-13 15:55 ` Katherine Cox-Buday
2021-12-13 12:41 Blake Shaw
2021-12-13 12:33 Blake Shaw
2021-12-15 17:37 ` Blake Shaw
2021-12-15 19:12   ` zimoun
2021-12-15 22:37     ` jgart
2021-12-11  1:42 Blake Shaw
2021-12-09  9:28 jgart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86lf0osya9.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=blake@nonconstructivism.com \
    --cc=guix-devel@gnu.org \
    --cc=jgart@dismail.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).