Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
What killed Haskell, could kill Rust, too

At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.


What killed Haskell, could kill Rust, too

What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.

Is Haskell dead?

There was a time when Haskell was the language to watch. During the late 2000s through the 2010s, Haskell was the language everybody wished they could program in, but nobody did, except for maybe a few people. There were some pretty impressive projects that were done in Haskell. There were massive financial projects done. There were payroll projects that were written in. But perhaps the most impressive from the point of view of a purely functional language like Haskell was Pandoc which had a Haskell core. It slapped in the face the whole notion “Haskell is too slow”, or “Haskell just can’t do real things”. Of course it can, and it did.

What happened? Why did Haskell suddenly, pretty suddenly just stop? It’s certainly not alive now. No one is contemplating major projects in Haskell any longer. Who is a GHC Haskell programmer here? I presume there are one or two people with their hands in the air. The GHC Haskell dialect has kinda fallen into an academic language. No one was really considering anything serious.

Haskell in its time was at the forefront of functional programming. It was the language that kind of characterized or epitomized what FP was really about. There were other languages that were functional, but they were only sort of functional. And of course, I’m talking about languages like Scala, or JavaScript. Those were the two major competitors during the same mid 2000s. Scala, JavaScript, and eventually, Golang, and C++ were followers. Haskell led them. These languages learned a lot from Haskell. Anybody doing Scala now knows that the syntax of the for-comprehension and many of the libraries, come directly from the Haskell world.

Haskell ruled.

It ruled in a way that no other language could have at that time. It ruled technically. There was a productivity which is measured at perhaps a factor of five. A team of developers could get an application written and shipped five times faster than a Scala application, or a C++ application. A factor of five is fairly significant in our world.

Haskell also ruled in ways that were just beginning to grasp. How many of you are using monads? But I’m using monads in JavaScript, and I have a little bit of a monads in Rust. In Go, I can do amazing things with monads. The thing about that is that the Haskell people had that in mid 2000s. There were monads and algebraic data types that were immensely powerful long before most of us even thought about a monad.

Haskell ruled in a whole bunch of interesting ways and yet it died. What killed it?

I’m gonna use a word here, and I don’t want you to take the word the wrong way. The wrong way you could take the word is “evil”, and the other way you could take the word is “ignorant”. But it’s not quite even “ignorant”. The word I’m gonna use is “arrogance”.

There was an arrogance in the Haskell community. Not the evil kind, but the kind that told them that they were somehow better. That the tools they were using were somehow better. That the things they were doing were somehow better. There was the arrogance of those people who believed that victory was inevitable. This was not the slapping your face “you, stupid fool golang programmers” kind of arrogance, although there was plenty of that, too. Instead, it was a kind of arrogance of power. Because the Haskell people were writing a pretty powerful code, they did have a tiger by the tail. It was a powerful compiler, it was a powerful language, and they knew they could work miracles.

And yet, that wasn’t enough. Something insidious, something subtle happened. It caused their separation, they set aside the rest of the industry. The people outside the community who were writing everyday programs began to look at the corner of the eye where the Haskell people were doing: “Emm… Haskell people don’t seem to like us very much, I don’t think we’re gonna like them”.

Some of you might remember the Reddit discussions in the mid 2000s. A bunch of people were there. And they were talking about cool math things there. In those talks, they often were snickering about other languages like Go. It wasn’t anything significant, it wasn’t anything evil, they were just snickering: “He-he-he, mainstream people, ha!”. But I was a mainstream golang guy at that time! I didn’t like that. And I’ve been dealing with language wars in the next couple of years. And I said to them at that time “Do we really want to have language wars on Reddit?”. And the interesting thing about it was not about what they were snickering about, because they probably had a right to do that. What was interesting about is my reaction. My reaction was defensive. My reaction was “Well, you guys, go ahead and do your Haskell thing, but I’m the one who gets real work done.”

That’s the interesting division that got set up at the time. And it was fairly pervasive. There was an attitude among the Haskell community, and again, it’s not an evil attitude, not one that was born out of ill will. But there was an attitude that said “You know, our tools are so good, our language is so good, we don’t need to follow the rules. We can do something else. We don’t have to talk to other people. We don’t have to do the other kinds of programs.” Haskell people didn’t want to do the regular kinds of programs. They didn’t want to have to deal with the corporate database. They didn’t want to have to deal with the horrible schema that had evolved twenty years. It was just distasteful. And they found ways instead to do things like using category theory, and dependent types. They’ve built a wall around themselves, and they’ve chosen to live in a technological bubble. Isolated from the evils of the outside world.

I’m going to define a word here. It’s a word you all know. And this definition is just one of many. You can find other definitions of this word if you like. The word is “professionalism”. And I’m going to define it as “The discipline of the wielding of power”. We have a certain amount of power in our tools, in our languages. But it requires a discipline to wield that power. And it’s not just a discipline in the use of the tool, it’s a discipline in a relationship to the community at large. It is a discipline that says: yes, it is a powerful tool, but powerful tools kill very quickly. And they kill in surprising ways, so we’re going to be careful. And we’re not going to denigrate people who are a little bit less willing to use our smart powerful tools.

Let us redefine “progress” to mean: “Just because we can do a thing it does not necessarily follow that we must do that thing”.

So what killed Haskell is the parochialism, the inability to address the needs of the Enterprise.

Haskell was a stellar performer in certain constraint circumstances but it was limited in its ability or rather in a desire of its users to address the general problems of the Enterprise. There was a certain purity among those people. They didn’t want to step outside and so lead themselves in the soil of real work. There was an “us versus them” feeling of uncleanliness, and those of us on the other side of that boundary felt it palpably. Parochialism is an “Hey you” attitude. It’s a way of putting a big banner on the screen saying “Hey you, I’m gonna do my way and screw the rest of you”. It’s a way to say “We are great in our little domain, and the rest of the world can go to hell”.

What is my save?

I want to save Rust and all other wonderful works that are going on in this community from that same demise. Frankly, I don’t think it’s anywhere near going down that route. First of all, the community is I think more dynamic and larger, and I believe that there is no longer the antithesis “us versus them”. Those of us who are “strong C++ hormonal programmers” have relented. And everybody is looking around and thinking: “You know, there might be something to this Rust stuff.” But still, what is it? What can save Rust from going down the same path that Haskell went?

I’d name 3 things:

The first one is discipline. Discipline specifically in documentation. A technical discipline that can keep Lord Cunningham’s problem from happening. It is writing documentation. And by god, it is a hard thing to do. You just want to write the code. But you should write that damn documentation. I mean all of you have found how hard it is to sit down and say “I’m going to write a good documentation so that others could use my work easily”.

The professionalism of humility is something that may prevent the demise, the same kind of demise that occurred for Haskell. The “us versus them” attitude. No, I know there have been some funny advertisements like “Mac versus PC” thing. “I’m Rails, and I’m Java”. And I don’t think there is any harm in it unless you take it too seriously. Unless you build the wall. Or unless they build the wall in response.

And the last thing would be acceptance of solving the “dirty” problems. Solving the problems of the horrible schema. And we're gonna have to sit down and say “No, we’ll deal with that”. If we’re going to survive in the end, we have to address problems that everybody has. Otherwise someone else will address those problems.

Remember the fate of probably the most powerful and influential language of the 2000s. The language that was at the start of pure functional paradigm, the language that influenced so much of what we’re currently doing. The fate of that language was near oblivion. And the people who used it and loved it had to jump to Scala for a living, and it nearly killed them.

We have great tools in the Rust language. We could kill it by making a mess, we could kill it by being arrogant about it, we could kill it by ignoring the Enterprise. I suggest that we not follow that route.


As one might have guessed, this is not an essay. It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others). You are free to make any conclusions from this.

What killed Smalltalk, could kill Ruby, too

@ivank2139

This comment has been minimized.

Copy link

@ivank2139 ivank2139 commented Sep 7, 2020

Good article. I spent a career in Java and ended with Go. I have been very happy using Go in my projects and it works well for me. I don't miss Java at all.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@ivank2139

Thanks! However I'd say this article can't be my merit only. I really just tried these shoes made by Uncle Bob for Rust and (mostly) Haskell.

But I don't really want this kind of attitude in our communities, it's counter-productive long term.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

That the tools they were using were somehow better. That the things they were doing were somehow better

Does a Go programmer think the things that they are doing by following KISS everywhere and avoiding unneeded abstraction is "somehow better"?

Absolutely!

Why is it only wrong when Haskellers think their way is better?

What makes it arrogance for Haskellers and not Gophers?

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@codygman Good questions! I would guess that doing things and thinking that those things are somehow better is okay. But it seems ignoring truths from the mainstream just because they came from that "dirty" mainstream is something I could call "arrogance". Go world is rather big, and it doesn't ignore mainstream practices, it adopts them gracefully. The Haskell world is rather small, and it can't afford to be ignorant, just because it will kill Haskell long term.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

But it seems ignoring truths from the mainstream just because they came from that "dirty" mainstream is something I could call "arrogance".

Do you have any examples of where the "dirty" mainstream is ignored? I didn't see any in the article and can't think of any offhand.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@codygman I could give you some evidences about "ignoring the mainstream practices" in the form of abandoned libraries, when some author firstly advertises its cool and smart library, takes a lot of respect, and then just disappears. He isn't interested in supporting the library, nor even in accepting pull requests or answering questions. Just ignores the requests, at all. I know at least 3 such cases with very popular libraries. But I won't name those to avoid pointing by fingers

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

I could give you some evidences about "ignoring the mainstream practices" in the form of abandoned libraries,

What truths were ignored from the "dirty mainstream" in doing that?

He isn't interested in supporting the library, nor even in accepting pull requests or answering questions. Just ignores the requests, at all. I know at least 3 such cases with very popular libraries. But I won't name those to avoid pointing by fingers

Assuming everything else you say is true, how is this arrogance? Where does arrogance come into play or ignoring the "dirty mainstream"?

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@codygman, okay, so maybe you'd interested in this post that happened in response to my article? It's a fair concentration of a true arrogance.

https://boxbase.org/entries/2020/jun/29/hierarchical-free-monads-criticism/

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@jumpnbrownweasel, thanks for your reply. Still, I'm pretty much informed about Haskell, GHC, its history and so on. But this is not an "essay", it's a transcription, so those words came directly from the talk, except the very words "GHC Haskell dialect". It was "Squeak" in the origin.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

@codygman, okay, so maybe you'd interested in this post that happened in response to my article? It's a fair concentration of a true arrogance.

https://boxbase.org/entries/2020/jun/29/hierarchical-free-monads-criticism/

Okay, now I feel like I understand the over-arching issue a little better after you bring that up.

Note the most upvoted reply by @lexi-lambda in the thread:

I appreciate someone taking the time to write all this up. (Though, as I note in another comment, I dont think its written in a very nice way, which meaningfully diminishes its underlying message and deserves to be called out.) - source.

Would you agree that the arrogance you are referring to isn't the norm in the Haskell community? This article seems to imply the Haskell community is wraught with a type that type of arrogance which will effectively kill it.

If anything, I'd say this top comment is more representative of the Haskell community in terms of criticisms like that.

I'm most curious what you have to say about this comment claiming that article's point isn't "mainstream industry sucks, Haskell is awesome" actually:

In context, the author here is not saying mainstream industry sucks, Haskell is awesome. Theyre saying your description of the industry is totally bizarre and does not mesh with my experiences, and if thats the industry you think Haskell should cater to, I dont agree. Maybe Im being unreasonably naïve and charitable, but I did not read bad faith here.

In another quote from that thread, I get the sense that many believe your dismissiveness in your hierarchical free monads post was arrogance itself:

But I get the sense its (boxbase) author is frustrated, and they are venting their frustrations. Perhaps that is not an acceptably-constructive way to do it, but I still empathize, because the post (your hierarchical free monads post) being criticized is at times deeply dismissive to the point of being insulting. (And yet its also often wrong.)

@wrwg

This comment has been minimized.

Copy link

@wrwg wrwg commented Sep 7, 2020

It's kind of funny how history is a bit distorted here by the viewpoint of a younger generation. Haskell and monads, type classes, and higher order types have been actually around since the early nineties. Algebraic data types even longer (early eighties, at least). So has been pattern matching and many other goodies of functional languages (functors have been introduced in standard ML, what, 1985?). Haskell died the first time with the introduction of Java (~1995). Until the end of 1990's many academic institutions were replacing functional languages by Java for education (yes, FP has been very dominant in education in the 90ties). The major reason has been: pure functional programming sucks, and monads are a crutch to replace imperative programming. Also dynamic dispatching, reflection, and runtime type information have been considered important features this time back. (I don't judge here whether they actually are.) "Arrogance" is rarely a reason why a language is adopted or not. (If you want to have an example look at Go -- a language which lacks many features language designers consider as essential, and which the designers of Go dropped because of disdain for them fed by arrogance.) It's the feature set, the ecosystem, the ease of learning, and, last not least, "luck" to do the right thing at the right time. Rust, a language which I really like, has its major problem in the steep learning curve. There is also a certain aspect of rigority in Rust (example: statics) which may distract people, but I have my doubts that this is the major issue.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@codygman

Would you agree that the arrogance you are referring to isn't the norm in the Haskell community?

Of course this is not a norm, but it's how the outer world sees us. And while it's not a norm, there is an implicit consensus that we're okay with that reputation, and thus we won't be doing anything with it. And also, we don't want anybody else to point to this fact, in either form.
This is how I see it. I might be wrong for sure but what is your explanation for that Haskell is not as popular as it deserves? My answer is that we don't take the mainstream world seriously, in general. We want to avoid it at any costs. We find it to be inherently flawed when our world is inherently better. With this attitude, we won't go that far with the Haskell's popularity. We don't think we should firstly learn from it, get a fair amount of adoption with 'mainstream' approaches familiar to the industry, and then try to dictate how software should be written.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

Digging deeper, I think there is a values difference in the Haskell community between:

  • Real World Knowledge
  • First Principles Knowledge

Maybe I'm tipping my hand and biases by naming the second, but I'm open to more fitting names 😉

"Real world knowledge" advocates might see "first principles knowledge" and dismiss it as "pure theory and not applicable to the real world".

"First principle knowledge" advocates might see "real world knowledge" and call it "unprincipled knowledge" that isn't worth making decisions based upon.

One great case of this at play is a question I asked from the perspective of someone considering "real world knowledge" important and got a response from someone who thought that real world knowledge wasn't valuable in this case from this thread:

"It runs in the real world" is a weak argument in favor of anything.

How do you feel about that sentence?

I think this gets at the core of the "arrogance" you are talking about, right? (I'm not sure if I agree it's arrogance).

After reading this though:

"It runs in the real world" is a weak argument in favor of anything.

Isn't it arrogant to assume that anyone dismissing "real world knowledge" by saying this is only doing it out of arrogance?

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

I think this gets at the core of the "arrogance" you are talking about, right?

Probably? I don't really have a strict sense of "arrogance", and, as people in r/rust noted, it could be better to say "ivory tower" instead. But this word was used in the origin, so it's here as well. However, once this word hits a nerve than there is some truth in it. Otherwise one just could ignore it. But I've heard many times from "the outside folks" how arrogant reputation we have. I started thinking that we are suffering from willful blindness and don't want to see this obvious fact. And it makes it hard to push Haskell in its adoption. I believe this should be changed somehow, or at least articulated for ourselves.

How do you feel about that sentence?

I personally find it bad. Nasim Taleb said:

"For real people, if something works in theory, but not in practice, it doesn't work.

For academics, if something works in practice, but not in theory, it doesn't exist."

(https://mobile.twitter.com/nntaleb/status/1013150172996685824)

And this is what I sometimes see in our lovely Haskell. But the real world is the practice, and we have to deal with all the consequeces of this.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

"Real world knowledge" advocates might see "first principles knowledge" and dismiss it as "pure theory and not applicable to the real world".

"First principle knowledge" advocates might see "real world knowledge" and call it "unprincipled knowledge" that isn't worth making decisions based upon.

P.S. Interesting perspective, I need to think about it.

@jumpnbrownweasel

This comment has been minimized.

Copy link

@jumpnbrownweasel jumpnbrownweasel commented Sep 7, 2020

The reason I'm not using Haskell has nothing to do with arrogance, it is mainly because of all the language extensions (I really don't want to deal with all of that, but they're commonly used) and the use of exceptions in IO (for me, this greatly reduces reliability). And of course tools and doc are not so great. So I agree in that these are probably due to lack of focus on mainstream concerns.

From what I've read, this lack of focus on mainstream is simply because there is no central organization/direction for Haskell, due to the research focus. And allowing complete freedom is probably worthwhile because of the benefit to research, even if it means Haskell never becomes mainstream.

There is nothing to prevent a group of people from creating a parallel Haskell that is better documented and simpler (more constrained), but it's not surprising that this hasn't come from the research community. It would take a very large effort, much larger than attempts at this in the past. It's kind of sad, because I think Haskell is simpler and more powerful than mainstream languages in many respects.

But I still get a lot of benefit from Haskell indirectly, due to it's contributions to other languages and from learning it and using it as a hobby. Sum types, pattern matching, and immutable by default are really big improvements. I'm able to use them now in Rust, and I suspect we'll see them in more languages over time.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@wrwg Thanks for your reply, noted! Yes, the post doesn't reflect the real history of the language.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@jumpnbrownweasel

the use of exceptions in IO

Moreover, exceptions can happen in a pure code... and there are async exceptions... and a lot of different approaches to mitigate the problem of exception unsafety. Haslell is not as safe as we used to advertise it.

creating a parallel Haskell

PureScript?

But I think a parallel Haskell is not needed, but we rather need to produce best practices and approaches (borrow them from the mainstream) so that the usage of Haskell wouldn't be so difficult. It's not that Haskell is difficult, it's we who've chosen to use it in the smartest and difficultiest possible ways. Doing things simpler is really a hard deal, and not that temptating, not that interesting as doing things smart and complex. My take is that we (as a community, in general) just don't have a desire to write a simple code in Haskell. We don't really know our tool, and we have wrong assumptions on what is needed for the industry.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 7, 2020

I think this gets at the core of the "arrogance" you are talking about, right?

Probably? I don't really have a strict sense of "arrogance", and, as people in r/rust noted, it could be better to say "ivory tower" instead. But this word was used in the origin, so it's here as well.

However, once this word hits a nerve than there is some truth in it.

Patently disagree on this line of thinking. I could call you mean, and observe "that hit a nerve, there is some truth to it" while it's totally false. The whole time I would just be the one that was mean.

The entire "if your pissing someone off you must be right" line of thinking is wrong, damaging, and horribly unconstructive.

Otherwise one just could ignore it.

False premise. If someone says "you stayed home yesterday" in front of my boss, I couldn't simply ignore it and would need to say "no I didn't". If my boss were to believe the fallace of "that hit a nerve, there is some truth to it" I might be in worse standing at work.

But I've heard many times from "the outside folks" how arrogant reputation we have.

You've heard many times, but quality is better than quantity. Did the criticisms go into detail? Let's be constructive and discuss those then!

I started thinking that we are suffering from willful blindness and don't want to see this obvious fact.

That's one theory. Another theory which could file me further under the problem category of Haskeller's is suggesting it could also be the willfill blindness outside of the community. I do believe it's good to look harder at ourselves though, so I'm open to actual arguments and will consider them.

And it makes it hard to push Haskell in its adoption. I believe this should be changed somehow, or at least articulated for ourselves.

You believe that questioning the value of "real world knowledge" makese adopting Haskell harder?

Yeah, I agree with that. It necessarily has too. If you think Haskell's value add is the type system and the language itself mostly, I can see how you'd be annoyed that people won't just "be the same" in regards to "real world knowledge".

Many think that questioning the real world knowledge vs first principles knowledge weights though is a part of Haskell itself.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 7, 2020

@codygman Sure thing, I see your points. Maybe we'll return to these questions later, but for now it seems we have an overthinking of the "essay"'s topics. I'll need to formulate my thesises for this next talk.

@lexi-lambda

This comment has been minimized.

Copy link

@lexi-lambda lexi-lambda commented Sep 7, 2020

Note the most upvoted reply by @lexi-lambda in the thread

Chiming in here because I was pinged. I really regret spending even a word defending that article. I didn’t read it thoroughly at all before writing my comment, I just skimmed it to see the points it was criticizing. Frankly I was quite taken aback upon giving it a closer reading how childish it was, and it made me feel like an asshole for giving it any praise at all.

That was a mistake on my part, and I apologize. But I do think there are some things we can take away from that experience:

  • I think that particular kind of immaturity and arrogance is genuinely unusual within the “core” Haskell community—the community that regularly works with it and writes about it. If it wasn’t so unusual, I wouldn’t have felt like it was safe for me to just assume it wasn’t written that way, nor would I have felt so shocked upon a closer rereading.

  • Personally, I think the article it was criticizing is pretty arrogant, too, but in a different way. It says things like this:

    And I'm not exaggerating. Haskellers consider their language as something special, unique, blessed and therefore standing out of those strange agreements the outer world managed to build.

    [...]

    Effect systems bring too much accidental complexity in the code; perhaps this was a reason why PureScript developers removed a similar system from the language. It turned out that effect tracking is commercially worthless.

    [...]

    We all need to learn from the mainstream, we need to adopt methodologies, ideas and practices to show the industry that Haskell is not a toy but rather a tool able to solve real tasks and lead businesses to success. We all should be more open-minded and should not stay in our Ivory Tower.

    I consider this quite arrogant (and rather insulting) for several reasons:

    1. It claims outright that effect systems are worthless with relatively little evidence or explanation to back it up. Most of the arguments seem to appeal to the idea that Haskellers have their heads in the clouds and just don’t care about writing real software, but that isn’t a technical critique at all.

    2. It suggests the author believes that his approach is superior to things people have spent enormous amounts of time thinking about and working on because it is simpler. Implicitly, this carries the assertion that all those people are either stupid or don’t care about “real programming,” but that is a pretty rude thing to say.

    3. The article itself makes some technical errors or incorrect assertions that belie a misunderstanding of the problem domain in spite of the aforementioned confidence.

    I have spent much of the past year investing enormous amounts of time into engineering a practical solution for real-world problems that I have run into, and my work builds upon prior art while integrating various other ideas. That prior art is valuable. I found the article frustrating because it seems to claim without evidence that all our work is pointless, and it makes some incorrect claims I’ve spent a lot of time over the past year trying to dispel.

  • Nevertheless, the Haskell community can be arrogant, quite so. I have seen this arrogance in action myself, and it is very ugly. I find that it rarely takes the form “anything that isn’t math/category theory is bad” (though that comes up sometimes, it’s true), but much more often “if you write Python you’re just an idiot.” What profound foolishness. I have written about how unreasonable and harmful I think this attitude is at length elsewhere.

Overall, I think the tone of both your original article and this gist is arrogant, combative, and unempathetic. Yes, Haskell is flawed. Yes, Haskell tends to be idealistic, sometimes to its detriment. Yes, Haskell is a research language. But that research is not nearly as irrelevant to practice as I think you seem to think. I write Haskell professionally full-time, and we work on a problem where a lot of the recent GHC extensions are enormously helpful. You seem to be saying “most people don’t have these problems, so Haskell is wasting its time trying to offer solutions.”

But c’mon, I have these problems, and so do some others. Are you saying the Haskell community should abandon me? You seem to want Haskell to be something fundamentally different from what it is, and you’re claiming that all the people making Haskell into something useful for them should just go away and serve a different cohort, instead. Why? That Haskell is specialized does not make it bad; it means it’s serving a niche unfilled by other languages.

There are lots of research languages that are not intended for industry application—see Idris, Agda, Lean, etc. But Haskell was always, from the beginning, a research project into whether or not it was possible to make a compiler for a lazy, pure, functional programming language that executed programs on stock hardware efficiently enough to be an industrial-strength compiler. Its research premise was taking academic ideas and making them practical. I think that philosophy is alive and well today—see, for example, the recent implementation of linear types, which I will remind you was funded by industry, not research grants—and claiming it isn’t is not a good way to open a productive debate with the Haskell community.

@rmbagel

This comment has been minimized.

Copy link

@rmbagel rmbagel commented Sep 8, 2020

The comments of this article ironically reflect the point of this article.

Arrogance indeed. I'll be staying clear of Haskell.

@schw1804

This comment has been minimized.

Copy link

@schw1804 schw1804 commented Sep 8, 2020

Is the editor of this transcript a native English speaker?

@sterlingbates

This comment has been minimized.

Copy link

@sterlingbates sterlingbates commented Sep 8, 2020

@rmbagel +1. Arrogant, combative, childish? Yeah, not at all descriptive of the comments.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 8, 2020

@lexi-lambda

Thanks for writing this (and that).

Of course, nobody should be sent away from Haskell, irrespective the activities the person does. There is no such intent, and trying to see such intent in my words is overthinking. Academic research or industrial usage, - all the people should feel comfortable, and the outer world should not be offended by our behavior. This doesn't mean we should stop doing research, after all, Haskell is indeed a research-first language. But some people are trying to make it research-only language, and they constantly expose an attitude that they are somehow better. Not only better than people from, let's say, golang, but also better than haskellers like me who've chosen to bring the mainstream knowledge into Haskell (like "we need general purpose frameworks", "we should write a simple code (for production)", or "that approach gives too much accidental complexity"). (Saying "we" I mean myself and those people who would want to join to this.) Better than haskellers like me who doesn't know Category Theory or can't manipulate types on the level you can. Our interests are not represented well, and since the last year we are trying to say that we exist. We're trying to write a simple, boring Haskell because it better suites the requirements of a usual industrial reality. We're not dumb. We just have a slightly different system of values.

Of course we respect the things research people do. We respect the things you do. We respect the things the GHC team does. We respect the things library people do (unless they just disappear, - this is not good). But the outer world, which makes decisions, sees Haskell as a language in which people don't know how to write software with low risks and low complexity. The outer world thinks that we're an academic language only. Solutions we as a community offer are usually suitable for a very small niche where smart cool things are more or less acceptable. The problem is that the alternative (simplicity) is not represented properly, but it should be if we want Haskell to be popular and successful (even alive).

I understand why some of my words could seem to be arrogant, and maybe it is, and I apologize for this. I should probably choose another strategy in my activities.

But I doubt it's arrogant in the way you've written because you do additional steps in your reasoning by thinking more than there is in my words. At least, the middle cite is just a normal technical assessment of applicability some solution (effect system), this is not arrogance. We all should be careful about complexity we bring into projects, and effect systems bring a lot of complexity. I used an effect system in real production, and it was a pain. Complexity is a technical point one should weight. There is nothing about that your work on effect systems is pointless or not needed. I never said that effect systems are useless, or you do a useless work. The argument that your work is useless is a social argument, and the argument that effect systems are hardly applicable because of their complexity - is a technical argument. They might be commercially worthless, they might be less applicable than a simpler solutions, but maybe this is just because effect systems are not developed enough. It might be they are useful, however it's not enough to just provide an effect system and say: use it! Irrespective how much effort you brought into the effect systems research, it's developed in a different direction than a usual company would like to see. Firstly, there should be a whole bunch of solutions on top of it: database support, logging, HTTP, multithreading etc. Just to show it's possible. Just to clarify the subtle thongs. Just to provide a broad example of usage so that the industry could be sure there will be no unexpected, fatal problems in the middle of a project. There should be a set of practices for many real-life tasks. It should be clear how to do things on top of the effect system, and what are the consequences for the code long term. And the very last point will be how good or fast the effect system is.

By the way this is true for all the cool Haskell things: advanced type level, linear types, future dependent types. It's not enough to just have them and use them because it's inherently good. There should be understanding on how to solve regular tasks with it, and what are the risks. This is a kind of maturity I'd want to see.

Any research is useful for the community, and maybe some approach can be adopted widely in the future. So I appreciate your work. There is nothing like "stop doing your research". Please do, we all benefit from your work, and we all respect it. Please, continue improving effect systems, and maybe you can even create a showcase how to use effect systems for regular tasks one might meet in production. It's always a good idea come from the other side, from the usage side, and produce some practices to follow.

But yes, simple approaches are better, in general. This is an axiom which comes directly from the mainstream practice. The world of software engineering tends to simplify from year to year, and there are good reasons for that. If we miss this general requirement, we can forget about the wide adoption of Haskell. Doing simple - is very hard. Making some approach to be assessed in a real environment also means making it simpler because there will be an understanding, maybe documentation on the hidden pitfalls. I personally want to add some effect system as an engine for my Hydra showcase. This would show all the consequences of such decision.

Doing so we can provide a complete picture of Haskell for the outside world. This is beneficial for all of us. Making Haskell more popular is a wise strategy and the only viable way long term.

P.S. No, I don't think my understanding of the industry is bizarre. There are clusters of the industry that look for the smart Haskell approaches, but the vast majority of the industry isn't like that.

@ShalokShalom

This comment has been minimized.

Copy link

@ShalokShalom ShalokShalom commented Sep 8, 2020

One point is, that people don't accept scientific evidence. We call ourselves computer scientists and artists. And still, artistic expression in code is far more accepted than the scientific evidence.

You can always choose the language/brush that you love and prefer. No issue with that. Artistic choice. When you choose to drive west, when you want from San Francisco to New York, is this also your free choice. What is the real issue here, is cognitive dissonance.

People love one language, while another one would make more sense. They hate this. They hate, that these two worlds collide. They would love, when their broken design idea - like traditional inheritance, that is a reflection of the hierarchy and our position to it - would just work miraculously.

So they tell themselves lies, and this can also be described as arrogance. Arrogance in opposition to reality. We have to accept, that we sometimes do things, because we prefer to be stubborn and ignorant. This is our choice. And this is, why some people decide to stick to the truth, and some lie to themselves.

The Haskell people - and Smalltalk before them - also did lie to themselves on daily basis since they told themselves, that adoption from the outside is something they can do great without it.

Haskell is a wonderful language. And just a piece of zeros and ones, an idea, which is absolutely worthless without adopters.

I personally think, that new programmers are the true source of change: Those are the group of people, who can lift a language from the abyss to the top of the line. All popular languages today - you can say what you like - got popular since they provided an immense benefit for those, who came new to the field. C++ for polymorphism and Java for memory management and cross-platform shipment, Python for kids and dummies like me, Javascript for webdesigners. C for people who were tired and overwhelmed by Assembly.

I think those languages all have in common, that they united people, who were otherwise not welcome to write the software they aimed for. PHP and JS were successful since they offered the opportunity to write webpages. Not because it was not possible otherwise - at least for the backend. But because they were welcoming to these people, while others were not. It was - or was not - part of the culture. And I think Rust is the next big language, since it allows people to do things, which they could not easily do in others. And they welcomed newbies. I think ultimately, Haskell is not a newbie-friendly language. Functional languages in general.

I was interested in declarative code before I knew that functional programming enables me to do that. I wanted functional programming from the get go, since I loved how it looked. I found out about all the other benefits way later.
And guess what? Zero of those languages welcomed me a complete new programmer. This is why functional languages fail. And this is, why Rust is successful. They welcome newbies.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 8, 2020

@graninas Do you realize the pattern you have of paying lip service to "I respect your work" and then you turn around and basically say "I'm right because my approach is (allegedly) simpler", specfically:

But yes, simple approaches are better, in general. This is an axiom which comes directly from the mainstream practice.

When you say:

Of course we respect the things research people do. We respect the things you do.

There is nothing like "stop doing your research". Please do, we all benefit from your work, and we all respect it.

But yes, simple approaches are better, in general.

Then reflect on what Lexi said:

It suggests the author believes that his approach is superior to things people have spent enormous amounts of time thinking about and working on because it is simpler. Implicitly, this carries the assertion that all those people are either stupid or don’t care about “real programming,” but that is a pretty rude thing to say.

In the same way you accuse Haskller's of "ignoring truths from the "dirty" mainstream", I'd say you are "ignoring truths from "air-headed, impractical" researchers"

You also didn't really give much of a response to this:

I have spent much of the past year investing enormous amounts of time into engineering a practical solution for real-world problems that I have run into, and my work builds upon prior art while integrating various other ideas. That prior art is valuable. I found the article frustrating because it seems to claim without evidence that all our work is pointless

What do you have to say about this quote specifically?

Haskell's research premise was taking academic ideas and making them practical.

You want to change this right? You want Haskell to instead be guided by industry rather than what's gotten it the success it already has, right?

If so, the arguments you've presented for doing so are uncompelling:

simple approaches are better, in general. This is an axiom which comes directly from the mainstream practice.

You can just say "this is true because it's an axiom from industry" and expect an entire programming language to change what's made it successful to this point.

I personally want to add some effect system as an engine for my Hydra showcase. This would show all the consequences of such decision.

Please do this, this would be more compelling evidence especially if you colloborate with others to make sure effect systems are presented on their strongest terms. I bet there could be constructive technical-focused discussion on such an exhibition as well.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 8, 2020

@ShalokShalom

And guess what? Zero of those languages welcomed me a complete new programmer. This is why functional languages fail. And this is, why Rust is successful. They welcome newbies.

I'm sorry for your experience. Do you mean in terms of documentation, or something like not being welcomed in a language chatroom or mailing list? I'm assuming you mean in terms of documentation, but feel free to correct me.

I also think Rust is successful because they make things easier for newbies to start and I continually push for easy defaults for better UX with customizability available for power-users like it's evident Rust does in the cargo documentation.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 8, 2020

@codygman, I'm not sure what are you trying to achieve, but sorry, I won't be answering here anymore.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 8, 2020

@codygman, I'm not sure what are you trying to achieve, but sorry, I won't be answering here anymore.

I bet there could be constructive technical-focused discussion - @codygman

@throwmeaway876

This comment has been minimized.

Copy link

@throwmeaway876 throwmeaway876 commented Sep 9, 2020

@graninas
He's just a zealot that got triggered by the word "arrogance".
Must have hit a little too close to home, huh?

"Never Wrestle with a Pig. You Both Get Dirty and the Pig Likes It"

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 9, 2020

@graninas
He's just a zealot that got triggered by the word "arrogance".
Must have hit a little too close to home, huh?

"Never Wrestle with a Pig. You Both Get Dirty and the Pig Likes It"

"Triggered" is disrespectful to PTSD victims, please don't use it.

What bothered me were all of the false claims and no evidence.

Have a nice night! 🙂

@cheery

This comment has been minimized.

Copy link

@cheery cheery commented Sep 9, 2020

Hello @graninas, I am the author of the boxbase.org article and ended up finding this thing out while idly searching stuff to read. Did I mention on the post that I wished people would not link to it? I'm not too offended myself, but I can see people getting frustrated from reading it.

I did come here to say that I barely participate in the Haskell community. At the time of writing this post I didn't even consider that I was a member of any community. You're not entirely wrong though, the article was written when I did use communities more than participate in them. In that way it was written by somebody who was a member of a very small community of one person.

I am sorry that I wrote the article to begin with.

@graninas

This comment has been minimized.

Copy link
Owner Author

@graninas graninas commented Sep 9, 2020

@cheery, hello, and thanks for writing this.

You don't have to say sorry, because I don't feel offended by your article. That's because I'm not a person who seeks an opportunity to be offended. I don't have anything personal against you or your article. Feel free to delete it if you want, or leave it as is, that's not a problem for me.

I won't say anything about my article, - this is the past, and it doesn't deserve that much attention. I'm taking the full responsibility for this article, and I knew what kind of responsibility it will require.

@mauricioszabo

This comment has been minimized.

Copy link

@mauricioszabo mauricioszabo commented Sep 9, 2020

What makes it arrogance for Haskellers and not Gophers?

@codygman I must say only from my experience on Haskell communities (I have no contact with go at all). I work in Clojure, and I know that Clojurians also follow blindly the author of the language, creating almost the same problem that I'm seeing in Haskell.

The problem I see is: people are way too academic on some issues (like type/category theory) but refuse to accept when they are contradicted even when there are proofs that they are wrong. For example, they keep saying terms like "Unityped", "Weak-typed", "Untyped" or "Unsafe" to define dynamic-typed languages (terms that are unused, too broad, or that most people disagree what it means), or say lots of times that "their typing information is so rich that allows then to not have lots of bugs" (there's also no evidence for it, based on studies), or "to not have runtime exceptions" (also wrong), or even that "it'll always catch bugs without losing flexibility" (blatantly wrong).

Now, I know some people will say "this is not how the core community is", but this argument seems like a true Scotsman fallacy. This arrogance leaks also on tooling - there's still no good package manager for Haskell (stack is a nightmare, to the point that IHP uses a whole linux package manager just to install a simple framework), for example...

@cheery

This comment has been minimized.

Copy link

@cheery cheery commented Sep 9, 2020

@mauricioszabo, there likely are people willing to discuss that with you. Though it will take several weeks or more to explain, depending on where you start at. I agree that it is abusive to throw terms around and not explain them, and that educated people should prefer to not do this. People should have possibility to have their say and be listened, under some conditions.

I'd suggest you to search about Nix-style local builds. I don't think it addresses the idea that cabal would not be a good package manager, but maybe you'd like to look and try it out a bit.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

@mauricioszabo hi there!

there's still no good package manager for Haskell (stack is a nightmare,

Stack is wonderful! Why do you say it's a nightmare? It just works in my experience.

to the point that IHP uses a whole linux package manager just to install a simple framework), for example...

They use nix for speed through binary caching I think. Even if that's not the reason, how does IHP using nix make stack nightmare level?

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

their typing information is so rich that allows then to not have lots of bugs" (there's also no evidence for it, based on studies)

You can rule out bugs with static types and in effect create something that allows not having a lot of bugs. I don't think you need a study to prove/disprove most "static safety makes bug X impossible" claims.

For instance, with smart constructors I could make a password type that can't be constructed with an empty string.

Then I could claim that I prevent bugs where users enter empty strings with static type-safety. More here:

https://kowainik.github.io/posts/haskell-mini-patterns#smart-constructor

Does that make sense?

The problem I see is: people are way too academic on some issues (like type/category theory) but refuse to accept when they are contradicted even when there are proofs that they are wrong.

Sadly that's people in general, it's not unique to Haskellers.

In fact, when adequate proof is given, Haskellers seem slightly better than programmers in other languages in admitting they are wrong in my experience.

Can you link some specific examples?

@ShalokShalom

This comment has been minimized.

Copy link

@ShalokShalom ShalokShalom commented Sep 10, 2020

I'm sorry for your experience. Do you mean in terms of documentation, or something like not being welcomed in a language chatroom or mailing list? I'm assuming you mean in terms of documentation, but feel free to correct me.

Documentation, interaction in chat, and error messages.
The point is if the focus on newbie friendliness is not there, it is not reflected in any of those aspects, naturally.
I think new users are a huge source of potential to modern languages since they are bypassing the long and tedious process of unlearning bad and old habits.

And they are also more open to fundamentally different concepts as considered not normal, they dont have the scare to not get a job due to low job listings and all that stuff.
So more open to change, which is the new normal for them.

@mauricioszabo

This comment has been minimized.

Copy link

@mauricioszabo mauricioszabo commented Sep 10, 2020

Stack is wonderful! Why do you say it's a nightmare? It just works in my experience.

To learn a "real world Haskell", I began a simple project. The idea would be to expose a REST API, parse a JSON payload, send it to multiple external services and persist their results in PostgreSQL. I tried stack - it broke my dependencies five times, on the same computer, and simply couldn't resolve the packages on another computer (mind you, I was already developing on that other computer: I simply updated a branch there). Nothing helped - deleting everything and starting again, deleting the project and re-cloning it, etc...

I don't think you need a study to prove/disprove most "static safety makes bug X impossible" claims.

Actually, you need. Otherwise, you're just guessing. Yes, static typing (not "static safety" - I'm unaware if it's an used term, or well-defined) will catch typing errors, but there are studies that tried to verify if static typing reduces bugs, or increases code quality, and the results are inconclusive: https://danluu.com/empirical-pl/ and https://arxiv.org/pdf/1901.10220.pdf. Please notice that this last paper contradicts one that, originally, concluded that TypeScript, Haskell, Clojure, Ruby, and Scala are less error-prone: two of these languages are dynamic-typed

Also: this last paper I've linked, I sent to multiple Haskell user groups. Most of the users on these groups did say "my experience shows the opposite, so the study is wrong" 😞

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

Actually, you need. Otherwise, you're just guessing.

It's not guessing to say a static type Password that can't be constructed with an empty string value prevents bugs caused by empty strings in any code that handles that Password type.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

I'm not sure why the Dan Luu article considers the results from "Unit testing isn't enough. You need static typing too." not large enough to be practically significant.

Please notice that this last paper contradicts one that, originally, concluded that TypeScript, Haskell, Clojure, Ruby, and Scala are less error-prone

Yes, Ive long since stopped linking to that paper. We really need reproducible research.

Most of the users on these groups did say "my experience shows the opposite, so the study is wrong" 😞

I won't say that, but I'll say since there is no empirical basis to make decisions from I'm forced to go by my experience until empirical evidence arises that contradicts it.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

To learn a "real world Haskell", I began a simple project. The idea would be to expose a REST API, parse a JSON payload, send it to multiple external services and persist their results in PostgreSQL. I tried stack - it broke my dependencies five times, on the same computer, and simply couldn't resolve the packages on another computer

Sorry for your bad experience. The second sounds like a temporary network issue. The first issue.. I've never heard of stack breaking dependencies. How did you know they were broke?

@jumpnbrownweasel

This comment has been minimized.

Copy link

@jumpnbrownweasel jumpnbrownweasel commented Sep 10, 2020

I'm an old programmer and I work with a bunch of other old programmers. :-) There is a consensus in our group that writing reliable software, especially for distributed systems, is extremely difficult. So whatever tools we can find to help us do that, we will use. In other words, we need all the help we can get. Static type checking finds errors earlier, so we use it. Of course static type checking doesn't find all the errors, and therefore we need code reviews, unit testing, integration testing, etc, etc. We'll throw everything at this problem that we can, and even then we won't find all the errors. Of course we have limited time, so tools that are more efficient to use are better.

From this viewpoint, which I think is fairly common, by catching more and more errors with static type checking, Haskell is taking us in the right direction. The more errors we can catch, and the less costly it is to find them, the better. Please don't underestimate the benefits of this.

I suspect it is quite difficult to do a study that accurately measures the overall benefits of using different languages, because there are so many variables and so many ways that things can go wrong in software.

@mauricioszabo

This comment has been minimized.

Copy link

@mauricioszabo mauricioszabo commented Sep 10, 2020

How did you know they were broke

It didn't compile at all, and gave me lots of strange errors 😆. But to be honest I don't really remember the errors, just that some commands to compile, run the REPL, etc on one machine didn't work on the other.

Also, some of the answers here already illustrated what I talked about Haskell groups, so... ¯\_(ツ)_/¯

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 10, 2020

Also, some of the answers here already illustrated what I talked about Haskell groups, so... ¯_(ツ)_/¯

I think you might mean some of my answers? Can you quote them and tell me how they illustrate what you said about Haskell groups?

If I'm being arrogant or could improve in some way you see I'd be interested in knowing 🤠

@ShalokShalom

This comment has been minimized.

Copy link

@ShalokShalom ShalokShalom commented Sep 10, 2020

Fuzz tests, no unit tests. Its 2020

@hrishikeshk

This comment has been minimized.

Copy link

@hrishikeshk hrishikeshk commented Sep 11, 2020

I think there are plenty of programmers with brain power far in excess of what someone needs to grok Haskell or any such un-typical programming languages and paradigms. What can spur them towards using Haskell are these three promises -

  1. Can I develop large programs in Haskell in super quick time ? Compared to lets say Python ?
  2. Can the program I develop have great runtime speed ? Compared to lets say C++ ?
  3. Can Haskell let me develop multi-threaded programs smoothly and painlessly ? the kind of multh-threading that gets really hairy in say C++ ?

I get a feeling that Haskellers tend to focus disproportionately on higher level patterns, structures and stuff that programmers tend to invent themselves when they are up against a problem that needs it.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 11, 2020

I get a feeling that Haskellers tend to focus disproportionately on higher level patterns, structures and stuff that programmers tend to invent themselves when they are up against a problem that needs it.

Right, they do spend more time on it. The argument though is less time overall is spent on those high level patterns than the "invent it myself" default that dominates industry.

You can reject that time spent on coming up with reusable abstractions is valuable and go the "invent yourself" route in Haskell too.

I wouldn't call Haskellers disagreeing with the default based on both their research and real world experience arrogant though.

@codygman

This comment has been minimized.

Copy link

@codygman codygman commented Sep 11, 2020

I think there are plenty of programmers with brain power far in excess of what someone needs to grok Haskell or any such un-typical programming languages and paradigms.

Agree wholeheartedly!

What can spur them towards using Haskell are these three promises -

Nice! Mind if I use those for a blog post in the future?

@lexi-lambda

This comment has been minimized.

Copy link

@lexi-lambda lexi-lambda commented Sep 11, 2020

@mauricioszabo writes:

For example, they keep saying terms like "Unityped", "Weak-typed", "Untyped" or "Unsafe" to define dynamic-typed languages (terms that are unused, too broad, or that most people disagree what it means), or say lots of times that "their typing information is so rich that allows then to not have lots of bugs" (there's also no evidence for it, based on studies), or "to not have runtime exceptions" (also wrong), or even that "it'll always catch bugs without losing flexibility" (blatantly wrong).

Regrettably, I completely agree with this. I think these kinds of arguments are spurious, bad faith, and generally unhelpful ways of thinking about programming. I have personally complained about these arguments at various points in the past. The Haskell community will never move past its reputation as mean and elitist without learning to call out these talking points for what they are.


@graninas writes:

We all should be careful about complexity we bring into projects, and effect systems bring a lot of complexity. I used an effect system in real production, and it was a pain. Complexity is a technical point one should weight.

Certainly. I, for one, will agree wholeheartedly with the belief that simplicity is always to be strived for! Even from an academic, mathematical perspective, complex solutions are ugly, and simple solutions are beautiful. When faced with a choice between a complex solution and a simple one that does the same thing, obviously we would pick the simple one every time.

But of course, that assumes that all other things are, indeed, equal. In practice, that is often not the case—just look at systems like the JVM or Kubernetes, which are enormously complex yet used massively within the industry. These systems are used because they tackle truly complex problem domains. They are also both research projects in their own rights, albeit industrial rather than academic.

Now, as it happens, I have never written an application that actually needs the complexity of Kubernetes. I simply have not had the set of problems that Kubernetes was designed to solve. So I have never used it, and that is okay—I don’t go around claiming that “Kubernetes is commercially worthless.”

You have stated that you do not construe your own writing as arrogant:

But I doubt it's arrogant in the way you've written because you do additional steps in your reasoning by thinking more than there is in my words. At least, the middle cite is just a normal technical assessment of applicability some solution (effect system), this is not arrogance.

Obviously, it is possible that others agree with you, and not with me. But I really do see your wording as arrogant and dismissive of the real problems that, for some people, such projects solve. Ultimately, you may choose whether or not you care about how I or anyone else perceives your words—all we have is our opinions. But generally one communicates such things with an intent to somehow change minds, and the way your words are received matters enormously for accomplishing that goal.

Changing minds is hard. But if you seriously want to do it, I recommend trying—hard as it sometimes is—to put real work into empathizing with the people you are trying to convince and framing your conversation in a way that they will understand. This is hard to do when strong opinions are at play, but it can be done. Listening to the way others respond to you is crucial, because even if you don’t agree with their response, it means you can learn to reach them better.

@hrishikeshk

This comment has been minimized.

Copy link

@hrishikeshk hrishikeshk commented Sep 12, 2020

I think there are plenty of programmers with brain power far in excess of what someone needs to grok Haskell or any such un-typical programming languages and paradigms.

Agree wholeheartedly!

What can spur them towards using Haskell are these three promises -

Nice! Mind if I use those for a blog post in the future?

Sure. Expand on this topic.

@maralorn

This comment has been minimized.

Copy link

@maralorn maralorn commented Sep 12, 2020

I want to raise a meta point here. It's not possible to tell "how the Haskell community really is" from just reading this article or it's comments.
I think if you have a bad image of the community this dialog will confirm the arrogance, because "they don't accept that critcism" and if you think more positive of it the reactions in this post seem reasonable, too.

I think bad behavior should be called out, but that can get out of control and perpetuating the narrative of an arrogant community can be very damaging for the language.

My personal experience is, that most people in the community often seem embarrassed by unintelligible error messages and get out of there way to explain them. I feel a lot of them aggressively try to do all they can to loose that negative image and make the language more usable.
But of course I can't tell how many off putting experiences people have.

@haroldcarr

This comment has been minimized.

Copy link

@haroldcarr haroldcarr commented Sep 12, 2020

Haskell made me love programming again.
Highly recommended.

@lpar

This comment has been minimized.

Copy link

@lpar lpar commented Sep 12, 2020

What makes it arrogance for Haskellers and not Gophers?

I think it’s because with Go, features are left out because Go developers consider them too difficult to use, apt to lead to mistakes, or hard to get right in implementation. That is, the Go developers are in a sense leaving things out because they consider themselves not smart enough to put those things in safely — not because the things are bad, and not because Go is in any way intellectually superior to other languages. Gophers will say yes, our type system is poor, we hope to make it a bit better in Go 2, but what we have gets the job done.

Whereas with Haskell, things are too often presented as intellectually superior, with a connotation that if you don’t recognize their inherent superiority, it’s because you don’t understand them. Why, if you were smart, you wouldn’t even consider using a language that lacked algebraic data types!

This impression of professed intellectual superiority is also amplified by the use of terminology and syntax which obscures.

@abeck99

This comment has been minimized.

Copy link

@abeck99 abeck99 commented Sep 13, 2020

As someone outside both of these communities with a long term interest in Haskell and more recent interest in Rust, who recently had an opportunity to start a major project that either Haskell or Rust would’ve worked but I stuck with C++ reluctantly because reasons, I’d say I feel the Smalltalk arrogance more from Rusters than Haskellers. The most arrogant of Haskellers just seem unconcerned with mainstream (like some monks on the mountaintop) but the most arrogant of Rusters seem actively antagonistic.

I’m just saying the Smalltalk/Ruby parallel is not 1:1. Not to mention that Rust has a chance to capture more of the programming world than ruby ever had a chance to. But I agree 100% this is the biggest hurdle in between Rust reaching that tipping point where it lived a long time. Literally everything else about Rust is trending in the right direction or already great, and it feels inevitable Rust is here to stay. But that feeling leads to the arrogance that prevents new adoption and prevents reaching the tipping point. I think just looking at the death of Smalltalk alone is instructive enough without bringing the Ruby parallel in too (which btw Ruby only achieved a temporary mainstream via a single library so you may not want to compare Ruby to Rust. Also as many have said Haskell certainly isn’t dead

@youngtrips

This comment has been minimized.

Copy link

@youngtrips youngtrips commented Sep 13, 2020

Language will be more powerful only if it focuses more on engineering and not just academics.

@cheery

This comment has been minimized.

Copy link

@cheery cheery commented Sep 13, 2020

I designed a programming language that focused on engineering first, disregarding latest theory. Then I wanted to extend it with a computer algebra system and the whole fucking thing came down tumbling like a stack of playing cards. Never again.

@luserx0

This comment has been minimized.

Copy link

@luserx0 luserx0 commented Sep 14, 2020

Scheme.

@cartermp

This comment has been minimized.

Copy link

@cartermp cartermp commented Sep 15, 2020

I would agree with some commenters here about Go being highly arrogant. It stems largely from Rob Pike being a complete asshole, and a good number of the community parroting his nonsense. That seemed to work, so I wouldn't go so far as to say that arrogance must be removed from the process.

But I would prefer it if all language communities were more positive like the Rust folks:

  1. Externally, just show what's great about the language and don't try to make claims about being better or whatever.
  2. Within the language community, focus on what could improve, especially from an accessibility standpoint.
@dunrix

This comment has been minimized.

Copy link

@dunrix dunrix commented Sep 23, 2020

I've not met too much arrogance in haskell community, resp. nothing standing out of usualness. The problem may lay in dichotomy between academic and enterprise demands and, as already mentioned, lack of leadership with a clear vision and compatability/consistency/constraints policies. The wild-nature of development of referential implementation with generating permutations of Haskell-like languages with fast-growing and often overlaying/duplicating/conflicting/deprecating extensions undermines its adoption for sure. The trials-and-errors at fixing some sort-sighted decisions brought to the language (records, class deriving, existential ranks etc) were also too much.

With increasing favour and enthusiasm of Rust even at haskellers much more experienced and skilful then I've ever been, one may question if ideas which keep him in haskell world are really worth it ...

@srid

This comment has been minimized.

@timmyjose

This comment has been minimized.

Copy link

@timmyjose timmyjose commented Sep 28, 2020

Good article. I spent a career in Java and ended with Go. I have been very happy using Go in my projects and it works well for me. I don't miss Java at all.

Not even generics? Heh.

@lisanhu

This comment has been minimized.

Copy link

@lisanhu lisanhu commented Oct 1, 2020

I didn't understand what you want to say. You are saying Haskell died because of some reasons and Rust community doesn't have the problem, and you are trying to save Rust community for some problem that doesn't exist yet. Your "save" doesn't seem like to be the solution for the Haskell problem, but for something else.

You could just say what is your conclusion about Haskell and remind Rust community not doing the same.

It seems that you are suggesting the Rust community to take care of the "mainstream" ideas, and be polite, is it your points?

I think there are many things that are disputed like is Haskell dead? How do you define its death? Not being discussed by certain number of people?

I believe people are told that all languages work and it's just some languages are better suited for some tasks. Like it's really hard to use pure Java to do HPC and it's not easy to use C to write a quick prototype. Rust can do things fast and is usually free of memory bugs, but it's still having severe problems like hard to implement certain data structures like linked list, lack of accelerator support so very hard to program on GPU. I don't think the people you are referring to can really represent the community since the people talking about "superior" languages seems to be new to programming.

@Leokuma

This comment has been minimized.

Copy link

@Leokuma Leokuma commented Oct 4, 2020

Nice article.

I think Rust has taken a much more open approach than Haskell since the beginning. Community is at the center of the development of the language. In fact, Rust's design is the way it is today because of community feedback. Also, the "rustaceans" I've met were really nice.

So I don't think Rust will end up the way you say Haskell did.

@robinhoodhimself

This comment has been minimized.

Copy link

@robinhoodhimself robinhoodhimself commented Oct 22, 2020

I think there are plenty of programmers with brain power far in excess of what someone needs to grok Haskell or any such un-typical programming languages and paradigms. What can spur them towards using Haskell are these three promises -

1. Can I develop large programs in Haskell in super quick time ? Compared to lets say Python ?

2. Can the program I develop have great runtime speed ? Compared to lets say C++ ?

3. Can Haskell let me develop multi-threaded programs smoothly and painlessly ? the kind of multh-threading that gets really hairy in say C++ ?

I get a feeling that Haskellers tend to focus disproportionately on higher level patterns, structures and stuff that programmers tend to invent themselves when they are up against a problem that needs it.

Totally agree with you.

A Development language is a tool. It's not art. Caterpillar is not working in the art department.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.