There are a lot of new languages on the scene at the moment and a lot of effort has gone into evaluating them but we have a unique perspective. What do the new languages offer if you have a functional view point and say a Haskell background?

Haskell’s weaknesses

The purpose of this section is to give you some insight on why I’m looking forward to new languages instead of being already content (with Haskell).

Apart from coding in Java for university projects and briefly checking out some other languages, I’ve been toying around with Haskell for around a year. Some of my impressions of it can be found on my blog, for example  “Experience Report: A Mastermind Simulation in Lua, Java and Haskell“.

Although I’ve had a lot of praise for Haskell’s virtues,  I have acknowledged its warts. And the more I've programmed and thought about the things I want to create, the more precise my ideas of what I want from a language have become and the bigger the warts have seemed.

One of the negative things I pointed out previously was the dreadful record syntax. Accessing (nested) fields is a nightmare and updating them even more. Not even lenses come close to the syntactic ease of field manipulation of conventional programming languages in my opinion. What’s even more tragic: everybody in the Haskell community is aware of this but despite endless discussions for years a solution is not to be seen on the horizon yet.

Lazy evaluation by default caused problems in every single project thus far - and they were not particularly large projects nor were they particularly complicated. Sometimes I searched eight hours for the source of a space leak. Other times I had to really dig around the internet to learn how to force a computation so that I could measure the time of said computation.

Each time I increased my “defeating-laziness-skills”, for example how to use the profiling tools and how to use deepseq, but for the next “lazy” challenge my skills weren’t good enough and I had to play the role of a detective again, which in fact wasn’t as fun as it sounds. And even though I acknowledge that there are theoretical advantages that are allowed by laziness, personally, I find it to cost more than it helps and I find it telling that even the most bright Haskell hackers have to tackle so much with space leaks. One of Haskell’s creators has actually released slides with the title “The next Haskell will be strict“. At any rate, I’m not the only person that dislikes laziness by default and there is a lot more that could be said about this topic. Read the paper “Why functional programming matters” to see some semantic advantages of laziness.

I don’t have the source for the following paraphrased quote but I’ve read it a couple of times in the Haskell mailing list:

Haskell makes some easy things harder and some difficult things easier

In some scenarios I wished for the good old for loop instead of a fold, which is arguably as “low-level” as a for loop, or some not-so-clear combination of some local or inline function definitions and compositions of several combinators. Now I know you can mimic for and while loops in Haskell, but then you are in monadic land and anyhow - they are syntactically and semantically not quite the same.

What this point actually boils down to is that I want a language where immutability as well as mutability are treated like first class citizens. Let’s be honest: if you want to do some things that are easy in conventional, imperative or “unpure” languages, prepare for a syntactic and semantic overhead of concepts in Haskell. It’s not that it’s too hard to understand how to do it in Haskell, but rather too cumbersome in my opinion.

Here’s a sentiment that I stumbled upon in one of the soon-to-be-presented languages (Disciple) and that I share fully:

We still think the Monad type class is useful, and we support it as well. However, when writing Haskell programs we’ve found that most uses of Monad are for IO, and to manage the internal state of the program. In Disciple, we use effects for state-based functions because it’s more convenient, and reserve Monad for things that definitely want a non-standard notion of sequence, like parser combinators. 

Source

There are other problems that could be talked about:

• the overwhelmingness and confusion of new concepts: conduits, iterators, enumerators, etc
• package dependency hell (which I have experienced fully)
• standard libraries could be more consistent (e.g. only map, not fmap…)
• …

but I think I've made my dissatisfaction with Haskell clear and I hope this makes it easier to understand how I judge the languages I'm about to present. By the way, if you want to read criticism against Haskell from a far more credible person than me have a look at Robert Harper’s blog and at some of the discussions in the comments.

Well, I didn’t think that I would write so much in this section. I may sound bitter / overly demanding but don’t get me wrong - it’s simply because I care. Despite its weaknesses, I still think that Haskell is a pretty good language / language environment when compared to the status quo of mainstream programming languages - especially for tasks that functional programming languages are naturally good at. Plus, every new language has to first build a healthy ecosystem around itself which Haskell already has. However, it is also glaringly obvious that (drastic) improvements on Haskell and other languages are entirely possible. But don’t just take my word for it.

The existence of a new stream of programming languages is proof that others feel the same way.