6 ms·

Probably because I’m not a lisp person but the syntax is just ugly and not intuitive. It would look much better as a yaml file and I don’t even really like yaml

Probably because I’m not a lisp person but the syntax is just ugly and not intuitive. It would look much better as a yaml file and I don’t even really like yaml either.

eointierney 4y ago
Learn Sanskrit not BNF Tongue in cheek :)
0x457 4y ago
I don't like lisp syntax, but honestly, I would rather use this language than whatever nix is. It can't be a yaml file because it's essentially a program, it's a lot easier to write such things as a program.
- colordrops 4y ago
  If you know Lisp or Haskell then Emacs and XMonad are great. If you don't, then you just get lost trying to configure them. Nix lang is a much simpler DSL with affordances like nice list syntax. It may be less powerful than lisp but it's easy to edit and (relatively) quick to learn. Similar to vimscript, which sucks, but it's amenable to easy edits for the unwashed masses.
  - deleted 4y ago
    [deleted]
  - 0x457 4y ago
    My issue with Nix-lang is that it's somewhere between declarative and uhm…not declarative? Certain sections of nix files have special meaning (config), certain functions only work in those sections. Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. It's poorly documented, “standard library” documentation is even worse. It's impossible to navigate because everything is mashed together in `nixpkgs`. Often show no examples on how to use a function and just say `it takes blahblah`, but what is blahblah?
    - ParetoOptimal 4y ago
      > Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. Ah, so Nix needs lenses. Edit: On the NixOS matrix I was told "there is lib.recursiveUpdate" when I mentioned your comment. Does that fix this problem for you or improve things?
      - 0x457 4y ago
        Well, yes, it fixed it when I've discovered this function a while ago. That's just an example. That's what I'm bitching about - discovering documentation sucks because nix-lang is a very niche language and `nixpkgs.lib` is mostly undocumented. That makes finding how to do something in it is harder compared if to any other language. With homebrew, it's just ruby scripts. You write ruby, you can ask some ruby question from someone who never wrote a formula and get an answer because that's a general purpose language. With guix, it's not the best, but it's still just GNU Guile, it's been around for almost 30 years. Yeah, it's probably not very popular, but it's still a general purpose language that has uses outside Guix.
db48x 4y ago
Would you mind clarifying what part of the syntax was unintuitive?
- dan-robertson 4y ago
  I think when I skimmed it, I found: - the module paths a bit weird (I’d find slash or dot separated more obvious) - some values needed to be constructed with a call to list - weird dsl for building was mixed in there - it’s probably not obvious what should be string/symbol/whatever I’m not sure anything should change though. It still feels a bit weird to me that it’s a program generating the package rather than a more direct ‘just data’ format.
  - podiki 4y ago
    To the last point: since it is a lisp, data = code and all that. Fundamentally I think that is at the heart of a lot of the power here with package definitions and the system itself being the same.
  - db48x 4y ago
    Ok, so mostly just variations on the “unfamiliar with lisp” theme. Though I have to say that it would be a bit silly to invent a new way to write lists just to name packages, when Lisp already has an excellent way of writing lists. :) Oh, and how can a package manager avoid dealing with build systems? There are almost as many different build systems as there are packages!
    - dan-robertson 4y ago
      I was trying to answer the question of why the lisp config might be difficult to read so I deliberately tried to not rely on my own intuition about how lisps work. In particular, I think it is possible to design a format for s-expression package definitions that is more approachable to people who don’t know lisp. I continue to find it slightly odd that the package definition is not some serialisation of a package object but rather a full program that outputs a package object, and I think this is the root of a bunch of the confusing things about the definition. Consider that the commenter at the top of this thread thought yaml might be preferable. I think that means they didn’t realise they were looking at a program outputting the package definition but rather that they thought they were just looking at the definition itself. If the whole thing were just data instead of data that’s actually code whose evaluation produces data, I think things would be more obvious. For example, some symbols are just syntax (e.g. in the alist syntax for constructing the package definition) whereas others are references to values of which some are other packages, some are just scheme functions, and some are guix-specific functions. And symbols have other meanings in the build-steps reader macro. Building package definitions in this way can also make errors harder to pinpoint as the author can write any program they like rather than being restricted to a more limited configuration language. Needing to evaluate programs to get packages can also, I think, make the collection of all packages as a whole pretty opaque and hard to reason about compared to e.g. being able to have a database that contains all the package definitions. I don’t think the ‘unfamiliar with lisp’ argument is good. I’m pretty familiar with lisp (though not so much guile/scheme) and I’ve been writing it for over ten years and I think this way of specifying packages is not great in the average case, though perhaps there are some complexities that cannot be handled without this general mechanism.
sreevisakh 4y ago
How familiar are you with Lisps? I heard somewhere that it's easier for a complete beginner to start learning programming with lisps than with traditional languages. I started with more mainstream languages, but my experience tends to agree with that observation. The small set of various lisp forms and their semantics are easy to learn and reason about, compared to synatx and semantics of more traditional languages. Same when s-expressions are used for representing data. The syntax closely matches the logical structure of a program or data. Keeping this in mind, I find the Guile scheme syntax used by Guix quite intuitive and pleasant. It reduces the cognitive overhead to configure the system, at least for me.
llanowarelves 4y ago
I felt the same but after reading this[1] and following along with the REPL it finally started to click. There are actually much less rules than "normal" programming languages. I had started to write my own basic functions that would be in a "standard library" (trim(), trunc(), remove() etc) and got the hang of it after a couple hours. The only thing I don't like about the language for "serious" work on massive projects is missing static types (may make it less readable though..), and the tooling (most people lean on Emacs) could be better. So I'm guessing there's some additional conventions for function naming, besides appending ? to the name for boolean return and ! for functions that mutate. [1]https://spritely.institute/static/papers/scheme-primer.html https://spritely.institute/static/papers/scheme-primer.html
guilhas 4y ago
I am not a lisp person, but it is just a configuration file with key value pairs and lists, mostly copy pasted from the documentation or other ppl configurations. A file with all configs in the same place in an unified way Also each configuration file in Linux has already has their differences and quirks

Probably because I’m not a lisp person but the syntax is just ugly and not intuitive. It would look much better as a yaml file and I don’t even really like yaml either.

eointierney 4y ago

Learn Sanskrit not BNF Tongue in cheek :)

0x457 4y ago

I don't like lisp syntax, but honestly, I would rather use this language than whatever nix is. It can't be a yaml file because it's essentially a program, it's a lot easier to write such things as a program.

colordrops 4y ago
If you know Lisp or Haskell then Emacs and XMonad are great. If you don't, then you just get lost trying to configure them. Nix lang is a much simpler DSL with affordances like nice list syntax. It may be less powerful than lisp but it's easy to edit and (relatively) quick to learn. Similar to vimscript, which sucks, but it's amenable to easy edits for the unwashed masses.
- deleted 4y ago
  [deleted]
- 0x457 4y ago
  My issue with Nix-lang is that it's somewhere between declarative and uhm…not declarative? Certain sections of nix files have special meaning (config), certain functions only work in those sections. Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. It's poorly documented, “standard library” documentation is even worse. It's impossible to navigate because everything is mashed together in `nixpkgs`. Often show no examples on how to use a function and just say `it takes blahblah`, but what is blahblah?
  - ParetoOptimal 4y ago
    > Nice features like `//` for merging dicts goes out of the window as soon as you have nested dict, which is nearly every time. Ah, so Nix needs lenses. Edit: On the NixOS matrix I was told "there is lib.recursiveUpdate" when I mentioned your comment. Does that fix this problem for you or improve things?
    - 0x457 4y ago
      Well, yes, it fixed it when I've discovered this function a while ago. That's just an example. That's what I'm bitching about - discovering documentation sucks because nix-lang is a very niche language and `nixpkgs.lib` is mostly undocumented. That makes finding how to do something in it is harder compared if to any other language. With homebrew, it's just ruby scripts. You write ruby, you can ask some ruby question from someone who never wrote a formula and get an answer because that's a general purpose language. With guix, it's not the best, but it's still just GNU Guile, it's been around for almost 30 years. Yeah, it's probably not very popular, but it's still a general purpose language that has uses outside Guix.

db48x 4y ago

Would you mind clarifying what part of the syntax was unintuitive?

dan-robertson 4y ago
I think when I skimmed it, I found: - the module paths a bit weird (I’d find slash or dot separated more obvious) - some values needed to be constructed with a call to list - weird dsl for building was mixed in there - it’s probably not obvious what should be string/symbol/whatever I’m not sure anything should change though. It still feels a bit weird to me that it’s a program generating the package rather than a more direct ‘just data’ format.
- podiki 4y ago
  To the last point: since it is a lisp, data = code and all that. Fundamentally I think that is at the heart of a lot of the power here with package definitions and the system itself being the same.
- db48x 4y ago
  Ok, so mostly just variations on the “unfamiliar with lisp” theme. Though I have to say that it would be a bit silly to invent a new way to write lists just to name packages, when Lisp already has an excellent way of writing lists. :) Oh, and how can a package manager avoid dealing with build systems? There are almost as many different build systems as there are packages!
  - dan-robertson 4y ago
    I was trying to answer the question of why the lisp config might be difficult to read so I deliberately tried to not rely on my own intuition about how lisps work. In particular, I think it is possible to design a format for s-expression package definitions that is more approachable to people who don’t know lisp. I continue to find it slightly odd that the package definition is not some serialisation of a package object but rather a full program that outputs a package object, and I think this is the root of a bunch of the confusing things about the definition. Consider that the commenter at the top of this thread thought yaml might be preferable. I think that means they didn’t realise they were looking at a program outputting the package definition but rather that they thought they were just looking at the definition itself. If the whole thing were just data instead of data that’s actually code whose evaluation produces data, I think things would be more obvious. For example, some symbols are just syntax (e.g. in the alist syntax for constructing the package definition) whereas others are references to values of which some are other packages, some are just scheme functions, and some are guix-specific functions. And symbols have other meanings in the build-steps reader macro. Building package definitions in this way can also make errors harder to pinpoint as the author can write any program they like rather than being restricted to a more limited configuration language. Needing to evaluate programs to get packages can also, I think, make the collection of all packages as a whole pretty opaque and hard to reason about compared to e.g. being able to have a database that contains all the package definitions. I don’t think the ‘unfamiliar with lisp’ argument is good. I’m pretty familiar with lisp (though not so much guile/scheme) and I’ve been writing it for over ten years and I think this way of specifying packages is not great in the average case, though perhaps there are some complexities that cannot be handled without this general mechanism.

sreevisakh 4y ago

How familiar are you with Lisps? I heard somewhere that it's easier for a complete beginner to start learning programming with lisps than with traditional languages. I started with more mainstream languages, but my experience tends to agree with that observation. The small set of various lisp forms and their semantics are easy to learn and reason about, compared to synatx and semantics of more traditional languages. Same when s-expressions are used for representing data. The syntax closely matches the logical structure of a program or data. Keeping this in mind, I find the Guile scheme syntax used by Guix quite intuitive and pleasant. It reduces the cognitive overhead to configure the system, at least for me.

llanowarelves 4y ago

I felt the same but after reading this[1] and following along with the REPL it finally started to click. There are actually much less rules than "normal" programming languages. I had started to write my own basic functions that would be in a "standard library" (trim(), trunc(), remove() etc) and got the hang of it after a couple hours. The only thing I don't like about the language for "serious" work on massive projects is missing static types (may make it less readable though..), and the tooling (most people lean on Emacs) could be better. So I'm guessing there's some additional conventions for function naming, besides appending ? to the name for boolean return and ! for functions that mutate. [1]https://spritely.institute/static/papers/scheme-primer.html https://spritely.institute/static/papers/scheme-primer.html

guilhas 4y ago

I am not a lisp person, but it is just a configuration file with key value pairs and lists, mostly copy pasted from the documentation or other ppl configurations. A file with all configs in the same place in an unified way Also each configuration file in Linux has already has their differences and quirks