What Is Good About Haskell?

And also to point to this excellent article: https://pchiusano.github.io/2017-01-20/why-not-haskell.html

I use

http://hackage.haskell.org/package/optparse-applicative for small cli apps

http://hackage.haskell.org/package/envparse For any Docker microservice

http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A... For all JSON work. Sometimes I’ll use it with lenses which is massively powerful but a rabbit hole

I’ll use http://hackage.haskell.org/package/stm when dealing with parallel execution

https://github.com/brendanhay/amazonka For anything dealing with AWS

https://github.com/haskell-works?tab=repositories Projects for Kafka and avro

http://hackage.haskell.org/package/warp For trivial micro services or Scotty if more than a few endpoints

http://hackage.haskell.org/package/persistent For dealing with Postgres

http://hackage.haskell.org/package/parsec For dealing with any text parsing.

The tools are available, they can make things like cli apps and micro services trivial. However if you have never used a ML language before you will have a steep learning curve as very different to C style/based languages.

I was once of the opinion Haskell is academic, what can you use it for in the real world. Then I studied with it, played with it admittedly on and off over 1-2 years, hit hurdles where I had to think as so different to what I’ve learnt before. Eventually it clicked, it’s very hard and frustrating now in my day job using typical enterprise or popular languages. It’s not about convincing, it’s about having a open mind and wanting to learn something different

For example, pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler. One makes the code a bit more concise and readable, but not necessarily a whole lot more maintainable. The other takes one of the more annoying and error-prone portions of my (say) Java code and renders it far more manageable.

There's a recent LispCast that talks about this a bit: https://lispcast.com/what-is-data-orientation/

And every non-trivial program I've worked on is 90% of a compiler. (You could describe compilers as just "some business logic in the middle", too, if you were in Architecture Astronaut mode.) You don't think HTTP servers use "pattern matching"? You don't think API endpoints would benefit from "ridiculously easy" testing? This is your bread and butter.

This article is showing how to implement if-statements and null-checks in Haskell, and reduce your code size by half. I bet you have some of those in your software. I'm not sure how this could be much more relevant, without reducing its usefulness by being overly specific.

If you want to learn statically typed functional programming learn Elm (which takes only a few days), then one of F# or OCaml.

If you want to learn dynamically typed Functional Programming, learn Clojure or Racket/Scheme.

They amount of investment it takes to see return on learning Haskell makes it terrible for an introductory language. And every proponent of it glosses over this part. It has some advanced concepts but its not an introductory language.

There is so much benefit you can get to your coding from learning FP that you should pick a language that allows you to see and judge that value prop on your own quickly, not have to invest so much time to be haskell proficient to try to get the return on your learning.

In general terms, almost everything you and I do is either a CRUD app, or something overcomplicated which would be better-implemented as a CRUD app. There's not technological advancement happening here. And usually you're not even doing a new CRUD app, you're just reimplementing an earlier CRUD app with better CSS and JS and a different marketing team to tout it. IF there's an innovation in your company it's not the CRUD app developer who's innovating. We're just reimplementing the wheel over and over, because the other wheel implementations are closed source and owned by a competitor.

If you want to innovate, you have to take on harder problems that aren't CRUD apps. That's where languages like Haskell shine. Haskell doesn't shine because it's better, it shines because it's different, and suited for different tasks. The tasks for which Haskell is suited haven't been saturated yet, so there's still room for innovating on the technical side of things.

So yeah, I can't show you how to do what you do with Haskell--the reason you'd want to use Haskell in the first place is to do something different from what you (and most other developers, myself included) are doing. The reason you'd want to write Haskell is to solve technical problems which haven't already been solved.

You're right to bring up binary search trees and linked lists as criticisms of the Haskell community, because those are also pretty solved areas: touting binary search and linked lists as the powers of Haskell completely undersells Haskell. Haskell learning materials fall into two basic categories: complete beginner stuff, and Ph.D. theses written in an alien language. This is, unfortunately, part of why there's any innovation to be had here: having very little mid-level learning material creates a barrier for entry that keeps people from reaching a level where they could innovate. The same is true for the communities of many less-widely-used languages.

This has been a rather cynical post, I realize. I'm not sure there's any recommendations here: I'm certainly not going all-in on learning Haskell and using it to innovate, myself. CRUD apps pay the bills and innovation is risky. I find interest and novelty in other areas of my life.

I wrote the article a while ago after being frustrated using a bunch of Go and Python at an internship. Often I really wanted simple algebraic data types and pattern-matching, but when I looked up why Go didn't have them I saw a lot of justifications that amounted to "functional features are too complex and we're making a simple language. Haskell is notoriously complex". In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. So I wanted to write an article demonstrating that, while Haskell has a lot of out-there stuff in it, there's a bunch of simple ideas which really shouldn't be missing from any modern general-purpose language.

As to why I used a binary tree as the example, I thought it was pretty self-contained, and I find skew heaps quite interesting.

If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).

The pure FP Scala community understands your complaints more than the Haskell community.

https://typelevel.org/ is chock full of

a) useful utilities for actually writing applications

b) decent documentation. Not just pages of type signatures, but demonstrations of the libs usage.

Everything you need is here: JSON, config, units of measure, streams, testing, validation, a really nice JDBC wrapper (https://tpolecat.github.io/doobie/)

Throw in https://http4s.org/ and you've got yourself a rock-solid, purely functional stack with sensible, documented APIs, a more readable syntax and better tooling support.

I urge anyone who learnt some Haskell, thought "man this shit sucks, I'm never going to write something useful in this" to at least give FP Scala a chance. Here's a useful service template to start hacking with: https://github.com/http4s/http4s.g8.

I feel like the F# community tends to be more grounded in reality. Or at least I'm more exposed to the side of it that is trying to popularize it in Microsoft, as a useful tool for Domain Driven Design and the like.

Is Stack not adequate? I thought the consensus was that it was ok. Is it really more horrible than say Maven or SBT or whatever in other languages?

This is fundamentally why it's useless in practice. It requires you to anticipate/predict everything ahead of implementation.

It requires you to be perfect at Waterfall ( https://en.wikipedia.org/wiki/Waterfall_model ).

Real-world problems laugh at such idealism.

In my experience working in the largest Haskell team in the world, dealing with various applications and services in production: none of what you said is close to reality.

Applications and building large systems are explicitly goals of Haskell. Haskell was never intended to be a research language.

If only weren't web only and run as a private project. An elm like language with llvm backend would be amazing

1) Many of us have also seen the C++ library or application that busts out the template metaprograms at every opportunity. Haskell is the same. Use restraint when bringing in new libraries and programming techniques. (as an aside, I have yet to encounter a single problem that I thought merited the use of arrows)

2) You also see this in other languages, though to a lesser degree. The same techniques we use with other languages work just as well in Haskell: As leadership, form a strong opinion on the best way to write control flow and ensure that everything uses a consistent style.

3) Are your engineers running around implementing random research papers? This has nothing to do with Haskell.

4) In practice, this is almost never a big problem. Refactoring a pure function to an effectful function is easy and safe. In a production setting, almost all of your functions run in some monad already, so it's pretty rare to run into a situation where you suddenly need to percolate effects through many functions.

That's a huge red flag.

As for the rest.. I don't think the language was the problem at that team.

I don't like the "simple language means understandable code" argument being thrown around like it was some obvious fact. I'm currently working on a project whose major component is a byzantine home-grown message passing framework written in pretty much Java-in-C++ (old school OO with liberal use of shared pointers. Not that I would call C++ in any form "simple", but I do think that C++ without template magic is simpler than Haskell with GHC magic, or, say, any Lisp with a lot of macros). Maybe it's a case of grass being greener on the other side, but I'd gladly take a monad transformer stack or a DSL written in Lisp macros over doing the same song and a dance over and over again just to implent a tiny new functionality, or trying to deduce the logic from someone else's sea of boilerplate.

I mean, taking this logic to extreme, one could say that code written in assembly is easy to understand: it's adding a value to EAX now, then it jumps over there...

This being said, Haskell does have something in it that encourages one to design a ballistic algebra that runs in the type system before even pointing a gun at one's foot.

You can say the same thing about production Java code buried under layers of frameworks, factories, facades, proxies, aspects, annotations, etc. I don't see why readable, maintainable code can't be written as easily in Haskell as Java, C++, Python - you just have to make writing clean code a priority.

If you are stuck on a plane are you going to watch citizen kane or something from the last couple of years. What about an Akira Kurosawa movie? They top film critics' lists of the 'best' movies, but really they are some of the most influential movies of all time.

Lisp and Haskell aren't the 'best' languages to use the vast majority of the time, but they heavily influential and have contributed a lot to computer science.

Let's assume that your on call person is a developer. (If the person is not a developer, (s)he is not going to comprehend any language.)

1) If your application is written in Haskell, the on call developer would more than likely have been involved in the code base and reads Haskell. Your assertion about not comprehending it seems suspect.

2) You have a serious process issue if a developer is woken from a sound sleep to track down, correct, thoroughly test, and promote a fix for the bug in the middle of the night. The number of cases in which this happens should be close enough to zero to call it zero.

Your comment sounds like an attempt to cast Haskell as a purely academic language because it fails a (poorly) made up real world scenario. I'm NOT a Haskell-er so I don't feel a need to defend it. I do find the reasoning behind the criticism poorly thought out.

1) For a team of Haskell programmers reading Haskell code is just the norm. It's the same as for a team of Python programmers reading Python code. Also as a side-note: I never in my 15 years of professional life had a 4am call. Maybe I'm lucky, I don't know. In my experience automated tests, code reviews, sane deployment policies, etc... all minimise the chance of this ever happening. Haskell's powerful type system helps a lot here as it saves you from a whole array of problems upfront. I feel much more confident deploying Haskell code to production than code in any other language.

2) In commercial projects engineers tend to do things in sane and simple ways. This is not surprising really. Just cause you can does not mean you should. It's not Haskell specific but a general principle ie. KISS.

3) "Fancy research papers" at times can actually be really helpful. If you happen to have a problem that someone wrote a paper about that saves you time having to rediscover the solution. Having lots of research papers is imho a great strength of Haskell. That being said KISS from above applies here. If your problem is simple then do it simply.

4) Architecture in general is much less sensitive to change in Haskell than in other languages in my experience as the type checker guides you when you want to change your code. Refactoring in Haskell is pure joy. Re logging/configuration/etc... there are well-known patterns to deal with these as you would imagine, it's not like no one had to solve these problems in Haskell before. There are also tools (eg. Debug.Trace) in case you need some quick ad-hoc printf-style debugging. The same really as in any other language.

I don't want to write about all the pros of the language, others have done so already, just wanted to add my own professional experience to the mix.

Not a serious Haskeller at all, so not sure if this is a terrible practice, but for logging, `unsafePerformIO` could work in a pinch without changing types.

I would say that's a software company's biggest problem instead. I really don't understand how someone with little or no coding experience can be in a leadership position with other programmers who are supposed to be problem solvers and have all the details of how to build something. The bigger the gap in knowledge, the more communication breaks down and the hierarchical structure becomes useless.

Here's my version of skew heap in Python 3, edited down to just the essential operations. (Link to slightly fuller version: https://gist.github.com/olooney/97643d07d69d22015ae5bb70c121...). It seems about as clean as the Haskell version presented, mainly because I used None to represent leaves (which is quite Pythonic.) Relative to the code presented in the article, it also benefits from a clear partition of trees of immutable nodes on the one hand, and a class to represent the mutable heap interface on the other.

    from typing import NamedTuple, Any, Optional

    class Node(NamedTuple):
        """A single Node in a binary tree."""
        value: Any
        left: Node
        right: Node

    def merge(p: Optional[Node], q: Optional[Node]) -> Node:
        """
        Implements the critical "merge" operation which is
        used by all operations on a SkewHeap. The merge operation
        does not mutate either tree but returns a new tree which
        contains the least item at the root and is in heap order.
        The resulting tree is not necessarily balanced.
        """
        if p is None: return q
        if q is None: return p

        if q.value < p.value:
            p, q = q, p

        return Node(p.value, merge(p.right, q), p.left)


    class SkewHeap:
        """
        A SkewHeap is a heap data structure which uses an unbalanced binary tree to
        store items. Although no attempt is made to balance the tree, it can be
        shown to have amortized O(log n) time complexity for all operations under
        the assumption that the items inserted are in random order.
        """   
        def __init__(self, items=tuple()):
            """
            SkewHeap() -> new, empty, skew heap.
            SkewHeap(iterable) -> new skew heap initialized from the iterable.
            """
            self.root = None
            for item in items:
                self.push(item)

        def push(self, value: Any):
            """Add an item to this heap."""
            node = Node(value, None, None)
            self.root = merge(self.root, node)

        def pop(self):
            """Remove the least item in this heap and return it."""
            if self.root is None:
                raise ValueError("Cannot pop empty SkewHeap")
            else:
                value = self.root.value
                self.root = merge(self.root.left, self.root.right)
                return value

        def union(self, other: 'SkewHeap') -> 'SkewHeap':
            """Return a new heap which contains all the items of this and another heap combined."""
            ret = SkewHeap()
            ret.root = merge(self.root, other.root)
            return ret

        def __bool__(self) -> bool:
            """Return true iff the heap is non-empty."""
            return self.root is not None

    def test():
        h1 = SkewHeap()
        for item in [42, 13, 50, 11, 14, 50, 91, 72, 91]:
            h1.push(item)
        h2 = SkewHeap([63, 15, 1, 22, 91, 11, 92, 99, 93])
        h = h1.union(h2)

        while h:
            print(h.pop())

The point of the post was really to argue that simple features like pattern matching, ADTs, and so on, should be in languages like Python and Go. Also I wanted to make the point that functional non-mutating APIs could be simple and tend to compose well: the `unfoldr` example was all about that. In that vein, it was important that I compare the Haskell code to an imperative version.

For instance, with your `reduce` improvement: I agree that the `reduce` version is better! It's simpler, cleaner, and easier to read. But Python these days is moving away from that sort of thing: `reduce` has been removed from the top-level available functions, and you're discouraged from using it as much as possible. The point I was making is that I think that move is a bad one.

Finally, while the Python code here is shorter, you still don't get any of the benefits of pattern-matching and ADTs.

* You can only deal with 2 cases cleanly (what if you wanted a separate case for the singleton tree?).

* You are not prevented from accessing unavailable fields.

* You don't get any exhaustiveness checking.

    enum Tree<A> {
        Leaf(A),
        Node(A, Box<Tree<A>>, Box<Tree<A>>),
    }

    data Tree a
      = Leaf
      | Node a (Tree a) (Tree a)

?

This is actually one of my main two beefs with Haskell:

     . The language is really interesting from a feature point of view, but the syntax, oh man. Looking at Haskell code when you switch back and forth from a more conventional language (C/C++/JS/Java/C#/Python/etc...) is a major headache. I can switch from C++ to Python without a second thought. Not so with Haskell.

     . You can't really predict how something will actually execute, that's left to the language to decide. While in some situations this is a desirable feature, in many, it isn't at all, especially if you're writing performance critical code.

You need something to represent a completely empty tree. You also need something to represent in a Tree node that "there is no child here". It makes sense to use the same thing for both. In Python and other languages with nullable references you can just use None (or null, or ...) for this. But ML-family languages have no nullable references. You could use option types instead, but that would look pretty complex, something like (my Haskell is rusty):

    data Tree a = Maybe (TreeStructure a)

    data TreeStructure a = TreeNode (Maybe (TreeStructure a)) (Maybe (TreeStructure a))

It's easier to have an empty leaf instead. Personally I would possibly call it EmptyLeaf or maybe NoTree instead of just Leaf.

Whether you’re a student fresh out of school, or you’ve been unemployed for 10 years as a sysadmin, or you’re an expert programmer already, Common Lisp is accessible to you. Those examples are real; they’re backgrounds of folks I either used to or currently work with. Being paid helps immensely.

So it’s not that the language is unlearnable, unreadable, or out-of-reach. (The pot-shots that random commenters in forums like these take on the language are usually shallow or even outright wrong.) In some cases, it’s even demonstrated to be asymptotically more productive.

So what’s the deal? I personally think it’s just that productivity isn’t in and of itself incentivizing enough. You know Python and C++, you’re relatively proficient at them, you know how to get the job done with them, why learn something new? Haskell/Lisp won’t get you a job (necessarily), it won’t allow you to do something with a computer that you fundamentally couldn’t do before, and it’ll suck up a lot of your time to figure out what’s going on with them. Moreover, there’s no big organization behind it (like Mozilla or Facebook or Microsoft or ...) so where’s the credibility? A bunch of researchers at some university? A bunch of open-source hackers?

I think one has to be personally invested in becoming a broadly more knowledgeable and more skilled programmer, just for the sake of it, and (IME) most people aren’t like that. I think one has to also have a penchant for finding simpler or more fundamental ways of solving problems, and that has to turn into an exploratory drive. Even if one is like that, learning Haskell is one of a hundred possible paths to improve oneself.

My comment shouldn’t be misconstrued as supporting a mindset of it being OK to just know a couple languages well. I think the hallmark of an excellent programmer is precisely this broad knowledge of not just tools, but ways of thinking, in order to solve the gnarly problems that come up in software.

In my experience it's usually some combination of FUD echoed throughout these comments such as:

Haskell is an academic language and cannot be understood be mere mortals

Well everyone is mortal and some people have learned Haskell so this is obviously hyperbole and meaningless. Is it difficult to understand? Yes... but I have a theory that this is largely because we aren't taught to think in the way Haskell asks us to. Most of us in industry invariably learn Haskell as a second or third language and by then certain patterns and expectations are present in our brains that we hold as truths.

The tragedy of this argument is that people think you have to understand everything in Haskell in order to get started. They point to more advanced features like lenses and profunctor optics and all of this jargon as proof. However I don't ever recall having to learn the entirety of template metaprogramming to get started in C++.

There's really a pyramid of features and the amount of Haskell you need to know to get started is small.

It is too hard to hire Haskell programmers

It's as hard as you make it out to be. There are plenty of people out there who would love to program in Haskell for their day job. When I started posting jobs for Haskell programmers my queue was full, constantly.

The problem is that unless your organization is fully invested in Haskell people in your organization will find ways to hijack this process in order to make it come true by moving the goal posts. It might be hard to find Haskell programmers in your area so they'll say you can't hire remote developers. Say you'll train people up into Haskell and they'll say we don't have anyone experienced enough, or not enough time, etc, etc.

It's not hard to hire programmers. It's hard dealing with people who don't want Haskell to be adopted in your org.

The documentation is poor, there aren't enough libraries, etc

This may have been true more than ten years ago but it no longer holds. The documentation is phenomenal. It seems rough if you're not used to reading type signatures. However once you are familiar with rudimentary levels of Haskell this disappears fast. Haskell is documented. Whenever you add a top-level signature you're adding documentation that not only enriches the program but documentation that cannot be wrong, go out of date, etc.

I think this one gets bandied around a lot by developers from big ecosystems that have deep corporate pockets to fund the development of frameworks, libraries, and tooling. Haskell has been getting more of that but it's still nothing compared to Java/.NET/Swift, etc.

Regardless there are libraries for every common task and ones that can do things with Haskell's type system that you simply cannot in other languages (or can only emulate, poorly, with possibly buggy run-time code introspections, templates, macros, etc).

The real world is messy and Haskell's type system just gets in the way

The real world is messy so why would you want to use a tool that makes incorrect programs permissible?

This comes up from folks who like how easy it is to get started with dynamic languages which are permissive about their inputs. I like this property of dynamic languages too.

What I don't like is all of the run time inspection I have to do in order to know what data is safe to use. At first this doesn't seem like a problem with unit tests and a tight feedback loop. However at larger scales in a code base it makes refactoring and reasoning about high-level patterns much harder. And despite the claim that "type errors are rarely ever the source of production issues anyway," I still find TypeError: undefined is not a function in logs more often than they'd like to think.

The point of all this is that we ship this code confident that we probably nailed ~85% of the problem and we tolerate the risk that there will be some number of errors that will be reported after the fact. Ship early and ship often. However in practice this sucks up a lot of time as a project matures.

I rather like the experience of not having to chase down where an errant null check as missed or where some code mistakenly mutated a shallow copy. I don't even have to think about that in Haskell. I can focus on the business domain logic.

First, it doesn't fit everywhere. The best advice I received is that FP fits best when you can think about your program as a pipe - data comes in, data goes out. The more your program doesn't look like that, the less well FP fits.

Now, Haskell can do non-FP things, but you're fighting against the nature of the language to do so. It's probably better to pick a language that you don't have to fight in order to write your program.

Second (though I'm not sure that this is actually a reason that people pay attention to): Compile time. How long does Haskell take to compile a multi-million-line code base? How long does Go take? (Yes, I know that Haskell may take fewer lines. It won't be enough fewer to make the compile time shorter, though, nor anywhere close.) If you've got a multi-million-line code base, you've probably got a reasonably large team, and you've probably had them for years. If they each compile, say, five times per day, and there are twenty of them, and they've been doing it for ten years, the time spent in compiling adds up to real serious money lost.

Third: For a large team, they won't all be A students. Half the programmers will be below average. I'm not sure that Haskell is a great language for them. I wonder if they can't do more damage with Haskell than they could with, say, Go. (Of course, they could do a lot of damage with C++, too...)

As the author of the post, I don't actually think I can make a compelling argument for why someone should switch to using Haskell in their day job. I don't have real experience in the software engineering industry, and from what little I do know language choice doesn't make a huge difference.

That said, I think it's valid to say that a given pattern is bad, or another pattern is better. I was trying to argue for that in the post in a couple cases that I think Haskell does well.

Perhaps we should use a language that is immutable and can reason about side-effects. Like Haskell?

I'm constantly sad that Standard ML is so outdated. No good tooling, no real unicode support, etc.

At least we have ocaml and F#.

Or the following:

             x
            / \
           /   \
          /     \
         y       None
        / \      / \
       /   \    /   \
    Leaf  Leaf Leaf Leaf

In what language? Did you mean ">=" or "<="? They mean the exact same thing in Haskell.

> "|" means an OR

It also means the same thing in Haskell.

  data Maybe a = Nothing | Just a

  max a b | a > b = a
          | otherwise = b

  odd x || x >= 5

A cool thing about Haskell is that it lets you define new operators. In the parsec package, you get the operator <|>, which keeps the meaning of OR but works with parsers.

  csvCell = csvQuotedCell <|> csvNonQuotedCell

> I'm cringed to see $s and \s in a program code that makes it look like LaTeX

I don't think they're so common that the comparison is valid. $s implies Template Haskell, which should be used sparingly. \s implies lambdas, which are nowhere near as common as the use of backslashes in LaTex.

> I also prefer the boundary of terms and expressions to be consistently marked up with parenthesis.

The way you wrote this, makes me think you prefer to write 2 + 5 * 2 as 2 + (5 * 2). You can do that, just like in any other language. I don't think it's common to add parenthesis redundantly in any language though.

If you actually meant something like preferring f x y to be written as f(x, y), it's not just a matter of taste. It's so the syntax makes sense with partial application. You can do

  f x y = ...
  g = f x
  h = g y

  f(x, y) = ...
  g = f(x)
  h = g(y)

People shouldn't downvote you: the sarcasm bit is funny, and it does actually point out to one of the major reason Haskell is not gaining more acceptance in spite of its many great features:

     . the syntax is completely alien (to the point of turning quasi APL-ish in some cases) and scares away potential users.

     . the community is so focused on esoteric stuff that the "how do I do X that's super easy to do in traditional languages" is completely missing from the conversation.