1. 15
  1.  

  2. 11

    This.

    Functional programmers often make what I consider to be a rookie sales mistake: they show 20 lines of C or Java code, then 4 lines of Haskell code, and argue that the Haskell code is better or more readable simply because it’s more terse. They’re unaware of the fact that they’re favoring their own idiom just because it’s more familiar.

    For small self-contained projects that will require minimal maintenance, any language will do. Use C if you want high performance, Python for its libraries, or Haskell if you have an able team, Clojure if you want its UX, and you’ll be fine. If you have a varying degree of programmer competence, changing requirements, high expected speed of development, and a high degree of interaction between peoples' code, then Haskell is probably the only language I’d fully trust for a production system. The nice thing about Haskell is that it slams the brakes on sloppy, enterprise-ish code practices and mediocre programmers. It just stops a lot of things (mostly bad things, like 95% of OOP) that are still possible in other languages.

    1. 9

      The nice thing about Haskell is that it slams the brakes on sloppy, enterprise-ish code practices and mediocre programmers.

      But it replaces it by type wizardry. There used to be a time where you could read a Haskell function signature and get an immediate grasp of what is going on. Nowadays, a lot of projects use all kinds of clever abstractions that make Haskell code difficult to read. And then there’s the graveyard of packages that use out-of-favor abstractions (e.g. arrows).

      If you have a varying degree of programmer competence, changing requirements, high expected speed of development, and a high degree of interaction between peoples' code, then Haskell is probably the only language I’d fully trust for a production system.

      This has rarely been proven empirically. The number of large, widely-used, long-term Haskell projects are at most a couple of dozen (GHC, pandoc, Simon M.’s work at Facebook, some financial firms), where projects are maintained by the top 1% which would set up reliable projects in any language.

      Also, you don’t take any other languages into account (as nickpsecurity hints at) that have a proven track record in various domains, e.g. Ada, SPARK, Erlang.

      1. 8

        But it replaces it by type wizardry. There used to be a time where you could read a Haskell function signature and get an immediate grasp of what is going on. Nowadays, a lot of projects use all kinds of clever abstractions that make Haskell code difficult to read.

        This is true, and the type wizardry has the dangerous trait of being useful. For example, you can put a type-safe of nested record/object updates with lens, but then you have type signatures like:

        Lens s t a b = forall f. (Functor f) => (s -> f t) -> a -> f b

        which is not the most intuitive expression of the concept.

        I prefer type wizardry over other forms of wizardry, though, for the reason that it disappears at runtime. It might make code not compile when it should, but I’d rather get those kinds of failures at compile time than in a running system.

        where projects are maintained by the top 1% which would set up reliable projects in any language.

        It might be that Haskell / ML experience is part of what brings them into the top 1 percent, though. I certainly owe credit to these languages for my acceleration as a programmer. I do agree that good programmers can write solid systems in any language, but I doubt that I’d be in the top 1-3% of programmers if I hadn’t spent so much time with these “unusual” languages, in the same way that I wouldn’t be in that group if I hadn’t explored C and assembly, even though I wouldn’t use assembly for most real-world projects.

        1. 1

          I’ve been looking at the Haskell examples recommended here and don’t find them persuasive. For example, Haxl depends on unsafe data transformations for its central operation. I’m also not persuaded that wrapping opaque state change operations in IO or equivalent makes them any more safe or clear or verifiable than referring to global state directly.

        2. 3

          then Haskell is probably the only language I’d fully trust for a production system

          Ada’s been doing that a long time. Has mitigations or types for the common errors that break stuff during maintenance. Eiffel, too, with Design-by-Contract. Haskell is an improvement probably.