My talk "Functional Programming: Failed Successfully" is now available!

#29

I don’t want everyone to use Haskell though. I want the people who want to use Haskell to use Haskell.

It isn’t for everyone - and the things that cause that are kind of the parts I like? Its very nature means mainstream programmers won’t flock to it. Feature not a bug!

I don’t think Haskell or FP are objectively better ways to build things. I also don’t think program language choice matters all that much when it comes to project success.

Which is why the no1 reason I cite for choosing Haskell is just the fun factor. If I want myself (or someone wants me) to build something, the most important ingredient is that I actually bother to do it.

2 Likes
#30

I read the slides before seeing the talk and I didn’t miss the sarcasm, just letting you know.

I don’t think Haskell has a toxic community or an anti-industry focus. What’s true is that every single community of anything has a bunch of very vocal True Believers. Rust, Scala, C, C++, Java, I can come up with evangelism from every single one of them. So the toxicity you might see in Haskell is… part and parcel. Yes, it sucks. No, you can’t jail every single hooligan in the planet and achieve utopia. Yes, you should strive to do better. No, it’s not an apocalypse. Yes, it’s good to have reminders, I’m not telling you to shut up. No, that’s not THE problem.

So, what do I think is THE problem of Haskell? Why is it not popular in industry? It’s easy to answer. Haskell is hard. Haskell is very hard. For beginners, intermediates, and advanced users.

For beginners, Haskell demands you ditch simple reassignment of state and achieve purely functional means, and demands a firm grasp on recursion. Recursion alone is a roadblock for all newcomers to programming.

For intermediates, Haskell demands you know how to use monads, transformers, lenses, maps, lists, folds, semigroups, laziness, strictness, you name it. No, you don’t have to understand them. Just know how and when to use them. No, no math. No, no category theory. Learning how to use a framework like Servant or an extension like TypeFamilies is something new to learn, like another language. I’m not saying that learning is unfair. It’s not. I’m saying that it is too hard to learn these things. (Yes, other languages have things to learn and also have very hard things to learn too.) It is too time consuming to learn. Some tutorials point to white papers. Some people recommend hundred pages books. You want to set a field on a record and now you’re looking at affine traversals.

You can, you know, just not use these things. But they are everywhere. And profesionally you will have codebases that use them (or so I’ve heard). The complexity eroded by referential transparency returns hidden in increasing amounts of increasingly powerful abstractions.

For advanced users, there is even more to learn. Extensions to try. Build times to reduce. If you don’t have full awareness of laziness and full awareness of what accumulator is what, if you let any invalid state be actually valid because its laziness just slipped through your mind, if something fails to specialize and now it generates thunks and you need to understand specialization… there’s a lot to {-# UNPACK #-}. A good thing though is that concurrency comes practically FOR FREE, it’s actually amazing.

So all people have a hard (long) time learning, this translates to having less horsepower, and this translates to:

  1. Not having a NetBeans or IntelliJ for Haskell, fully customized to deal with any and all roadblocks. The average Joe is not going to become an Emacs wizard with over 9000 Nix flakes. VSCode is good enough. The Language Server and Cabal/Stack are good, and an amazing effort, but they are actually a expected standard for any modern language. There’s no industrial debugger for Haskell.
  2. Not having a myriad of small time content to climb the ranks of wizardry.

And the most important one for the average Joe, NO KILLER APPS:

  1. Other web frameworks are easier.
  2. The popular game engines are for other languages.
  3. No enterprise systems like Spring with all its docs.
  4. Python is easier to understand to act as glue for machine learning done in C.
  5. There’s no easy GUI to make small apps.

This is not to say Haskell isn’t useful. But there is no Apache Spark for Haskell. There is no Unity for Haskell. There’s probably a parser for your thing in your favorite language. (There is, however, pandoc, to lure some people in.)

And this translates to why industry doesn’t use Haskell. There’s not enough people. You need to pay fair compensation to get wizards to come work for you. They will leave and will need to be replaced. Will you find a replacement? Maybe. It’s too risky. It’s basic risk management. You can deal with splattering trace all over the place to debug a problem, you can deal with records not being ergonomic after years and years of talks, you can slap a monitor to see where all these thunks are coming from, but you can’t deal with non existent people. With Haskell, you can have 10x fun, 10x productivity, 10x reliability, but if the average Joe can barely learn how to write it and maintain it, 10x0 equals 0. So why not use Java? It’s not like we have to recall the 10 million dollar total chips distributed or somebody dies: the customer will complain about the null pointer, we will patch it, fire the scapegoat and hire somebody else for peanuts (free tip: you shouldn’t fire the guy that made the mistake because you fired the guy that just learned not to do it).

So, as you can see, curbstomping toxic evangelism won’t do anything in this regard. The solution is either:

  1. Improve the ergonomics of Haskell by evolving the standard and adopting libraries that make Haskell easier. This risks breaking industry builds. Of course, you risk changing the language for the worse and pissing off everybody. Easier said than done.
  2. Make a killer app for Haskell so that people put up with Haskell’s difficulty in order to use it. Easier said than done.

What a tall order, huh?

As for me, I love Haskell, will keep hacking at it, improving at it, and having fun with it.

8 Likes
#31

Thank you Alexander for your point of view, but that isn’t my experience. And I don’t get what you mean by “person from the outside”. If there’s some secret society you need to sign up to or a special handshake for Haskellers, I’ve never come across it. Perhaps that means I’ve always been on “the outside”? Haskell is unusual in being open-source with community decisions about how the language evolves and no large commercial sponsor. (Indeed no commercial sponsor at all over most of the time I’ve been taking part – beyond Microsoft supporting SPJ.)

What do you mean by “experience similar to mine”? Can you explain that without “sparking controversy”. What I do notice is that many people who were active with ideas for the language at the time I first took an interest, are no longer active. They didn’t have some big public stoush. (Perhaps there were some private stoushes?) They just faded away; and I miss them; I miss how the community used to work.

If your “experience” was some sort of hostility, I’ve never experienced that, despite my having many disagreements with where the language has been going over the past ~8 years.

I’d say you are entirely wrong in all of that characterisation. I’d go so far as to say huh? were you on another planet at the time.

One of the main arguments against was that dot syntax is not backwards-compatible with Haskell, because . has been used for function compose since 1990; and there’s not previously been a need for whitespace around any Haskell operators. Another argument was that there’s already a way to extract a named field from a record value. .field access dates from SQL ~1958, and from plenty other Assembly code languages of that era. I used it in DEC System-10 and PDP-11 Macro Assembly in the 1970’s. Frankly it owes f***-all to OOP languages. You are just wrong. It’s not difficult to check the facts – because Haskell is an open community, all the discussion is still on-line.

If you’ve experienced hostility (I say again, I haven’t) perhaps it’s because you persist in promulgating opinions that fly in the face of the facts?

BTW: I am quite disappointed with and hostile to .-syntax as it’s turned out. I don’t use it. So I’m not saying the above to support those who advocated for it.

So some advice for you: before you start disagreeing with what’s happening in the community, make double and triple sure you’ve established the facts and the history. If there’s any doubt remaining in your mind, approach the topic with an attitude of ‘can I just check I understand …’.

There’s plenty of non-native speakers in the Haskell community. I think everybody is welcoming and tolerant, and appreciative of just how hard it is to participate in technical discussion going on in a foreign language. But of course we can’t walk in your shoes. Never the less, English just is the language of the community. Nobody here (AFAICT) would be upset if you asked for clarification of some tricky piece of language – indeed that might be helping out English speakers too !

2 Likes
#32

Your previous paragraph made clear you think “mainstream” = “imperative”. A more charitable interpretation is that most programmers have no influence over what language/paradigm their employer chooses. Programming is their job. Why should they care particularly? They go home to their family and real life. They’re not ‘collective’ or ‘hive’ or ‘cancelling’: they merely have more than enough programming at work; they don’t wish their job to leak into their life. They don’t haunt discussion forums about work-topics outside of the need to keep up with their tools of trade.

I was a commercial/imperative programmer for ~30 years. Never heard of him. My employers had no use for Python. It’s an icky language for hackers – in their opinion.

#33

There is nothing “simple” about reassigning state. It must be that you’ve used the imperative (or OO) model for so long you’ve forgotten how much of a learning curve it was at first. Side effects, race conditions, sequence of operations, … are all complexity arising from state and changing state.

I can see that if you come to FP with assigning-state ingrained in your head as “simple”, you’ll find learning anything else “hard”.

Is it? I guess I was happy with recursion coming from school maths: factorials, Newton-Raphson. It was quite annoying I couldn’t use it in the first programming languages I learnt (Dartmouth BASIC, COBOL).

#34

It’s as straightforward as you make it.

It depends, because the first programs you make, you can have them in your head and run them step by step until you reach the final instruction. Single thread, no coroutines or async, no race conditions, and if the sequence is wrong then it’s on you but for real. And you can get away with globalizing everything until you reach a very nasty bug, which is why people do it and then cry about it. But I figured out functional programming stratagems by myself before I formally got introduced to it.

That’s true.

It is. It’s not a joke that fizzbuzz can be a filter and recursion introduces a powerful abstraction early on that may be hard to grasp.
I did HTML/PHP/Perl in school and then Pascal, Modula-2, C, Java, Octave/MATLAB/R, SWI-Prolog, Haskell, in college in that order. I got over 95% score on the the Pascal, C, Prolog and Haskell classes so you can tell I didn’t get filtered by pointers or by having to build a parser and a tiny C interpreter in Haskell.
I know people that got ravaged by pointers and switched to electrical and civil.
The Haskell 1 course was about 60 people and 30 of them quit. Of the 30 people left, 10 failed, 10 barely passed, and 10 did great.
The Haskell 2 course was 3 people (including me).
You didn’t need Haskell for the degree, haha.

#35

If it really is that straightforward, then based on your Haskell experience…could you provide a concise mathematical description of it for the rest of us? :-D

#36

It’s a monoid in the category of the input outputs.

1 Like
#37

Alright…so how does that explain concurrency and nondeterminism (also in concise mathematical terms)?

#38

You compose them.

It’s an applicative.

1 Like
#39

Now can you use those concise mathematical descriptions to provide us with a working all-in-Haskell implementation of state (so no using “external entities” like primitive functions or types, foreign calls, et al )?

#40

No, because Haskell is useless.

Q.E.D

#41

Therefore:

…otherwise it could be expressed entirely in Haskell.

#42

Write a Haskell kernel.

#43

Would either of these be sufficient?

#44

image

gets Haskell kernel
looks inside
it’s all C

1 Like
#45

What about a minimal model of an OS in (an earlier version of) Haskell?

#46

You and me both know that to flip a bit you will call C.

#47

…or maybe assembly language - either way:

…otherwise it could be expressed entirely in Haskell.

#48

Or it is simple and Haskell is infinitely complex.