Spotlight: Rebecca Skinner (Author) Interview and AMA!

Ty for this detailed answer next time I’m asked about this I will be more convincing for sure :grin:.

I have another question about the Haskell eco-system maturity. In the data/machine learning engineering field, we focus a lot on JVM languages and python due to the major tools and framework provided in those eco-system.

From my understanding, it’s the current meta of development to use those tools and framework to do stuff in the real world.

As for Haskell, myself being a newbe, I have not a single idea of what it looks like in real life. What do we do when we want to orchestrate job ? Test it ? Deploy it ? Multi threading ? Do we actually have some tools at our disposal ? Or maybe Haskell is so great that we don’t need any of those :grinning: (no sarcasm intended) and therefore they don’t exist.

(Just noticed that your answer just above answers my last question :grimacing: sorry for the double question)


No trouble at all! To expand a bit on some things you mentioned in your question that I didn’t touch on as much earlier:


Haskell has a pretty good testing story in my experience. I personally tend to use hspec for spec style testing, and either quickcheck or hedgehog for property based testing. There are quite a few other testing frameworks out there to either help with writing tests or to offer different approaches to testing.


Since Haskell is a compiled language, deployment is pretty much the same as any other compiled language. Compile, copy the binaries, install dependencies if necessary, and run the application. A lot of people use Haskell inside of docker containers. I don’t touch on this in Effective Haskell at all, because it would have been too large of a digression from Haskell itself, but I prefer to build and deploy my applications using nix. It has a pretty steep learning curve, but once you get past the learning curve, it’s really useful for building and deploying things, and the Haskell support is particularly good.


Haskell does have really great support for multithreading, including a great tool called threadscope that lets you understand what’s happening in multithreaded code. Another great example of multithreading support in Haskell is the STM library, which gives you some really amazing safe primitives for building concurrent applications. At it’s best, I think Haskell’s concurrency story gives you all of the “fearless concurrency” of Rust alongside the ease-of-use of channel based communication (like Go’s channels, for example).

I hope that helps answer even more of your question!


Thank you so much for writing this book! I very much look forward to reading it.

Haskell-specific questions:

  • What is your opinion on TemplateHaskell? What do you think of it compared to other approaches of metaprogramming?
  • Which GHC extensions do you virtually always enable, and which ones do you think should be left alone?
  • What do you see as the biggest foot-gun for people starting out with Haskell?

Other questions:

  • What is your favorite animal?
  • What is your favorite beverage?
  • What do you think about hammocks?

Wow. Nice discussion already. Really enjoyed reading all those questions and answers.

Besides my interest in Haskell (I’m a beginner),
I‘m using nix for some time now.

You mentioned nix is your preferred tool to build and deploy Haskell projects.
Are you going to provide some examples in the book how to you use nix to achieve such things or at least some guidance for the curious? :smiley:


I love nix, but I had to make the hard choice to leave it out of the book. All of the examples are things you can definitely use nix with, and in fact I’ll likely include some nix code in the online source when the book is released. Unfortunately it would have been too much of a digression from the focus of the book to include it, and would have risked alienating readers who aren’t familiar with nix.


These are great questions!

What is your opinion on TemplateHaskell? What do you think of it compared to other approaches of metaprogramming?

I don’t use template haskell much. As a general rule, I prefer generic and type level programming over template haskell when possible, since they feel more natural to me when I’m writing code. I also find it a little easier to debug personally. I wouldn’t go so far as telling people not to use template haskell, but I did end up leaving it out of the book- mostly due to space constraints.

Which GHC extensions do you virtually always enable, and which ones do you think should be left alone?

I’d say OverloadedStrings is probably the extension I use most of all, since I just very rarely use String in most of my code. For my hobby projects I tend to either do a lot of type level programming, which comes with a large list of extensions, or focus on very performance oriented code- in those cases I don’t use many extensions.

For the hot take part of this answer, I personally avoid RecordDot notation, because I just really don’t like the aesthetics of it. I also tend to avoid LambdaCase because fairly often I end up refactoring my code and having to remove the lambda case anyway- and I don’t think it actually looks that much nicer. I use RecordWildcards more than I should- they make writing code really convenient, but I’ll admit that it can come at something of a maintenance burden later.

What do you see as the biggest foot-gun for people starting out with Haskell?

I think the biggest footgun of all is the lure of over-abstraction. Haskell offers up a lot of power, and sometimes people get really keen on using some new idea and try to shoehorn it into places they shouldn’t. As a learning exercise this can be a great way to get a feeling for an idea and when to use it, but it does end up being a problem when you are trying to get stuff done. I think it’s really helpful for people learning things in haskell to be mindful of when they are experimenting for the sake of learning, and when they are trying to be productive.

A more concrete footgun I think is laziness. A lot of Haskell developers think laziness was a mistake- I disagree. I think it’s a really fundamental and great feature of Haskell, but it can still be a footgun early on. Once you learn how to think about laziness, and how it works, then it’s not hard to work with, but until then it’s tricky. I make a point of covering laziness extensively as several points in the book to try to help save some of my readers toes :sweat_smile:

What is your favorite animal?

My favorite specific animal is my parrot, George, who makes several appearances in the book. I also love goats because they are just agents of pure chaos and I really feel that deeply in my soul. I’ve often suggested Haskell should adopt a Sloth as it’s mascot.

What is your favorite beverage?

I drink a lot of coffee (black) and LaCroix (beach plum and peach pear). I don’t drink alcohol often, but there is a wine bar in Minneapolis that I know of called “Haskell’s wine bar” and so I feel like I ought to at least try to like wine.

What do you think about hammocks?

They seem dangerous.


Wow, what a really fantastic overview … I need to learn functional programming! :nerd_face::+1:


Hi @RebeccaSkinner , I have attempted learning Haskell several times without success and I left several comments on my failed journey with the language. What would be your recommendations to a newcomer like myself that’s interested in leveraging Haskell to build applications and solve problems in the real world (i.e. healthcare and education)? Also, would your book be a good pragmatic resource for learning Haskell? BTW, I have worked as a software engineer for 10+ years using languages like C/C++, Java, Swift, Ruby, Elm, and most recently Elixir. I look forward to your feedback and huge congrats on the book.


Hi @RebeccaSkinner

Thanks for the interview and detailed responses to questions.

I’ve played around with Scala, Haskell and Clojure over the years, but I’ve never found an employer who allowed use of either. Every time I think or read about writing in pure functional languages, I’m reminded of both the joys and frustrations. I’ve worked pretty much exclusively in OO languages and so when I look at functional languages, they always feel restrictive at first. But I also found things that were so freeing and powerful. Pattern matching, easy composition and a simplicity that seems hidden initially because the thinking is so different.

While I still work in what would certainly be termed OO languages - mostly C# - I’ve been able to take some of that thinking into what I do day to day. I find myself thinking a lot about composing functions together and writing higher order functions to support this. I definitely think that using functional languages from time to time has made me a better developer overall and so I encourage people around me, especially at work, to give them a try. Unfortunately that seems to be a steeply uphill battle - people see functional languages as too hard, or think they’re a passing fad, or that there just won’t be enough people to maintain the code because there aren’t enough developers competent in the languages. I just keep hoping that my code is good enough that others will see it, be intrigued, and want to try it themselves. And then, eventually, consider actually using a functional language rather than just using the more functional features of languages like C#.


First, welcome back to Haskell. I’m glad you are interested in giving it another try!

“Experienced developer who bounced off Haskell a couple of times” is one of the core groups of people who I was hoping can benefit from my book. I think Effective Haskell might be a great fit for you!

For projects, I’ve tried to make sure that Effective Haskell has a good mix of shorter and longer projects. A couple of the longer exercises involve building a pager (like the unix cat command), writing a file archive tool (like tar) and building a spellchecking program (like aspell). I think building common command line tools like this can be a great place to start. Programs like this are well understood, so you don’t have to figure out what to build at the same time that you are learning a language and figuring out how to build it. They also have a good mixture of real world edge cases and more theory-focused problems. Another benefit to these types of applications is that they scale well- you can build an extremely simple version, or a much more fully featured application, depending on how much time you have and where your interests are. Finally, it’s really fun to be able to write tools you can actually use every day.


This is a tough situation that I think a lot of FP enthusiasts find themselves in. We are definitely seeing a rising tide of FP in software these days, but there’s still a long way to go.

I’d consider myself a polyglot developer. I love Haskell, but I’ve spent a lot of my career working in all sorts of other languages. I’ve learned a few hard lessons about introducing people to FP, and in particular Haskell, in the workplace.

Perhaps the most important piece of advice I can give is that, in my experience, writing functional with the hope that people will see how elegant it is almost never works. More often than not, people will become resentful and start to more actively reject FP on principle. I’ve definitely seen situations where someone who has been using Haskell for a while brings an idea over to another language, and it caused a rift on the team. In fact, my experience is that people are more likely to reject FP style code from someone they know is an FP enthusiast than they are to reject the same code from someone they don’t think of as a functional programmer. It’s a silly bias, and it won’t be that way everywhere, but I think it’s common enough that you have to address the possibility head on.

The second best piece of advice I can give is, under no circumstances, should you just write some code in Haskell and hope for the best. It’s a great way to have exactly one project in Haskell and to never be allowed to explore other languages in the workplace again. I think it’s a bad knee-jerk reaction teams have, but it’s the common reaction.

Here’s what works best in my own experience: Start by meeting the team where they are, and walk them through the motivation behind the ideas that you want to implement. Don’t present a solution- instead, introduce a series of problems. If you can get a PR in, and add incremental PRs to refactor something into a more functional style, with a clear explanation of what each change brings, and get some reviewers to buy in, that’s a good approach. If you have design or architecture meetings with your team, that’s another approach. Don’t say “let’s do FP”- just present a specific real problem in your code and then introduce a very practical fix that happens to borrow from a functional style. Once you’ve done that a few times, and helped people understand the problems you want to solve, and see the patterns for solutions, then you can talk about ways to abstract the ideas into something that borrows ideas from an FP language. Eventually, you might want to say “hey, we’re doing some stuff that is kind of FP style, maybe we should prototype this new feature in Haskell. If we do that, we’ll want to rewrite it in our main language when it goes to production, but it could be instructive.” and then offer to pair with people, write lots of documentation, or whatever else your team likes to do to share information. Maybe even have a reading group (this was another scenario I had in mind for Effective Haskell, and it’s why I spend so much time in the book trying to walk through the motivation behind particular features).

It’s a lot of work, and a lot of it requires paying attention to people’s feelings and the politics of the team as much as the technical motivations, but it can be done. I’ve never turned a team into an entirely Haskell team, but I have had broad team buy in on using Haskell for parts of a system, and had people who didn’t previously have much interest in FP become competent Haskellers able to contribute to that codebase. Not every team will be open to the idea, but a lot will when it’s approach the right way.


Hello everyone!

I’m your friendly Devtalk bot :nerd_face:

Thank you to all of you who participated in our Spotlight AMA!

This is now closed and all of those who commented above have been entered into the draw - meaning we’re now ready to pick a winner!

The process will be initiated when somebody clicks the special link below:

:arrow_right: :arrow_right: :arrow_right: Devtalk - Dev forum at Devtalk - the forum for developers! :arrow_left: :arrow_left: :arrow_left:

Don’t be shy, we need one of you to help make the magic happen! :sparkles:

1 Like

Thank you for initiating the draw process…

Entering the following members into the draw…

:arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down: :arrow_down:


And the winner is…

Drum roll…


Congratulations @lockejan you are the chosen one!! We’ll be in touch about your prize via PM soon :smiley:

Thank you everyone who entered, and of course @RebeccaSkinner for taking part in our Spotlight - thank you! :blue_heart:


Amazing. Looking forward to diving into it. :slight_smile:


Congratulations @lockejan ! I’ll be PMing you in a moment about your prize. :slight_smile:


Hi Rebecca,

Would you mind sharing your thoughts on Haskell in relation machine learning and AI. I have read some people saying that it won’t cut it because of so few libraries etc and haskell is way to hard to debug, but then I have also seen some saying that it has some awesome qualities that will make it more popular in ML in the future. IIRC (paraphrase) one guy wrote that because of some intrinsic qualities of haskell either ML will go more towards haskell or other languages will steal these haskell features.

Do you have an opinion on this?


That’s a great question, and the answer is pretty nuanced I think.

At a high level, I’d say that today Haskell is probably more widely used for data engineering than for implementing models, Haskell’s data modeling capabilities and strong support for streaming data make it a great fit for a lot of data engineering work, and if I were trying to look for the best way to introduce Haskell to an ML team, I’d probably start there.

When it comes to implementing models, I think the choice is a bit more nuanced. There’s a lot Haskell brings to the table. Being able to model your data accurately and working with the type system to help you write correct code is a great benefit to building models since it makes it much easier to reason about how your models are being built. Even more importantly, being a pure functional language Haskell can give you some really amazing guarantees when you want to be able to understand and describe your system. Being able to understand how your models produce a decision, and being able to reproduce those results or test new models against historic data are huge problems that come up in any sort of data team, and Haskell allows us to model these constraints and guarantee we’re clearly capturing our inputs and outputs.

There are some challenges that come with using Haskell for writing models too. Library support is a consideration, but I often remind people to not worry about all of the libraries you don’t have, and just look to see if there are the specific libraries you need. If you’re comparing Haskell to something built largely by gluing together pieces of SciKit or Pandas or something then the library support will probably be a bit disappointing, but if you’re implementing most of your model yourself then Haskell’s going to compare a lot more favorably. Another challenge I see people talk about when using Haskell to build models is the fact that it’s often not as ergonomic to work with Haskell early in the process of developing a model. Optics give us the tools we need to arbitrarily traverse deeply nested data structures in an ad-hoc way, and more advanced type system features like GADTs can help us write code that we might use dataframes for in python, but getting to the point where you can use those things comfortably can involve a bit of an upfront investment, and it’s sometimes hard to convince people who are comfortable with Python that it’s going to be worth it.

On the whole, I think Haskell can be a great choice, but it’s also a particularly hard sell to data scientists in my experience. I’d certainly encourage you to consider trying Haskell for your own problems, and certainly look at it for data engineering problems, but for building models it’s probably best to work with your team and help them get comfortable with Haskell before you start trying to build significant work with it.


Thanks for the detailed answer! Personally I am almost half way through the book now. This gave me some ideas to think about.