Most code is read much more than it is written, at least I read much more code than I write. So for me code should be optimized to be read as plain text as that is basically what every tool uses. Requiring a separate tool to get basic readability is not really acceptable. I can't do that on github, I can't do that with the various diff tools, I can't just quickly cat a file or use the countless other tools that are designed to present plain text.

If I then can choose between guix and a language that doesn't require these hoops and extreme quality trade off the choice is not hard.

Anyway if you think guix is better than nix, than nothing stops you from using it.

I just have a hard time taking such a comment seriously, because I have made it myself. Many times even. My second comment on Slashdot in 1999 was a comment just like yours. I try to tell myself it is ok because I was still a teenager.

7 years later I had to write common lisp and I think the parens were a problem for about a week. Since then I have written many thousand lines of lisp code. I usually go back and forth on what I like the most. ML (ocaml mostly) or (guile) scheme. In just about every other language (except maybe factor) I miss the macros (even syntax rules ones) way more than I like the extra expressiveness of, say, Haskell. [0]

Wisp is a part of guile. So you can write your own config using it. It is not completely straightforward, but if you really hate parentheses it is a way. Or you continue the wonderful string gluing of Nix. Whatever floats your boat.

[0]: I do miss typing sometimes in scheme though. I have thought about vibe coding a prototype of an s-expr language that compiles to f# AST.

I think you’re misunderstanding my point.

This isn’t about whether someone can get used to parentheses. Obviously they can. I don’t doubt your extensive experience there. The question is what the language optimizes for by default.

My argument is that S-expressions optimize for structural uniformity and macro power, but they do so at the expense of plain-text readability without tooling. And that trade-off matters in contexts where code is frequently read outside of a fully configured editor, code reviews, diffs, quick inspection, etc.

Saying “editors solve this” doesn’t really address that, it just shifts the burden to tooling. In contrast, many other languages aim to be reasonably legible even in minimal environments.

So I’m not arguing that Lisp is unusable. I’m saying it makes a different set of trade-offs, and for my use case where I spend much more time reading other peoples code in some web portal and with basic terminal tools those trade-offs are a net negative. I would expect this trade off holds for most code produced.

All syntaxes look like windy grass to someone who is not used to them. I think that, while the parsing overhead for lisps might be higher, there is nothing else going on with precedence or syntax. Reading ocaml or haskel operator soup is in my opinion way more taxing than reading verbose scheme code - if it is well formatted.