[Nix-dev] Use Haskell for Shell Scripting

[Ertugrul Söylemez]

>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150209/acd5ff8c/attachment.bin