Comment by instig007
2 days ago
> 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.
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...
2 replies →
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.
5 replies →
> 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.
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.
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).
> 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.
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.