Hacker News Reader

Comment by instig007 | Hacker News Reader

> Apparently Haskell’s performance isn’t that bad, but I don’t plan on using Haskell for anything that is remotely performance-sensitive. Trying to optimize Haskell code does sound like an interesting problem, but it might be a lost cause.

When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause.

View on HN

In case anyone who doesn't know Haskell: both of these are beginner level mistakes. Using `foldl` causes space leaks and turns your O(1) space algorithm to O(N) space for no good reason. And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so. And that doesn't even include the obviously wrong choice of data structure, built-in Haskell lists are singly-linked lists not arrays. There are Array types and Vector types (both come with GHC so no extra dependency needed) that are more appropriate for implementing APL in the first place.

> And using `foldr` over lists is good when you are dealing with unevaluated lists and want list fusion, but not when they already exist in memory and will continue to do so.

What's the preffered approach?

I have the definitive answer to this question in my article “foldl traverses with State, foldr traverses with anything”

https://h2.jaguarpaw.co.uk/posts/foldl-traverses-state-foldr...

In short: use foldl’ when you’re iterating through a list with state. foldr can be used for anything else, but I recommend it for experts only. For non-experts I expect it’s easier to use for_. For more details about that see my article “Scrap your iteration combinators”.

https://h2.jaguarpaw.co.uk/posts/scrap-your-iteration-combin...

Is it really easier to use for_? It forces you to think about effects rather than pure data. So you end up packaging data into effects through State or similar monads. So is it really easier if you force people to use Monad (well technically Applicative)?

Yes, absolutely, I would say for almost every programmer, certainly for me. "Scrap your iteration combinators" goes into more detail. foldl' is a bit too simple to replace with for_, but for almost every other use case, yes, I do use for_. In fact, I find it remarkably liberating compared to the "iteration combinator" conventional wisdom that has been passed down from Haskeller to Haskeller over the years.

I don't feel that monads are particularly complicated. I have several non-Haskellers programming in Haskell at work, using monads. They just think they're writing a sequence of statements. I feel that mixing monads is complicated, which is why I recommend an IO-wrapper effect system (Bluefin or effectful), so that you don't need to mix.

https://h2.jaguarpaw.co.uk/posts/scrap-your-iteration-combin...

Usually you want `foldl'` (with ' at the end), the strict version of `foldl`. It prevents the creation of intermediate thunks, so effectively a tail recursive iteration over the list in constant space.

`foldr` I almost never use, but it would be for: the return value is a lazy list and I will only need to evaluate a prefix.

The naming conventions are nicely sadistic.

This is what happens when you let Mathematicians name things on chalkboards. They don't want to run out of chalk and they get tired of spelling whole words very easily so they use short names and silly symbols. The name foldl' is "just" "fold left prime". Remember ' means "prime" from calculus class and thinking that was silly even then? Accidentally infected Haskell at a young age.

> This is what happens when you let Mathematicians name things on chalkboards.

Doubly so with APL!

Yeah it's definitely unusual to allow ' to be part of the name of a variable, especially considering that it is, like C, the quote for character types.

In Haskell's case that is indirectly Lisp's fault. Lisp heard of Algol (C's design-by-committee "grandparent" on the family tree) identifier restrictions and thought they were silly. (I think Lisp is also often classified as Haskell's great-grandparent on the family tree? Lisp -> Scheme -> ML -> Haskell, I think?) As with most of that FP family the boundary between "operator" and "identifier" is real thin to nonexistent.

Aside: I've got half a feeling you could implement an APL-like directly in Haskell as a DSL using Unicode-named functions. I've seen Unicode Haskell files that look like APL (and GHC supports a surprising amount of that almost out of the box, as I recall).

> When the dude uses `foldl` over lists and `foldr` with `(*)` (numeric product) it is not the language that's the lost cause.

This is a great example of Haskell's community being toxic. The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery.

I usually don't point these things out and just move on with my life, but I went to a Haskell conference last year and was surprised that many Haskell proponents are not aware of the effects of this attitude towards newcomers.

> The author clearly mentioned they're new to the language, so calling them a "lost cause" for making a beginner mistake is elitist snobbery.

"Lost cause" was the author's description of the language.

The author didn't take the role of a student and ask how to do something. He took on the role of a teacher to tell others it couldn't be done.

Can I ask which conference? Did people behave towards you in that way at that conference, or are you referring to behaviour online? I will try to use whatever authority I have in the Haskell community to improve the situation.

(Still, hopefully in this case it's clear from instig007's reply that it's not a member of the Haskell community behaving in that way.)

This is almost exclusively just online behaviour. Everyone I met in person is very nice :).

The conference I mentioned was ZuriHac. After the key-note Q&A there was a small hallway discussion around how to grow the adoption / reach of Haskell. The conversation revolved around mostly technical points (like how Haskell is superior to x, because of y). What I found interesting was that there was little to no talk about the steep learning curve, developer ergonomics or business use-cases.

The thing is, if someone has not yet learned about functional programming, strong type systems or category theory, why / how would they see the advantages or the power of pure functions, lazy evaluation, Monads, etc. At the same time, their opinions or struggles are often dismissed due to their lack of knowledge. The parent comment is a prime example of this.

Edit: This is a great 10-minute talk that touches on the general topic: https://www.hytradboi.com/2025/419859c5-6a8f-4a49-b324-0f225... She covers a lot of this better than I can.

> calling them a "lost cause" for making a beginner mistake is elitist snobbery.

I wonder how do you call the practice of complete beginners spreading FUD and suggesting to their readers that something in the language is "a lost cause", all whilst having neither enough knoweldge nor sufficient practice to make assumptions of this kind.

> This is a great example of Haskell's community being toxic

To be clear: I don't represent haskell community, I'm not part of it, and I couldn't care less about it. It just so happened that I saw the author inflating their credentials at the expense of the language via spreading FUD, that the beginners you seem to care about are susceptible to, and I didn't like it.

If you get triggered by the expressed dissatisfaction with the author's unsubstantiated presumptuousness, reflected back at them in a style and manner they allowed themselves to talk about the thing they don't know about, then it's purely on you and your infantilism.

I don't question your experience but I think this is not a great example of that. That was a random HN commenter, not Haskell's community (which is quite large and diverse).

fair enough :)

Newcomers need the self-awareness to understand that they are newcomers and that their opinions are more often than not wrong. This author doesn't have that humility.

It is simply aggravating to see newcomers without humility speak with an authoritative tone on subjects they barely know.

Reply on news.ycombinator.com