Contents:
- Why I write and who you are
- Haskell - The language of terms
- Haskell - The language of types
- Haskell - Typeclasses
- Parser combinators: Fast streaming of huge and complex files
- Multiple sequence alignment: Algorithms and performance
- Command line scripting: IO, system calls and parallelism
- Rogue: Graphics and concurrency
- Alignment dashboard: REST APIs and web design
- The End
In this series, I will make the case for the practicality of strongly-typed functional languages (STFL). My target reader is the practical bioinformatician. You know who you are. When faced with a problem, you seek the shortest path the solution. Your eyes are on the end, not the means. Any time spent learning programming language arcana is time not spent doing science. So why would you be interested in strongly-typed functional programming languages?
I’ve had this debate many times. Indeed, the “you” I write to is an averaging of many people I’ve known: close friends, co-workers, random conference-goers, reviewers who casually torpedoed my grants because “Python does everything”. The argument always flounders because we don’t have a common conceptual framework. Instead of discussing the interesting problem, how best to do computational science, we argue over the definitions of words. It is my goal here to provide a foundation on which we can have a proper discussion.
To contrast strongly-typed functional languages and weakly-typed imperative/mixed languages I will focus on Haskell and Python. I chose Haskell because I know it well and the language is, at its core, very simple and minimal. While Rust is likely a better alternative for many bioinformatics applications, my case for the power of well-designed type systems and strict control of effects will apply to it as well.
A common reaction to Haskell is to immediately dismiss it as irrelevant. Why are you wasting time with esoteric languages? We care about practical problems and getting solutions out to our collaborators as quickly as possible. We care about efficient solutions and fast development, not your academic concerns about soundness and elegance. OK, I’m definitely bitter.
The implicit assumption is that Haskell is slow, hard to write, and hard to read. That Haskell is not practical. My goal is to counter this assumption. I may not convince you to replace the conventional Bash/Python/R ecosystem for Haskell or Rust, but I hope you will at least learn what you are missing and where such languages may be valuable.
This series will be a long term endeavor. I will start with a three-part tutorial on Haskell where I will argue that the type system is your friend. The Haskell tutorial will hopefully show you the beauty of Haskell and the reason why it is so loved by its users. It will not, however, show the practicality of the language. To that end I will write a series of side-by-side comparisons that show implementations of non-trivial problems in both Haskell and Python.
This series is not complete. I hope to finish it by the end of 2023.