6 ms·

> Thanks for not going full-Haskell on us It would have been so much better if they went full Haskell. Haskell is better designed as a language, it has types a

by tinco 5y ago

> Thanks for not going full-Haskell on us It would have been so much better if they went full Haskell. Haskell is better designed as a language, it has types and could support all Nix features without modification as far as I can tell. On top of that it's a common language that most have used at least in university and has loads of friendly tutorials online. Totally agree on the packaging of C/C++ projects is a drag of our entire industry and basically a complete embarrassment.

SkyMarshal 5y ago
I'm relatively new to NixOS but this is my sense of things too - it might have been better to use a subset of Haskell for the Nix package manager, instead of a new untyped language, for the reasons you give. One simple thing I like about Haskell is its readability. Instead of cramming both type signature and function definition into the same line, Haskell splits those two into separate lines. Having the type signature in its own line, as the first line of every function, is so much more readable. It's also interesting that you can outline/pseudo-code an entire program structure using only type signatures and no function definitions, check if the type signatures are all correct, and then fill in the function definitions later. That said, I'm still new to Nix, and there are probably good reasons it was done this way, buried in past discussions, the creator's PhD thesis, etc. that I haven't read yet. And I hear that types are being looked into for future upgrades to Nix.
- mikepurvis 5y ago
  I'm not a Haskell user, but my assumption has been that the Nix language being something of a DSL has meant that it's able to include certain kinds of convenient optimizations such as directly referring to files by their relative path. Is this bogus, or would you imagine that a substantial number of additional wrapper/helper/noise functions would be needed to make a general-purpose language do what the Nix language does? I guess Guix is probably an opportunity to look at a practical instance of this first-hand.
  - momentoftop 5y ago
    Not the parent, but I think if you tried to do Nix in Haskell, the syntax would be seriously gross. For starters, you couldn't use Haskell's record syntax for Nix's sets, because they're not Haskell records. Types wouldn't help that much when you come to do lookups in these sets: if you get the name of a key wrong, it's a runtime error. The ability to use file paths in Nix gives you a very cheap mechanism for splitting code across files. In Nix, the expression `import <filepath>` will evaluate to the result of evaluating the file `<filepath>`. But in Haskell, every such import would need to be declared at the top of the file, and the module name would need to be duplicated at the use-site, almost certainly fully qualified to avoid nameclashes. I'm not overly bothered by type systems for things like Nix. In Nix, you're mostly just coding the construction of a single, reproducible value, which is trivial to exhaustively test: just construct it and see if it's right. If there's something wrong, you'll either 1) get the error immediately when you try to evaluate, and you might even be told helpful things like a list of strings was expected, not a list of numbers. 2) get an error when the derivation is built, due to an environment error that is unlikely to be detected by a type system. Splitting this into two phases, compile then evaluate, wouldn't help me much.
    - mikepurvis 5y ago
      Okay, yeah, that makes sense and aligns with my instinct about it. I think the main costs of Nix being its own thing are probably in areas like documentation and performance. But a lot of the documentation issues with Nix aren't actually issues with the documentation of the language (which is fairly minimal) but rather with the document of nixpkgs, which contains mountains of magical helpers and other tricks with horrendously bad documentation and discoverability. That infrastructure (and the corresponding documentation gap) would likely exist regardless of the base language.
shepherdjerred 5y ago
Haskell is a fantastic language, and it's becoming one of my favorites, but it is by no measure a friendly one. Nobody wants to have to learn a complex language for a task as essential as using their own computer. Also, I think your claim that "most have used at least in university" is skewed to your experiences. I doubt the majority of programmers have any experience in Haskell whatsoever with even fewer having enough experience to be comfortable in it.
- wyager 5y ago
  I don't really buy the "Haskell isn't friendly" thing - it's way more work and way less pleasant to become an expert in, say, C++, than to become an expert in Haskell. It depends on what, precisely, you are measuring the difficulty of. Are you writing a quick script? A complex software project? Trying to master the language? Is it a beginner programmer? A narrowly focused coder who only knows one or two similar languages? An experienced programmer with a wide breadth of knowledge? In pedagogical terms, I found learning Haskell much friendlier when I was contemporaneously learning Java, C++, Prolog, etc. in university.
  - shepherdjerred 5y ago
    But the choice isn’t between Haskell and C++, the choice is between Haskell and any other language. I agree that C++ is a bloated, error-prone nightmare, and I avoid it for that reason. There are plenty of languages that are widely considered easy to learn/use (python, Java, JavaScript). One of the big reasons that Haskell is hard to learn is because it is purely functional. Writing idiomatic Haskell is dramatically different from traditional imperative C-like languages. Just to give an example - a few years ago I was taking an AI class which used Common Lisp (a functional language, but not purely functional). The first few tests/projects which required functional lisp programs led many of my peers to drop the class. I think part of this is because my school, like most, started students off with an imperative/procedural language (C++). If you have a clean slate (e.g. someone with zero programming knowledge) it’s probably just as easy to teach them Haskell as it is C++ or Java. Functional programming is great, and I love it, but many programmers don’t even have a firm grasp on recursion which makes pure languages like Haskell like a mountain to climb.
josteink 5y ago
> have used at least in university That’s showing a bit of bias. Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell. Basing your packaging-format on Haskell is a great way to alienate most Linux-users without a specialised university-education, and I’m wagering that’s a fairly big portion of desktop-Linux end-users.
- nix23 5y ago
  >Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell. See that's the bubble ;) If you work at a company who makes archival, language-detection and ocr you will see C/C++ Haskell and OCaml..well and perl in no time. http://wiki.haskell.org/Haskell_in_industry http://wiki.haskell.org/Haskell_in_industry https://serokell.io/blog/top-software-written-in-haskell https://serokell.io/blog/top-software-written-in-haskell
  - throwaway894345 5y ago
    > See that's the bubble ;) If you work at a company who makes archival, language-detection and ocr you will see C/C++ Haskell and OCaml..well and perl in no time. I think your scenario sounds a lot more like a bubble. It's certainly my experience that very few people have encountered Haskell whether in a university setting or a professional setting. Yes, there are some niches where Haskell is "not rare" (especially the programming language theory corner of computer science departments), but in general I think it's quite rare.
    - nix23 5y ago
      >I think your scenario sounds a lot more like a bubble. Depends on the job you have, and how far you go out of your bubble. >but in general I think it's quite rare. Like Fortran...but not if you work at Cern. And Cobol...but not if you work at a Finance institute. And PL/1...but not if you work for IBM.
      - 5y ago

by tinco 5y ago

SkyMarshal 5y ago

I'm relatively new to NixOS but this is my sense of things too - it might have been better to use a subset of Haskell for the Nix package manager, instead of a new untyped language, for the reasons you give. One simple thing I like about Haskell is its readability. Instead of cramming both type signature and function definition into the same line, Haskell splits those two into separate lines. Having the type signature in its own line, as the first line of every function, is so much more readable. It's also interesting that you can outline/pseudo-code an entire program structure using only type signatures and no function definitions, check if the type signatures are all correct, and then fill in the function definitions later. That said, I'm still new to Nix, and there are probably good reasons it was done this way, buried in past discussions, the creator's PhD thesis, etc. that I haven't read yet. And I hear that types are being looked into for future upgrades to Nix.

mikepurvis 5y ago
I'm not a Haskell user, but my assumption has been that the Nix language being something of a DSL has meant that it's able to include certain kinds of convenient optimizations such as directly referring to files by their relative path. Is this bogus, or would you imagine that a substantial number of additional wrapper/helper/noise functions would be needed to make a general-purpose language do what the Nix language does? I guess Guix is probably an opportunity to look at a practical instance of this first-hand.
- momentoftop 5y ago
  Not the parent, but I think if you tried to do Nix in Haskell, the syntax would be seriously gross. For starters, you couldn't use Haskell's record syntax for Nix's sets, because they're not Haskell records. Types wouldn't help that much when you come to do lookups in these sets: if you get the name of a key wrong, it's a runtime error. The ability to use file paths in Nix gives you a very cheap mechanism for splitting code across files. In Nix, the expression `import <filepath>` will evaluate to the result of evaluating the file `<filepath>`. But in Haskell, every such import would need to be declared at the top of the file, and the module name would need to be duplicated at the use-site, almost certainly fully qualified to avoid nameclashes. I'm not overly bothered by type systems for things like Nix. In Nix, you're mostly just coding the construction of a single, reproducible value, which is trivial to exhaustively test: just construct it and see if it's right. If there's something wrong, you'll either 1) get the error immediately when you try to evaluate, and you might even be told helpful things like a list of strings was expected, not a list of numbers. 2) get an error when the derivation is built, due to an environment error that is unlikely to be detected by a type system. Splitting this into two phases, compile then evaluate, wouldn't help me much.
  - mikepurvis 5y ago
    Okay, yeah, that makes sense and aligns with my instinct about it. I think the main costs of Nix being its own thing are probably in areas like documentation and performance. But a lot of the documentation issues with Nix aren't actually issues with the documentation of the language (which is fairly minimal) but rather with the document of nixpkgs, which contains mountains of magical helpers and other tricks with horrendously bad documentation and discoverability. That infrastructure (and the corresponding documentation gap) would likely exist regardless of the base language.

shepherdjerred 5y ago

Haskell is a fantastic language, and it's becoming one of my favorites, but it is by no measure a friendly one. Nobody wants to have to learn a complex language for a task as essential as using their own computer. Also, I think your claim that "most have used at least in university" is skewed to your experiences. I doubt the majority of programmers have any experience in Haskell whatsoever with even fewer having enough experience to be comfortable in it.

wyager 5y ago
I don't really buy the "Haskell isn't friendly" thing - it's way more work and way less pleasant to become an expert in, say, C++, than to become an expert in Haskell. It depends on what, precisely, you are measuring the difficulty of. Are you writing a quick script? A complex software project? Trying to master the language? Is it a beginner programmer? A narrowly focused coder who only knows one or two similar languages? An experienced programmer with a wide breadth of knowledge? In pedagogical terms, I found learning Haskell much friendlier when I was contemporaneously learning Java, C++, Prolog, etc. in university.
- shepherdjerred 5y ago
  But the choice isn’t between Haskell and C++, the choice is between Haskell and any other language. I agree that C++ is a bloated, error-prone nightmare, and I avoid it for that reason. There are plenty of languages that are widely considered easy to learn/use (python, Java, JavaScript). One of the big reasons that Haskell is hard to learn is because it is purely functional. Writing idiomatic Haskell is dramatically different from traditional imperative C-like languages. Just to give an example - a few years ago I was taking an AI class which used Common Lisp (a functional language, but not purely functional). The first few tests/projects which required functional lisp programs led many of my peers to drop the class. I think part of this is because my school, like most, started students off with an imperative/procedural language (C++). If you have a clean slate (e.g. someone with zero programming knowledge) it’s probably just as easy to teach them Haskell as it is C++ or Java. Functional programming is great, and I love it, but many programmers don’t even have a firm grasp on recursion which makes pure languages like Haskell like a mountain to climb.

josteink 5y ago

> have used at least in university That’s showing a bit of bias. Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell. Basing your packaging-format on Haskell is a great way to alienate most Linux-users without a specialised university-education, and I’m wagering that’s a fairly big portion of desktop-Linux end-users.

nix23 5y ago
>Personally Ive been in the industry for roughly 20 years and I’ve yet to meet anyone IRL who has even dabbled in Haskell. See that's the bubble ;) If you work at a company who makes archival, language-detection and ocr you will see C/C++ Haskell and OCaml..well and perl in no time. http://wiki.haskell.org/Haskell_in_industry http://wiki.haskell.org/Haskell_in_industry https://serokell.io/blog/top-software-written-in-haskell https://serokell.io/blog/top-software-written-in-haskell
- throwaway894345 5y ago
  > See that's the bubble ;) If you work at a company who makes archival, language-detection and ocr you will see C/C++ Haskell and OCaml..well and perl in no time. I think your scenario sounds a lot more like a bubble. It's certainly my experience that very few people have encountered Haskell whether in a university setting or a professional setting. Yes, there are some niches where Haskell is "not rare" (especially the programming language theory corner of computer science departments), but in general I think it's quite rare.
  - nix23 5y ago
    >I think your scenario sounds a lot more like a bubble. Depends on the job you have, and how far you go out of your bubble. >but in general I think it's quite rare. Like Fortran...but not if you work at Cern. And Cobol...but not if you work at a Finance institute. And PL/1...but not if you work for IBM.
    - 5y ago