6 ms·

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

whateveracct 7y ago
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.
- gizmo385 7y ago
  > 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.
  - whateveracct 7y ago
    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.
    - holtalanm 7y ago
      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.
      - whateveracct 7y ago
        I'm saying if you don't have a working understanding of some technology, maybe think twice before negatively opining about it on HN.
        holtalanm 7y ago
        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.
        whateveracct 7y ago
        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.
        holtalanm 7y ago
        -> 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.
        whateveracct 7y ago
        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.
- q3k 7y ago
  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.
  - whateveracct 7y ago
    > 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.
    - p1esk 7y ago
- hopia 7y ago
  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.
  - whateveracct 7y ago
    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)
- deleted 7y ago
  [deleted]

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.

gizmo385 7y ago
> 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.
- whateveracct 7y ago
  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.
  - holtalanm 7y ago
    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.
    - whateveracct 7y ago
      I'm saying if you don't have a working understanding of some technology, maybe think twice before negatively opining about it on HN.
      - holtalanm 7y ago
        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.
        whateveracct 7y ago
        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.
        holtalanm 7y ago
        -> 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.
        whateveracct 7y ago
        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.
q3k 7y ago
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.
- whateveracct 7y ago
  > 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.
  - p1esk 7y ago
hopia 7y ago
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.
- whateveracct 7y ago
  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)
deleted 7y ago
[deleted]