7 Reasons to Have Your Next Software Project Written in Haskell

Caveat Emptor

An important part of life is speaking the truth. Haskell projects are not for every person. Or company. Haskell is an advanced, difficult functional programming language that takes time for most engineers to grasp. It has a high learning curve, regardless of what people in the community preach. Because Haskell is such a high-level language, this can cause many problems, for example, finding qualified engineers to work with you. A business has to have a worthwhile product to justify using it. Full disclosure, I am one of those qualified software engineers and run my own software consulting business. More truth - I am not going to try and convince you to use Haskell. Honest. It could be a large mistake. I am just going to explain why I use it for my business.

After studying Computer Information Systems as an undergrad, 4 years working as a software developer at a cloud-based startup, then 2 1/2 years creating and running a software consulting company of my own, I’ve learned that the most effective tool for my business and my clients, is in fact, Haskell. This mostly has to do with the fact that I do the overwhelming majority of software development myself. And also that I work on medical, financial and government web applications. I put in the time to learn the language by recommendation of a good friend, Roy. I have experienced shipping production applications written in Haskell. And I know and appreciate the fact that I will always be learning, because Haskell was created in academia to explore Mathematics, namely Type Theory, it really has an “infinite skill ceiling.” Coming from a background writing software mainly in JavaScript and Ruby, Java then Python, what we would call “mainstream languages,” this article is again, anecdotal, based on firsthand experience. I’ve tried to be as objective as possible. Comments and suggestions - and please, corrections - are welcome and wholeheartedly appreciated. Just send me a message.

The Main Consideration: People First, Business Second

Meditate on the following.

What helps people, helps business.

Leo Burnett

I am a big fan of the Haskell programming language and community. While I find it is a powerful tool for writing software, technically speaking, interestingly enough I find it even more powerful from a business perspective. The reason is twofold.

On a personal level, as a professional computer programmer, it keep me interested in programming. A side-effect of learning Haskell is having to study mathematics. It is not essential, but if you do not care about understanding your computer programming language, you probably will not want to learn Haskell. The knowledge one gains through learning Haskell is not based on temporal technology that will be gone in less than one generation - it an exploration and discovery into a new universe of categories and types, the Curry-Howard Isomorphism, and the nature of software. One that has refreshed my mind. So it is, for me, less about zeal for the language and more about the underlying knowledge.

And of course secondly, Haskell simply enables me to produce better results more easily and enjoyably than before. Here’s why…

1. Haskell Programs Have Fewer Bugs

Haskell programs have fewer bugs than, say, not just the aforementioned mainstream languages, but also most other languages. This is a bold claim that requires some explanation - hold your comments until the end of the post though. Really, the only truly valid claim is the elimination of at least one class of bugs. But again, this article is anecdotal.

First, Haskell eliminates an entire class of bugs by nature of the language’s design: it has a strong, static type system. This means mistakes that stem from type mismatches are entirely avoided. As a brief example, a JavaScript program will let you run code that does not make sense, like 1 + "100", that is, adding a number with text? Whereas it is less possible to do something similar in Haskell. To a degree, the compiler or type-checker proves the correctness of your software. Secondly, Haskell is an almost pure functional programming language, which means code is separated into two parts: the mathematically pure, and impure. This allows developers to reason more thoroughly about program logic, and deal with code that has side effects, or impurities, in a more controlled fashion.

Because of these two main features, there are many tools in the Haskell ecosystem that leverage the language to further improve correctness. For example, because of Haskell’s type system, a library called QuickCheck can be used to generate hundreds of thousands of test cases for your program automatically, via property testing. Imagine throwing lots of random inputs into your program to see if it breaks. Taking this even further… theorem provers like Coq allow developers to mathematically prove software correctness. To be clear, theorem proving is not possible in Haskell as far as I know, but my point is, it is only one step away from Coq. Coq is a purely functional programming language based on the Calculus Inductive Constructions, has quite a few distinctions from Haskell that allow for proving correctness. See my other blog post for differences in the two type systems. Also, Coq is not Turing complete.

I will admit I am not the world’s best software engineer. And I have met brilliant people who can write great business applications better than I, even in languages other than Haskell. But as for me, I chose to use a programming language that helps catch and fix my mistakes for me. Paul Hudak wrote a great paper in 1994 that gets more into some auxiliary reasons for why engineers might find the language better suitable for important applications.

2. Adding Features and/or Extending Functionality is Safe and Easy

Similar to how software products evolve, here’s a quotation from Darwin about biology.

It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.

Charles Darwin

Your application is going to grow, new features are going to be added. And when when this happens you better hope these new features do not break existing features. Haskell, like all FP Languages, is extremely modular. Think about it in this way: Haskell programs consist of jigsaw puzzle pieces that can only fit together in a certain way, whereas one of the popular alternatives to FP, object oriented programming (OOP), creates programs that do not fit together but are laid out like uniform squares. The former allows for a well defined and determined movement, or outcome, while the later allows for an arbitrary “sliding around of pieces” and a larger number of configurations and outcomes. The FP principle here is called referential transparency.

3. Rapid Prototyping

Haskell is a high-level language. Qualitatively speaking, this means a person can do more with less code. In so many words, writing in Haskell is like describing what something is, whereas in Python, a programmer manually has to tell the computer what to do, what instructions to carry out.

So at the end of the day, using higher level languages, I get products to market faster.

4. Smaller Longterm Cost of Ownership

Over half the cost of software ownership comes from maintenance and support. Once a software product is written and launched, all is well. As time goes by however, inevitable design or requirements mistakes bubble up. And then they need to be fixed. There is a great article that gets into the numbers behind this. If Haskell programs have fewer bugs, it follows that longterm cost is reduced.

5. Performance, Performance, and Performance

The pattern I have found is that I will ship an application written in a mainstream programming language for a client, and then, as it gains traction and the user base grows, the application gets slower and slower. This is completely normal - first you write an application for correctness, then you optimize it, making it faster and faster. This is what retainers are for and is part of the ongoing cost of maintenance and support.

But as it turns out - Haskell programs run extremely fast from the beginning. This goes back to the fact that Haskell is compiled code, meaning an external program looks for ways to optimize the program before compiling or “building” it. Here’s a great paper showing Haskell’s speed versus lower level languages like C, one of the faster languages out there.

In addition, Haskell has a feature called lazy evaluation, which also contributes to its speed.

This is not a contest of who has the fastest programming language, and I do not want to misinform. Just saying Haskell is faster than mainstream languages like Ruby, Python and possibly, JavaScript, depending on the implementation. I know the V8 compiler is amazing, as it should be.

6. Vibrant Community Support

Haskell gets a lot of flak for being such an academic language, in the “Ivory Tower” sense. However, this can also really be seen as an advantage. Look at all the great products that have come out of the AI revolution - the research for a large majority of all these Machine and Deep Learning predictive algorithms has come from the academic community. Why not expect a similar outcome with a programming language?

There is also an incredible array of high quality libraries in the Haskell community. Checkout Hackage for more info.

7. Stay Ahead of Your Competition

The best way to predict the future is to invent it.

Alan Kay

Albeit I am biased, but I see a trend with Haskell and FP. What company does not want higher quality software, with fewer mistakes? To attract higher talent? We are now starting to see the industry pick up on this trend as well - Facebook recently rewrote a critical piece of the company’s Artificial Intelligence (AI) powered spam detection library in Haskell, and open-sourced a critical piece of that project, Haxl.

Haskell’s Pitfalls

As mentioned earlier, this article mostly pertains to important projects. That is, anything a person or company is willing to invest in. Haskell is a more difficult language to command and therefore there is a smaller pool of developers to choose from, so finding Haskell developers is generally harder. In my experience however, I have found and hear from friends that there are engineers dying to write something in Haskell.

There’s a great quotation that sums up the language well.

Due to the language’s nature and its firm roots in the academic world, the community is very math-minded; if you’re a pragmatic person, this can be overwhelming at times, and if you don’t speak the jargon, you’ll have a harder time than with many other languages.

Also consider that while libraries like QuickCheck are great, as well as Unit Testing and Integration Testing in general, they are never perfect (unless we are talking about a theorem prover).

Testing shows the presence, not the absence of bugs.


At the end of the day, maybe language decisions don’t matter so much. If your software products works well, then who cares what it is made of. But if not, maybe you should rethink what you are doing.