unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: Attila Lendvai <attila@lendvai.name>,
	Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: "Edouard Klein" <edou@rdklein.fr>,
	guix-devel@gnu.org, "Ludovic Courtès" <ludo@gnu.org>,
	"Josselin Poiret" <dev@jpoiret.xyz>
Subject: Re: Syntactic Diabetes (was Re: A friendlier API for operating-system declarations)
Date: Wed, 29 Nov 2023 15:39:17 -0800	[thread overview]
Message-ID: <87ttp4jfiy.fsf@lease-up.com> (raw)
In-Reply-To: <PMkbNbqoqO_VlPdTnI3voK37SRW1sKoKWNBShju_iWnmyByJPs3cGbfTEwqfo8vZ61DI2NLUv26_zIZNhkXvBApxhWBNyQVmkEsqw1G6Qjc=@lendvai.name>

Hi Attila,

On Wed, Nov 29 2023, Attila Lendvai wrote:

> i agree. in my experience, it's good practice in general to try to
> make a functional API as convenient as possible, and if that is still
> too verbose or cumbersome, only then add a thin layer of syntactic
> abstractions that expand to code that uses this functional API.
>
> [...]
>
> the downside of generating countless macros is that they won't show up
> in backtraces, and they cannot be found when grep'ping the codebase,
> and as such make the codebase much less approachable.

Reading your words really helped me feel that I'm not alone. You more or
less summarized my feelings about the Guix codebase, which I have been
reading now for over a year. Guile's syntax features make the code more
symbolic and less approachable to newcomers.

Of course, syntax features are helpful and necessary in some places.

Any large project like GNU Guix, however, must continue to engage a
cadre of skilled maintainers. Between Guile records and syntax features,
code can get hairy pretty fast. Some files seem to have received more
hurried attention recently. In the long run, it's not good for Guix to
make code hard to read.

Please forgive me, everyone, for speaking up. I did not follow the
discussion here at all. Attila's commentary merely resonated with me as
I tried to deal with my own shortcomings in contributing to the Guix
codebase.

Eventually, I hope to make meaningful suggestions to the bootloader
interaction with system profiles, and to the automatic "wrapping" of
executables, which is currently done by hand.

The changes Edouard and Michal may well be very valuable. Please do not
allow my comments to reflect on their well-meant ideas and hard work, or
on any other contributions to the software we love.

Thank you all for contributing to GNU Guix!

Kind regards
Felix


  reply	other threads:[~2023-11-29 23:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  8:06 A friendlier API for operating-system declarations Edouard Klein
2023-03-23 18:48 ` Josselin Poiret
2023-03-23 20:23   ` Edouard Klein
2023-03-23 21:05 ` Liliana Marie Prikler
2023-04-13  9:42 ` Ludovic Courtès
2023-05-18 14:37   ` Edouard Klein
2023-11-24 21:43 ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Edouard Klein
2023-11-24 22:50   ` Liliana Marie Prikler
2023-11-25 20:14     ` Attila Lendvai
2023-11-26  5:36       ` Michal Atlas
2023-11-26 16:49       ` Edouard Klein
2023-11-26 18:32         ` Liliana Marie Prikler
2023-11-26 20:46           ` Edouard Klein
2023-11-27 21:09             ` Liliana Marie Prikler
2023-11-29 20:12               ` Attila Lendvai
2023-11-29 23:39                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution. [this message]
2023-11-30 11:16                   ` Attila Lendvai
2023-12-01 18:18                     ` Michal Atlas
2024-02-01 13:29                     ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-02-01 19:43                       ` Liliana Marie Prikler
2024-02-01 20:30                         ` Attila Lendvai
2024-02-01 20:46                           ` Liliana Marie Prikler
2024-02-02 20:11                             ` Attila Lendvai
2024-02-01 21:02                           ` Ricardo Wurmus
2024-02-02 19:36                             ` Attila Lendvai
2024-02-02 20:21                               ` Vagrant Cascadian
2024-02-02 21:25                                 ` Attila Lendvai
2024-02-02  0:03                       ` Introducing Guix "Features"! Carlo Zancanaro
2024-02-18 15:07                       ` Introducing Guix "Features"! (Was: Syntactic Diabetes) Edouard Klein
2023-12-09 10:12         ` Syntactic Diabetes (was Re: A friendlier API for operating-system declarations) Ludovic Courtès

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=87ttp4jfiy.fsf@lease-up.com \
    --to=guix-devel@gnu.org \
    --cc=attila@lendvai.name \
    --cc=dev@jpoiret.xyz \
    --cc=edou@rdklein.fr \
    --cc=felix.lechner@lease-up.com \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    /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).