Are you familiar with Haskell? Or just a programmer in general?

The name doesn't mean nothing. Either you're a Haskeller not familiar with monad transformer idioms, or you're not a Haskeller just shouting your uninformed opinion.

Hoist means something very specific in the monad transformer world, and it really helps explain what this does. And the "StateToStateT" also is pretty literal (and in the types.)

I'd actually argue this name is boring & completely derived from the types.

I agree with you here that this does make sense from the point of view of even an intermediate Haskeller.

However, I also do think that the jargon in Haskell is extremely daunting. I think it's the only language I've used where easily most of the function names you see relate not to your business logic, but abstract types. There's some obvious things like 'map' and 'fold', but the deeper your get into complex types the more it looks like total gibberish (and you end up with lift, bind, hoist, not to mention obscure operators if you're in that sort of codebase). And while most other languages out there are at least somewhat approachable by experienced engineers new to that particular language, Haskell code will basically be ungrokable black magic until you spend a few months full time learning it.

And the worst part is that there's so many styles of Haskell - even if you're experienced, sometimes when jumping into a foreigh codebase you'll be suddenly struck by comonods or some other PL-theory-heavy library you never used before. And that just sucks when you're trying to debug a production bug. To me it basically feels like you're never 'done' learning Haskell.

> And the worst part is that there's so many styles of Haskell - even if you're experienced, sometimes when jumping into a foreigh codebase you'll be suddenly struck by comonods or some other PL-theory-heavy library you never used before. And that just sucks when you're trying to debug a production bug. To me it basically feels like you're never 'done' learning Haskell.

It is true that you have to constantly be learning new idioms, (e)DSLs, libraries, types, etc in Haskell. But in my experience, it isn't so bad.

I was at a job with a production Haskell codebase that many senior engineers deemed unsalvageable and were trying to replace in parallel (I don't know if they ever did tbh.) We had production bugs and I had to debug them (I was on the team supporting the production service.) Instead of wincing at how "ugly" and awkward the code was, I just used techniques like the ones in this blog post. I immediately was able to make an impact in the correctness, availability, and performance of the production service, along with the extensibility and ergonomics of the codebase. All because I got my hands dirty instead of wishing things were perfect. It really wasn't hard at all.

Hey - I thought Haskell forces you write code without bugs! :)

Didn't we all at some point :)

> Either you're a Haskeller not familiar with monad transformer idioms, or you're not a Haskeller just shouting your uninformed opinion.

This comment feels unnecessarily aggressive.

Sorry - I just have very little patience for commenters saying Haskell is "hard to understand" or "doesn't mean anything" when they clearly haven't even passed the prerequisites of understanding.

When you don't have the prerequisites, the best thing to do is to be quiet and/or learn rather than pollute the comments with your unfounded value judgements.

so, you're essentially gatekeeping people's opinions about the code, because they don't understand the core concepts of Haskell?

I would argue that someone should be able to understand what a function does by reading the name regardless of their understanding of the underlying language it is written in.

I've noticed this type of weird expectation of understanding is very prevalent in the FP world, which makes it _harder_ for newcomers to understand code at face value.

> I would argue that someone should be able to understand what a function does by reading the name regardless of their understanding of the underlying language it is written in.

That's a bad litmus test imo and only encourages familiarity. If I used this to form my opinions, I would have peaced out the moment I saw >>= or traverse or foldMap

I am never going to believe everything should be immediately obvious to everyone. Sometimes, you have to buy in and learn some new abstractions instead of just favoring the ones that happened to be presented to you first.

-> everything should be immediately obvious to everyone

that....is not what I said. At all.

> I would argue that someone should be able to understand what a function does by reading the name regardless of their understanding of the underlying language it is written in.

You're saying that if someone doesn't know Haskell, they should be able to understand what functions in Haskell do by their name. Which disqualifies standard names like >>=, hoist, and more.

I'm saying if you don't have a working understanding of some technology, maybe think twice before negatively opining about it on HN.

nope, you're saying people aren't allowed to even have an opinion unless they pass your own criteria beforehand.

sorry, that isn't how most people operate. It would be a lot more constructive to tell them why their opinion is wrong, instead of telling them they aren't allowed to even have the opinion in the first place.

I never said that. My issue was with shouting uninformed opinions in a thread about a blog post by someone who actually has the experience to have such informed opinions.

Sometimes you gotta stop spouting answers and start asking questions.

-> I never said that.

Yes, you did.

-> When you don't have the prerequisites, the best thing to do is to be quiet and/or learn rather than pollute the comments with your unfounded value judgements.

reads as 'Shut up, your opinion doesn't matter'.

I'm done here. If you want to be rude and aggressive to people and turn them off to the concept of functional programming entirely, then that's on you, I suppose.

If you don't know Haskell, your opinion of if Haskell code 1) has a good name or 2) has an understandable implementation doesn't matter much to me, _especially_ on a blog post meant for proficient Haskellers such as this one.

In general, people can be better served lurking or asking questions or making qualified statements instead of blasting their opinion like this:

> The function name means nothing, and the implementation is hard to follow.

I don't know why you're getting downvoted (because of the tone?). As someone writing Haskell that name is as clear and concise as it should be.

Yes definitely the tone. Sadly I don't know how to be nicer when dealing with someone who seems to be projecting their opinion to an audience when they don't have the prerequisites to have that opinion to begin with. (It happens a lot in Haskell HN threads)