unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Attila Lendvai <attila@lendvai.name>
To: 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 20:12:30 +0000	[thread overview]
Message-ID: <PMkbNbqoqO_VlPdTnI3voK37SRW1sKoKWNBShju_iWnmyByJPs3cGbfTEwqfo8vZ61DI2NLUv26_zIZNhkXvBApxhWBNyQVmkEsqw1G6Qjc=@lendvai.name> (raw)
In-Reply-To: <cbb8a262d0bfa72d9050fae97b0c7f2b076d186f.camel@gmail.com>

> lines of code. I think hyper-focusing on syntax to make services
> "nicer" might be the wrong approach here: You could greatly reduce the
> complexity by making them procedures instead of syntax and still keep
> most of the configuration readable to a great extent.


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.

such code is much easier to work with, especially when debugging stuff interactively (i.e. it's possible to recompile a function that will then affect every place in the code where the macrology is used).

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. the size of their expansion can also become an issue if they are used often enough.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“They muddy the water, to make it seem deep.”
	— Friedrich Nietzsche (1844–1900)



  reply	other threads:[~2023-11-29 20:13 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 [this message]
2023-11-29 23:39                 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
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='PMkbNbqoqO_VlPdTnI3voK37SRW1sKoKWNBShju_iWnmyByJPs3cGbfTEwqfo8vZ61DI2NLUv26_zIZNhkXvBApxhWBNyQVmkEsqw1G6Qjc=@lendvai.name' \
    --to=attila@lendvai.name \
    --cc=dev@jpoiret.xyz \
    --cc=edou@rdklein.fr \
    --cc=guix-devel@gnu.org \
    --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).