but horrible to read as a normal user. Half your time is spend counting parenthesis and trying to figure out how and what to quote.
Which is why a good text editor will balance parentheses automatically and highlight macros. That being said, it is well known that macros can be abused and overused. It is considered bad style to use macros if a function would do the job too.
That being said, it is well known that macros can be abused and overused.
Which is what Guix is doing. Just look at (package), why isn't that a function taking an associated list? It's this kind of ad hoc DSL magic that makes Lisp-like languages incredible hard to read, since you never know what you are looking at.
Notice how the alist has to be backquoted so that you can put a comma in front of everything that needs to be evaluated, and how every entry in the alist has to be a pair rather than a list which requires a dot on every line. Which would you rather type out a hundred thousand times? Which would you prefer to teach to new contributors? Which would you prefer to answer questions about on a mailing list?
Which would you rather type out a hundred thousand times?
Neither. But that proofs my point, Lisp is unreadable for the average user. If your first instinct is to not use the language itself, but write your own DSL on top of it to make it readable, maybe that language ain't such a good choice.
But the whole point of Scheme is that the syntax is simple enough that you _can_ do metalinguistic abstraction. That was a deliberate design choice, not an accident. In most other languages you have to stoop to using some other parser and interpreter for data files, rather than reusing the excellent parser and interpreter that you already have for Scheme itself.
Plus, you can’t assume that using JSON or YAML will give your users some kind of magical intuition bonus; you’ll still have to train them to use JSON/YAML correctly. I have a friend (who isn’t a software engineer) who needed to do some work on JSON files, and it was pretty clear that he was just cargo–culting it. He was only doing it to accomplish some larger goal, not for the joy of knowing the JSON syntax. That’s a hurdle you will face no matter what you do.
I am not complaining about those abstractions being possible, I am complaining about them being necessary for doing basic stuff that every other modern language solves with a builtin dictionary datatype. The more you use those abstractions the worse your error messages will get and the harder it will be to understand what is going on.
JSON would at least work consistently and don't randomly redefine the meaning of the language midway through a config file. YAML numerous issues of its own, so I'd avoid that if possible.
This isn't a Guix specific problem, the GNU project has tried to make Guile a thing for the last 20 years or so, and it just never looked especially elegant to me in any context and never really gained any real adoption in the wild either.
And when it comes to package configuration, it's just an unnecessary issue, we already had Nix, which comes with it's own JSON-like language specifically build for this task and that is much nicer to work with than Scheme, because it's configuration language first, not a general purpose programming language turned into one via macros. Using Scheme instead just doesn't improve the situation in any way in my eyes, it just creates a lot of additional problems.
Comments
Which is why a good text editor will balance parentheses automatically and highlight macros. That being said, it is well known that macros can be abused and overused. It is considered bad style to use macros if a function would do the job too.
*Edit:* Guix supports JSON specifications too, though you are of course not as flexible as with Scheme: https://guix.gnu.org/manual/en/html_node/Invoking-guix-packa...
Which is what Guix is doing. Just look at (package), why isn't that a function taking an associated list? It's this kind of ad hoc DSL magic that makes Lisp-like languages incredible hard to read, since you never know what you are looking at.
Compare the package macro:
With a package function that takes an alist: Notice how the alist has to be backquoted so that you can put a comma in front of everything that needs to be evaluated, and how every entry in the alist has to be a pair rather than a list which requires a dot on every line. Which would you rather type out a hundred thousand times? Which would you prefer to teach to new contributors? Which would you prefer to answer questions about on a mailing list?Neither. But that proofs my point, Lisp is unreadable for the average user. If your first instinct is to not use the language itself, but write your own DSL on top of it to make it readable, maybe that language ain't such a good choice.
But the whole point of Scheme is that the syntax is simple enough that you _can_ do metalinguistic abstraction. That was a deliberate design choice, not an accident. In most other languages you have to stoop to using some other parser and interpreter for data files, rather than reusing the excellent parser and interpreter that you already have for Scheme itself.
Plus, you can’t assume that using JSON or YAML will give your users some kind of magical intuition bonus; you’ll still have to train them to use JSON/YAML correctly. I have a friend (who isn’t a software engineer) who needed to do some work on JSON files, and it was pretty clear that he was just cargo–culting it. He was only doing it to accomplish some larger goal, not for the joy of knowing the JSON syntax. That’s a hurdle you will face no matter what you do.
I am not complaining about those abstractions being possible, I am complaining about them being necessary for doing basic stuff that every other modern language solves with a builtin dictionary datatype. The more you use those abstractions the worse your error messages will get and the harder it will be to understand what is going on.
JSON would at least work consistently and don't randomly redefine the meaning of the language midway through a config file. YAML numerous issues of its own, so I'd avoid that if possible.
This isn't a Guix specific problem, the GNU project has tried to make Guile a thing for the last 20 years or so, and it just never looked especially elegant to me in any context and never really gained any real adoption in the wild either.
And when it comes to package configuration, it's just an unnecessary issue, we already had Nix, which comes with it's own JSON-like language specifically build for this task and that is much nicer to work with than Scheme, because it's configuration language first, not a general purpose programming language turned into one via macros. Using Scheme instead just doesn't improve the situation in any way in my eyes, it just creates a lot of additional problems.