[Nix-dev] Use Haskell for Shell Scripting

[James Haigh]

On 09/02/15 15:22, Ertugrul Söylemez wrote:
>>> 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.
Okay, sure. Nevertheless, shell-monad could still come in handy for Grub
scripts or something where I have no choice but to run shell scripts. :-D
>> 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.
Last time that I talked about Guix on IRC, I seem to remember that
Ludovic (civodul) declared that I was trolling and subsequently left the
channel, which was not and is not my intention because I'm a keen libre
software supporter and I accept that GNU OS is with good intentions. As
such, it's probably best for me to not talk about GNU OS, Guix, and
Guile until I get the time/willpower to explain why my viewpoint against
that project is not malicious and why NixOS is – perhaps
counterintuitively to some libre software supporters – more beneficial
to the software freedom movement.
>> [...] 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.
Sure, there isn't a distinct dividing line because, of course, the
programming language can be seen as the developer's ultimate human
interface to the computer, but what I was trying to say is that
comparisons of human interfaces are considerably more subjective and
personal than comparisons of programming techniques. However, this may
be a false conclusion of the apparent deterioration of graphical user
interfaces in Gnome, KDE, Firefox, Nautilus, and pretty much anything
that focuses on the concept of ‘discoverability’ by removing features
and preferences rather than improving their documentation and providing
interactive demonstrations. Basically, these ‘modern’ interfaces are,
generally by design, quicker to get the hang of but less efficient in
the long-run compared to some older UIs (e.g. Nautilus 3.4, Amarok 1.4)
or UIs of an ‘old style’ (but which may be up-to-date) such as tiling
window managers (I'm currently using XMonad+Taffybar with bits of Gnome)
which start with a higher learning curve but seem to be more efficient
in the long-term. Seeing as most people are using computers _a lot_ it
seems silly to make simple inefficient interfaces rather than powerful
featureful interfaces that are accompanied with mechanisms to get over
the initial learning curve quicker (documentation/walkthroughs). I had
put my dislike of simple GUIs down to personal preference and that I
just mustn't be normal with my preference, hence the mass change away
from it, but actually, surely this is measurably objective and that
those vast majority of people who claim to be computer illiterate but
who are actually using computers for several hours a day, would be very
much better-off investing some initial time learning a more efficient
interface.
    Nevertheless, I still think that human interface choice is
important, and XMonad is an example of the original point that I was
trying to get at. It is a classic user interface, a tiling window
manager, using a pure-functional language. Just because something is
written using modern techniques doesn't mean to say that the user
interface itself is ‘modern’.
    Either way, whether it is the user human interface or the developer
human interface (i.e. the programming language), diversity and choice is
good, providing that it can be supported by the size of the community –
or more specifically, providing that each choice can be supported by the
subset of the community that is interested in that choice. So I choose
determinism, declarativity, and the pure-functional paradigm, and so I
choose NixOS as my distro. I find Nix the language to be a very
efficient and comfortable human interface to package and configuration
management. ;-)
    Wrt. target audience, this is why I suggest that pure-functional
scripting only be used with functional or pure-functional packages.
Though the Nix community is small relative to those of other GNU+Linux
distributions, and smaller still to those of other operating systems, a
relatively large subset of the NixOS community is overlapping with the
Haskell and functional programming community.
    (Btw., when I am successfully up-and-running with ARM, I intend to
start packaging software for Nix, including some old interfaces such as
Nautilus 3.4 or its forks.)
>> 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.
Hey, that's a very interesting way to think of it!
> 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.
‘multiparadigm’ is ambiguous as to what multiple paradigms that refers
to, but I clarified that by saying “functional/imperative”. The point
that I was making was that different programming languages emphasise
different paradigms in their documentation and tutorials. I notice that
now when I write code in an imperative language, I'm laying it out more
as if it were functional, and I'm avoiding unnecessary side-effects.

Best regards,
James Haigh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150209/0ac2abaf/attachment-0001.html