Practical Haskell: scripting with types

I had the pleasure to give a new talk today, on design in functional programming — types, abstractions and monads — using the motivating example of scripting. The slides are below and a PDF version is available.

﻿﻿Shell scripts are often a quick, dirty way to get the job done. You glue
together external tools, maybe do a little error checking and process all data
as strings. This is great for some very simple problems but as requirements
change and more is demanded from the code shell scripts become unwieldy and
fragile. When they get large, they become slow and difficult to maintain. If
you need to write robust code then shell is not the way to go.

In this talk at an alternative: how to use Haskell as a type checked and
natively compiled language for scripting tasks. By refining the semantics of
the problem domain, employing abstraction, we produce shorter and more robust
code, that is more maintainable and scalable.

Cool talk! I agree with most of the points you make (and I think a Haskell library optimized for scripting would be a great tool), but one place where we differ is on compilation.

I think compilation is a great tool for type- and syntax- checking a Haskell script, but to me, to remain a script, the actual executable has to be the source code, not a compiled binary. That way, I can, as a reader of scripts, tell what a script does (and how it does it) just by looking at it, instead of trying to track down the matching executable. There’s a bunch of times where I want to
* copy some of the behaviour of an existing script
* trace through a particular script to see if it’s got a bug, or if I’m misunderstanding its use.

I do these tasks and tasks like them time and time again with shell code. And though Haskell, and good practices like sensible error reporting will help somewhat, it’s no substitute for a human readable shell script.