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

#82

So many my points from the talk have real ground and are quite widespread across FP communities, especially Haskell. These things prevent its wider adoption and are seen by the outside world as misbeliefs or misconceptions. Of course, not the entire community supports everything but I don’t see a general disagreement with these:

  • “OOP is trash”
  • “Math is king”
  • “Mainstream is wrong. What it does is garbage. We know better”
  • “Software Engineering is Math. FP is Math”
  • “We have our oun way, we don’t need to follow rules of the industry”
  • “We’re fine in our small, isolated world, we don’t need Haskell to become more popular”.
  • “The industry is broken, we need to fix it. Haskell is a political weapon”

I recently learned that the purpose of HF is not industry adoption. The goal has changed therefore, and I can see why. The road to popularity goes through 1) recognizing 2) solving social problems (like those misbeliefs and narratives). This meets too much resistance, and needs a very different approach, so it’s easier to focus on technical terms and forget about wide adoption. If that’s so, let’s at least be honest about this. I will then stop trying to convince the outer world to use Haskell

#83

Alexander, this feels a bit like an act of rhetorical vandalism in what has been — with highs and lows — an informative discussion.
There are many interesting bits in your presentation; I am unconvinced advocacy will change much with regards to making Haskell more popular to management.

Part of the HF job is fostering industry adoption, e.g. see Haskell Certification Program. There are many ways to skin this functional cat.

4 Likes
#84

I recently learned that the purpose of HF is not industry adoption.

That’s a bit surprising. Where did you learn this? I’m a member of the board and I have not been aware of any change of purpose. The web site says

“An independent, non-profit organization dedicated to broadening the adoption of Haskell, by supporting its ecosystem of tools, libraries, education, and research.”

This is spelled out a bit more in the HF’s vision statement.

I think it is indeed true that industry adoption is not the sole goal of HF. Hence the slogan “Avoid success-at-all-costs”. For example, I would argue against compromising the conceptual integrity of the language in a single-minded pursuit of popularity.

But that does not mean that adoption is a non-goal – quite the reverse (see above). I personally spend a lot of time and effort working out how to reduce the friction of adoption by increasing stability, and the HF has a Stability Working Group that does nothing else. (Here’s a state of play document.)

I think that we should not characterise this conversation in terms of who is “right” and who is “wrong”. Rather, I would say that Haskell takes a single core idea (statically-typed, purely functional programming) and sees how far it will go. If that’s not what someone wants, then they shouldn’t use Haskell; it’s not that they are right or wrong – just that Haskell isn’t right for them. We should not (and I hope do not) claim that Haskell is Definitely Better than alternatives, that we are right and everyone else is wrong. It’s a grand experiment, to take a single radical idea, stick to it like glue, and see where it takes us. That has been the story of my professional life, starting in around 1984, and it has been a pretty exciting journey. I would love more people to adopt Haskell, but I want them to do so because they love the joy and beauty of the core ideas.

All that said, what we should do, I think, is to bear down relentlessly on accidental friction, things that make mainstream developers get fed up with Haskell, but that are not a consequence of the core vision for Haskell, but rather are simply engineering shortcomings. For example, before cabal it was a huge pain to get libraries distributed and installed; now it is a breeze. Huge win. But the list of accidental frictions is long, and it will continue to take a lot of design and engineering work to sort out.

The road to popularity goes through 1) recognizing 2) solving social problems (like those misbeliefs and narratives).

Even if we were to solve all the sources of technical friction, we would still have the social issues of perception, training, certification, recruitment, and so on. I totally agree that it’s not just technical! I also agree that as a community we are less good at addressing social problems than technical ones.

But different people have different skills, and I’d love to hear more from folk with good ideas for addressing “social friction” rather than just “technical friction”.

thanks for starting this thread

Simon

24 Likes
#85

Hi Simon,

This is the first time we’re talking to each other, I appreciate your detailed response.

I learned this from @tomjaguarpaw on Reddit/r/haskell. The exact quote is this:

Firstly, a point of information: (one of) the goal(s) of the Haskell Foundation is to broaden Haskell adoption. It not intended to push Haskell to industry specifically. (I personally happen to to believe it can’t do the former without the latter, but in principle there is a distinction.)

Maybe he can add something on this, because he said there was some discussion with other members of HF, and it’s better for us to get the info from the first hands of that discussion.

I was surprised, too. I often mention HF as an analog of Rust Foundation, and learning that they differ in goals was contradictory to what I thought.

I certainly don’t think that adoption is the only goal. It is essential as Haskell is still a reasearch language.

#86

For our purposes the key word in Tom’s quote is “specifically”. This shouldn’t be taken to mean that industry adoption is necessarily a non-goal. If I’m intepreting him right, he’s saying that the stated purpose is to broaden adoption, and some might interpret that to include industry adoption as a subgoal, and some might not. I hope he’ll clarify if I’m misinterpreting him!

8 Likes
#87

There may have been a miscommunication around “one of the goals” of the HF versus “the singular goal”. In my comment on the matter I was responding to the part of the talk which said:

There is a Haskell Foundation by the way. It’s an organization that is intended to push Haskell to the industry. It works almost for three years but Haskell is still on the decline[*] according to the graph.

I interpreted that to mean that “the singular goal of the HF is to push adoption Haskell in industry”. My comment in response was supposed to clarify that that is only one amongst many goals:

Firstly, a point of information: (one of) the goal(s) of the Haskell Foundation is to broaden Haskell adoption. It not intended to push Haskell to industry specifically. (I personally happen to to believe it can’t do the former without the latter, but in principle there is a distinction.)

So Simon is right: pushing for industry adoption is not the sole or primary goal of the HF, but it is a goal.

(To share more on my personal view: I happen to believe that making Haskell more suitable for adoption in industry should be the HF’s primary focus, but not all board members agree with me.)

N.B.: I’m the Vice Chair of the HF

[*] By the way, I don’t believe that the graph in question provides evidence of decline. For a comparison against Java and C# (as controls) see my comment on that topic on Reddit.

5 Likes
#88

I don’t know what this means, but will try to avoid that.

1 Like
#89

To what matters, I strongly believe HF should do some regular comprehensive sociology in order to have understanding of social and technical situation and to have a measurable Definition of Done to know if the goals are getting closer or not and what was done right/wrong.

#90

So the HF can do that more quickly: are there any analogous organisations (e.g. the Python Steering Council or Rust Foundation) which carry out regular comprehensive sociology and have a measurable definition of “done” or “completed” ? Then the HF can use their experiences as a point of reference…

1 Like
#91

I don’t quite know, but if they don’t do that, HF can be the first. I think the value of such sociology and a measurable (maybe unreachable) DoD can’t be denied

#92

Or perhaps those analogous organisations just don’t require such mechanisms - if that’s the case, then neither does the HF.

1 Like
#93

The Haskell community is by far the nicest and most welcoming community I’ve ever seen. Almost any other community would’ve repelled violently to such an endless stream of baseless accusations and straw man arguments like this one:

yet folks here keeping addressing them politely. Has anyone ever actually heard that software engineering is math? I certainly haven’t, it’s such a ridiculous take, almost like “biology is astronomy”. I can imagine somebody sufficiently crazy believes that software engineering is math, but is that common in the Haskell community? Absolutely not, in my opinion.

To me this all looks like an elaborated ad to boost the Alexander’s following on social media and sell more books, this isn’t an honest attempt to expose the limitations of our community. If you want to see how such an attempt would look like, check out Leaving Rust gamedev after 3 years: you’ll find there plentiful disclaimers, acknowledgements of own limitations, elaborate clarifications etc etc. And this is what the author thinks of Haskell by the way:

The closest thing to Rust’s view on ECS I can think of is Haskell, except, and I know this is an oversimplification but I’ll say it anyway, I do feel that the overall community in Haskell is a lot more mature, and that people in general tend to be more reasonable about the existence of other approaches, and view Haskell as a “fun tool to solve problems where it fits well”.

Haskell has its issues, but the critique here is just made up nonsense.

5 Likes
#96

is fast and loose reasoning math? idk but it sure is useful

2 Likes
#97

Sorry folks, I think this thread is over. I’ll not be responding anymore.

2 Likes
#98

I ask everyone to assume good faith in debating this talk.

Alexander, your talk comes with broad-strokes criticism of the community, I expect you to handle robust objections.

9 Likes
#99

I’m all yours, go ahead with your feedback, and then, when enough of it is collected, I’ll respond something, but for now I don’t feel it will be productive for me personally

1 Like
#100

In the correct context…I would say “it’s allowed”:

1 Like
#101

The story of I/O in Haskell provides a similar example: In 1990, Haskell version 1.0 used the dialogue as the basis for I/O (with the alternate continuation-based interface being implemented in terms of it)…and it was generally considered “cringe-worthy”. Fortunately, and based on prior research into category theory, the monadic interface was adapted for use in Haskell. For I/O, it worked “well enough” to be adopted as the replacement standard interface for Haskell 1.3 (released 1996).

So there may yet be a way to bring certain features normally associated with OO-languages into non-strict functional languages: find a “suitable” field of mathematics or logic which can be used to map said features into Haskell in a more formal way. As for some starting points:

#102

I don’t think anyone here believes any of that. You’re tilting at strawmen and it has been very tiring. I would tend to agree this thread has run its course.

2 Likes
#103

Maybe it is not so obvious for everyone in the community, but the accepted stability policy of GHC is not just a technical, but also a social milestone.

Although it is mainly the result of a few very engaged individuals, I think the presence of the HF has helped different groups and authorities recognize the significance of problems.

The academic language wizards and the strict industrial engineering people are talking to each other.

Only good can come out of this if we can manage to keep this productive tension alive.

13 Likes