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
