8 months of OCaml after 8 years of Haskell in production

Links
#55

I want Haskell to be an inspiring language that embodies a vision, by taking a small number of unifying ideas, and see where they lead. Specifically:

  • Purely functional programming.
  • High-end static type systems

Now, that may not be everybody’s vision. Maybe the vision will die; maybe no one will use Haskell or OCaml, and maybe no one will care about functional programming. But I am much more optimistic than that. I think that purely-functional, statically-typed programming is just a better way to write programs, and
that has steadily become more and more apparent over the last four decades.

It is certainly possible that, rather than adopting Haskell or OCaml as-is, the mainstream world will simply absorb the ideas that they embody. Indeed, you can see Lisp/ML/Haskell/Ocaml fingerprints all over mainstream languages: garbage collection, lambdas, type classes, monads, generics, comprehensions, and so on. The ideas may not be as elegantly expressed, and in some cases may not even be feasible in practice (e.g. STM flourishes in Haskell but has been mostly abandoned by the mainstream); but they can still be extremely influential.

So what is the role of the Haskell community? I suggest

  • Stay true to the vision. Make Haskell elegant, expressive, and crucially (as others have said) fun.
  • Work hard to knock down obstacles to using Haskell in mission-critical applications.
  • Do all this in a collegial, diverse, open-source community, in which people trust each other.

See the Haskell Foundation vision.

These goals are enough for me personally. Maybe it will result in Haskell being more widely adopted; maybe not. But meanwhile it is a rich, rewarding, and intellectually challenging endeavour.

51 Likes
#56

I wouldn’t but I wouldn’t recommend against either.
My main concern will be, not the language itself, but the recruitment (which depends largely on the physical location).

1 Like
#57

Exactly. My answer to the question “should I use Haskell” is basically “if you hire me”.

  • hiring is hard
  • senior Haskellers are expensive
  • talented Haskell juniors will stay 1-2 years max in your company, before they transition to an employer you can’t compete with
  • many programming domains are underpresented in Haskell apart from generic backends, which means you might end up doing very heavy lifting of being a pioneer (this comes from painful experience of dealing with a custom event sourced Haskell backend)
  • many of the libraries you use will be abandoned half way into your project
  • onboarding new Haskellers is always challenging: people are into different corners of the language and what seems like an easy to understand codebase for some, is a nightmare for others
  • a Haskell codebase that has survived a couple of generations of different Haskellers can look like an odd giant… because there are so many ways to do the same thing
  • the tooling can easily become a bottleneck… compile times, HLS crashing, expensive GHC upgrades, …

And yet… it’s fun, at times.

So… “should I use Haskell?”. Well, “no”, unless you know what you’re getting into or you’re an invested enthusiasts.

But… I think that perception should change too. I’d like to recommend Haskell even to people who are not FP enthusiasts and say: “Yes, use Haskell, because the libraries are excellent, the tooling is smooth, the compiler is reliable and fast, hiring is easy and there’s lots of great documentation and advanced guides on how to evolve and structure your projects”.

That is a different kind of fun… it’s the fun that comes with smooth, pleasant user-experience and less with an expressive, elegant language.

We’ve managed the latter through those excellent researches like @simonpj, pioneering language research. But I think there’s a long way to go to make Haskell fun in those more boring ways.

So no, I don’t think I’m trivializing fun in software development.

12 Likes
#58

A counterpoint:

Hiring people who wanted to work with Haskell was very easy for us. We are the only Haskell team currently, so there was a lot os skepticism at the outset. We managed to hire the full team in record time, to the point that other managers asked me what my secret was.

16 Likes
#59

A breakthrough might happen (and I think it’ll come from cutting-edge features, not stability). Things like lens, servant or parallel computing are things were Haskell shines (obviously not enough).

That’s a very good idea. Making Haskell even more practical is probably not the best way to increase its user base. Making it more fun, creating absolutely new things no other language has (or even can have) — that’s the way to go.

Doing things in a fear of the language not being used otherwise could be a self-fulfilling prophesy. Haskell could become so stable and filled with backward compatibility that there will be no fun in using it.

Obvious obstacles should be fixed indeed, even more so if in a backwards compatible way. But it shouldn’t be the main focus.

5 Likes
#60

As for any other innovation:

#61

Please, can we not start this Neo thing again :slight_smile:

2 Likes
#62

But wouldn’t a successor to (Glasgow) Haskell be the ultimate innovation? If not, another option is a new Haskell compiler…

#63

Basically, you think Haskell adoption (especially among industries) will increase if there were less frictions. Unfortunately it works the other around. That friction will diminishes overnight if one of the big company decided to use Haskell.

The problem if I am right is, it means that big companies don’t believe in Haskell (even though we know there are aware of it existences), and we are wrong : Haskell is not the silver bullet we want to think it is.

1 Like
#64

I think the friction is more philosophical than technical tbh. Better tools won’t resolve that.

But we don’t need anyone and everyone to adopt Haskell! There’s a saying: “Marketing is deciding who not to sell to” :grin:

1 Like
#65
  • hiring is hard
    …
  • talented Haskell juniors will stay 1-2 years max in your company, before they transition to an employer you can’t compete with

So it’s both not hard for someone to hire and not that hard to find a job (which seems many people have an issue with)?

Excellent points about other aspects. For me, the main fun of the Haskell is how elegantly one can solve problems in it. Basically, how amazingly good a good software design looks in Haskell.

Unfortunately, people rarely write about simple Haskell that does the work well as it’s not that interesting. But people love to write about crazy experiments. Which is great and pushes progress forward, but it leads others to think that this is Haskell. Then people start using experimental effect systems or lenses everywhere, and we get:

  • onboarding new Haskellers is always challenging: people are into different corners of the language and what seems like an easy to understand codebase for some, is a nightmare for others

I think Haskell lacks a body of industrial usage wisdom. Everyone knows that C++ template metaprogramming leads to overcomplication, but not everyone knows which Haskell features/approaches should or should not be used in production systems.

Haskell’s expressiveness is a double-edged sword: one can both implement an amazingly simple and an amazingly complicated solution. And this is something that should be covered more in a Haskell world (“software engineering fun”?).

One can jump to OCaml in search of simplicity, but that’s like throwing the baby out with the bathwater.

7 Likes
#66

Heh I wrote a little (over-simplified) gist about the tension that arises from this in general (not just juniors) years ago PLs-misaligned-incentives.md · GitHub

1 Like
#67

That friction will diminishes overnight if one of the big company decided to use Haskell

IIUC, the current OCaml splash is mostly thanks to Jane Street backing a lot of new features.

It’s quite fun that about 15 years ago OCaml was basically a dead language. I could write a similar “4 months of Haskell after 4 years of OCaml” when I made an opposite switch back then:

  • Haskell has a parallel runtime,
  • more features,
  • more libraries,
  • more tools,
  • bigger and more active community,
  • nicer syntax,
  • type classes, lazy evaluation, …
  • slightly slower in some sequential programs, but we could fix it with parallelism

Only parallelism aspect has changed recently.

What’s interesting is that more features lead to unnecessary over-complication and that’s the point I’m completely agree with @ChShersh. I’m not yet sure what to do with this.

7 Likes
#68

Fair enough, but in the case of Haskell, it is easy to limit features in a enterprise context by limiting authorized extensions.

3 Likes
#69

…just remember to get ear-plugs or noise-cancelling ear/head-phones when the bikeshedding begins at each code review: "this would be so much easier if we could just use $LANG_EXTENSION…"

1 Like
#70

Unfortunately, it’s possible to abuse basic features like type classes and lazy evaluation (monad transformers and lenses do not require a lot of extensions).

Even a more concise syntax can be abused. OCaml uses @@ instead of $ and doesn’t have a function composition operator, so one needs to be either more explicit/wordy or not abstract some things at all.

Haskell allows a much better function composition style, but one needs to find a balance between making code cleaner and making it point-free garbage.

5 Likes
#71

No language, natural or artificial, will make it unnecessary to learn and practice eloquence.

11 Likes
#72

There it is:

…it wasn’t always like this:

So Haskell wasn’t always the centre of innovation it’s seen as now, with some of that occurring in a smaller Haskell-style language with its own (also smaller) implementation. Based on that observation, here’s a simple idea:

  • bring back Gofer for the purpose of innovation and exploration,

  • leaving Haskell to stabilise for use in production and education.

Ideally Haskell would then be a subset of Gofer, with new language features being migrated from Gofer to Haskell once they have proven to be useful for more than just (re)implementing Gofer. So there would be a need for Gofer to be accessible to the wider community, but in the manifest knowledge that Gofer will always be “subject to change with little, if any notice” - that would just be “life on the cutting-edge”…

2 Likes
#73

I don’t think either direction is correct. Real word complex systems evolve through small changes. In principle it’s possible that a large industrial user base could trigger a tipping point that eliminates friction in the language; on the other hand it’s possible that a large user base could be wiped out by too-high friction, especially once an alternative with less friction arises. Nonetheless, magically creating a large industrial user base is not one of the possibilities before us, so the only question that’s really important in this regard is “will the benefits of reducing friction be worth the costs?”. I suspect they will.

3 Likes
#74

True, but 20 years ago, Haskell tooling was on par if not better than other languages.
For C++, there were nothing if you were working on Unix (which my case at work).
You’ll have to create your makefile manually, download external lib yourself, no repl etc …
Same for Python (PIP was released in 2011). Cabal and GHCi were actually cutting edge. Writing a cabal file was a breeze compare to a makefile.
Having a repl for compiled language was also really good.
This “advance” in tooling didn’t boost Haskell adoption neither the C++ lacks of tooling deterred industry to adopt C++.

I believe that even, of course the tooling could be better, it’s good enough and people would give up Haskell because of the tooling would have given up anyway.

2 Likes