>> Also the Nix model allows us to compile all our scripts easily (just >> apply a function), which might hold some benefit in terms of startup >> and switch times. There is little reason to use interpreted scripts >> when you have a fast compiler. > > So would you say that this is preferable to the shell-monad idea?
Yes. Even when compiling a Haskell DSL to a shell script you need to compile the DSL itself first into a program that can output the script. If you are going to compile anyway, just compile the source language to a runnable binary in the first place. One huge benefit of that is that you can use the libraries and abstractions of the source language. As a simple example by compiling to Bash you give up the option of using Haskell's concurrency, exception handling, etc. And those two are particularly difficult to translate to Bash, or pretty much every other shell. > I'd definitely say that NixOS is the most state-of-the-art GNU+Linux > distribution in existence, [...] To be fair, there is also the GNU OS, which uses Guix, although the underlying ideas and build system (nix-daemon) are the same. > [...] for people who rarely use computers, the potential difference is > a lot lower, so UI changes should not be forced upon them.) I think it is important to define your target audience. If you are specifically targetting, as you call them, computer illiterates or people who rarely use computers, it is entirely reasonable to offer them an easy, slowly evolving UI. However, for the general public I would say that our current state of the art in UIs is so broken that the faster we move on the better for humanity. For example anyone who tells me that touch screens are intuitive does not understand the word *intuitive*. Hint: It does not mean pictures, nor does it mean pointing. The same holds for virtual UIs that we access through HIDs. For a concrete example just try to use style sheets *and* be productive at the same time in your office suite of choice (don't worry, they all suck). Try to handle hundreds of e-mails per day (*handle*, not skim!) in multiple mailboxes *and* use less than 50% of your work time for dealing with e-mail in any MUA (yes, I'm including mutt and Emacs). Now don't get me wrong. You do have a point there. If a UI was perfectly reasonable and has been replaced by something less reasonable, I can totally understand your dissatisfaction. That does happen from time to time when marketing people try to be smart. But if the sole reason that you are unhappy is because you have to learn something new, then you shouldn't suggest moving to purely functional languages for scripting. Remember that contributors are humans as well, many of them will face having to learn something new and nontrivial, and some of them will probably be just as angry as you are when your UI has been replaced without the option to go back. Again don't get me wrong. I suggest that we do it, as long as we think that we're moving along the right track. Innovation will almost by necessity cause some dissatisfaction. I'm really just saying that there is not much difference between innovation in programming languages (programmers are humans) and user experience (users are humans). For some of them innovation will be a problem in both cases. Either you choose to respect that, or you choose to move on regardless. It depends on your target audience. > I'm also only interested in the pure-functional languages. I'm not > interested in so-called ‘multiparadigm’ functional/imperative > languages like Scheme as this does not provide the deterministic > purity guarantees that pure-functional languages are based-on. I would love to use Haskell for everything, but it's simply not a realistic option. Currently GHC is practically our only compiler. It is huge, compiling takes time, etc. We can fix all of these things, but we haven't so far and GHC will not get smaller or faster any time soon. Let me clarify: GHC is not slow per se, if you consider that Haskell has an extremely high signal/noise ratio, not just in syntax, but especially in semantics. Two lines of Haskell can easily *mean a lot* (i.e. encode a program that does lots of things or very complicated things). If we measure by "time spent per semantic content", then GHC is lightning-fast. However, that measure is only interesting for larger projects. For small scripts the measure "time spent per line of code" counts, and GHC does not perform too well there. The other static functional languages I have tried were either too noisy, too immature or did not provide a reasonable FFI. Things will improve and new options will pop up, but right now our choices are limited. > True, but the idea is to minimise impure code. The documentation and > tutorials of pure languages encourage the practice of factoring-out > any necessary impure code and writing most code to be pure. Can the > same be said about multiparadigm languages? You may need to adjust your terminology there. Haskell is a multi-paradigm language. What sets it apart is its friendlyness to provable algebraic abstractions.
signature.asc
Description: PGP signature
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
