[Nix-dev] Use Haskell for Shell Scripting

[James Haigh]

On 30/01/15 16:02, Joe Hillenbrand wrote:
> http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html
>
> Time to replace all shell scripts in Nix with Haskell?
No, certainly _now_ is way too early to replace _all_, but possibly
_some_, and starting with just the functional programming packages.
    I've seen a couple of Haskell shells (e.g. Hell) since maybe about a
year ago. They're on my todo list of things to switch to (just like
NixOS was for me from 2013 to 2014).
    I would recommend using a Haskell shell as your main shell for some
time before submitting scripts in it to a project that only has loose
ties with Haskell. It would also be nice to wait for Haskell shell users
and documentation to increase first because currently, if someone is to
look at a Haskell shell script who has not seen one before, it would not
be so easy for them to get help with it.
    On the other hand, Nix expressions that relate specifically to
Haskell packages may be an appropriate place for such scripts because,
well, people using Haskell are going to have less of a learning curve
with them and would better appreciate the advantages.
    I am though concerned for energy efficiency. Increasing required
computation doesn't just cost more / take longer, but also has greater
environmental impact. It's a trade-off, but it should be kept in-mind.

On 30/01/15 17:35, Joe Hillenbrand wrote:
> [...]
> Given those concerns another option could be shell-monad[1][2], which
> outputs shell script, so you get some of the safety benefits of
> Haskell with none of the overhead. Maybe it would be a good middle ground.
>
> [1] http://joeyh.name/blog/entry/shell_monad_day_3/
> [2] http://hackage.haskell.org/package/shell-monad
Wow yes, that's really quite interesting!!!

On 01/02/15 00:24, Ertugrul Söylemez wrote:
>> What about other languages as Python, Perl etc.? I know it is against
>> our purity standards, but they are a far superior to Bash scripting.
> Well, that's the current state of the art.  They are both used in
> Nixpkgs and some Nix-related tools.  They are an improvement over Bash
> scripting, but I believe we might as well go all the way and use a
> functional language.
Yes, I agree. If we're going to use a higher-level language, it should
at least make it into the pure-functional paradigm level of abstraction.
I see breaking legacy as being akin to forming lightning strikes; there
has to be enough potential difference (advancement) to break-down the
electrical insulation (difficulty in migration) and initiate the
electrostatic discharge (migration). Switching from Bash to Python
doesn't have so much appeal to me anymore since I've already been moving
from Python to the functional paradigm since 2012.
> 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?

On 30/01/15 16:36, Domen Kožar wrote:
> If you want to impose on people to learn Haskell and Nix to
> contribute, you're going to end up in a lonely island. Remember, Nix
> tries to be approachable to everyone and that's why it's minimal and
> simple.
>
> A lot of developers do realize that bash is terrible, but it wasn't
> replaced yet exactly for that reason. Legacy matters.
Well, if I cared too much about legacy, I wouldn't be using NixOS! :-D
I'd definitely say that NixOS is the most state-of-the-art GNU+Linux
distribution in existence, albeit a little lacking of hardware support
and package ecosystem, but this is improving fast!
    (I must note though, that there are 2 cases in which legacy is
particularly important: human interfaces, and hardware. This is because
those 2 things are not a simple matter of changing software. Human
interfaces are a very personal thing and I find it frustrating when they
change continually, with no preference for previous behaviour, or even
that preferences are removed. I'm not alone in this frustration; UI
change is particularly harsh on computer illiterate who struggle to
learn 1 interface as it is. Hardware is obviously costly to upgrade,
contributes to electronic waste, and again, their human interface
devices are very personal preferences. I'm using ThinkPad X60 Tablets
largely because I like pointing stick mice, hate touchpads, like the
ThinkPad keyboard, and like the inductive tablet screen and stylus.
Whereas with non-human-interface software, it's possible to break legacy
and achieve state-of-the-art efficiency, maintainability, reliability,
etc. without any cost to the end user. I'm not saying that you can't
have state-of-the-art hardware or user interfaces, it's just that, to
use the lightning analogy again, the dielectric strength for the
electrical insulator is a lot higher and for people who rarely use
computers, the potential difference is a lot lower, so UI changes should
not be forced upon them.)
    I think that using pure-functional languages in replacement to Bash,
at least in Nix packages relating to pure-functional languages, could
well have already approached that point where the required potential
difference has been reached. What happens then is the lightning bolt
progresses in little spurts, which apparently are usually about 45
metres each. This discussion, previous discussions, and Ertugrul's
experimentation is analogous to that, albeit on a much longer timespan
of months or years (and on the scale of kilometres of course... ??! :-P
). The ‘streamers’ have definitely started here and I'm interested to
see what happens in this respect.

On 01/02/15 06:32, Joe Hillenbrand wrote:
> Chicken or Scheme are not at all what at all what I was suggesting as
> they offer nothing in the way of purity or type-safety, which are the
> primary motivation for suggesting Haskell.
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.

On 02/02/15 19:53, Michael Raskin wrote:
> [...]
> Of course you can break purity easily; of course the real Haskell 
> implementation is GHC and it has unsafePerformIO. There are ways to
> confine impurity in both languages and there are ways to break purity
> in both languages.
> [...]
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?

Best regards,
James Haigh.