[Retra]

It sounds like you're saying "I can optimize my algorithms better than any machine could, so why would I learn how to write code that a machine could reason about more effectively?"

Or more accurately, "I don't write code that needs what Haskell offers, so I'm not going to learn it." Which is fine, so long as you keep writing the same kind of code.

Anyway, the reason we need these kinds of things to be more popular is so they are better understood. And if they are better understood, they will allow us to produce better ways of solving problems. Haskell is a very influential language in the world today, and it's not because it is strictly superior to other languages, but because it encourages ways of thinking about problems that are elegant and insightful in addition to being pure.

Haskell's performance is 'pretty good.' It's not great. But it's not awful, which is what it would be if it weren't as good a language as it is. And the reason Haskell is not awful is because of those features that you're saying aren't important to you. Those features took a slug and turned it into a rabbit. It may not be a race horse, but if you ported those improvements into something like C, you'll have a high-performance rocket. Code that could possibly automatically refactor itself into more efficient, more general components.

You could potentially get something faster and more expressive than any language you know. And "who knows what's next" may not be you, because you don't know what's now.

But really, nobody is selling you functional programming because it'll make your code faster. They are selling it to you because it inspires them.

[codygman]

>> It may not be a race horse, but if you ported those improvements into something like C, you'll have a high-performance rocket. Code that could possibly automatically refactor itself into more efficient, more general components.

> From what I can tell, this is actually not the case. Unless what you're talking about is Go. In which case, carry on. ;)

So, don't have all the context... but it sounds like you are implying Haskell libraries can't be a "high-performance rocket" when paired with C whereas Go can? That sound right? Hope so, because it's the assumption my comment below responds to.

What about libraries which take this approach such as bytestring]0], aeson[1], attoparsec[2], and binary[3]?

0: https://hackage.haskell.org/package/bytestring

1: https://hackage.haskell.org/package/aeson

2: https://hackage.haskell.org/package/attoparsec

3: https://hackage.haskell.org/package/binary

[SomeCallMeTim]

>It sounds like you're saying "I can optimize my algorithms better than any machine could, so why would I learn how to write code that a machine could reason about more effectively?"

Actually, that's not at all what I'm saying.

I'm using tools that are known to create code that's faster than the equivalent Haskell.

>Or more accurately, "I don't write code that needs what Haskell offers, so I'm not going to learn it." Which is fine, so long as you keep writing the same kind of code.

I use languages that offer a lot of the tools that Haskell offers, but without as many restrictions. If the restrictions bought me speed (which I thought they did, previously), then they would be valuable.

>But really, nobody is selling you functional programming because it'll make your code faster. They are selling it to you because it inspires them.

I get that. I can see it in the converts who try to evangelize me. But I think that it's like the people who drank the OOP Koolaid: Yes, there are useful things to learn in other paradigms, but going extreme in any paradigm isn't the best way to code.

> It may not be a race horse, but if you ported those improvements into something like C, you'll have a high-performance rocket. Code that could possibly automatically refactor itself into more efficient, more general components.

From what I can tell, this is actually not the case. Unless what you're talking about is Go. In which case, carry on. ;)