3 ms·

Someone else was complaining about the excessive pedantry imperative languages and I pointed out not all languages are so pedantic. And you're calling this jud

Someone else was complaining about the excessive pedantry imperative languages and I pointed out not all languages are so pedantic. And you're calling this judgement? I mean, in the objective sense: declarative languages abstract over control flow and make programs less repetitive. If you (like me) think that's bad, then I think my conclusion is obvious. If you don't, why would my opinion concern you at all? It's almost like your comment is, "Hey don't have opinions about tooling." If that's your message: I apologize but I both cannot and will not oblige you.

AnimalMuppet 9y ago
Well, to me at least, you came across as more than just saying "here's a solution to the excessive pedantry". I read your response as being more judgmental than that. Perhaps that's my problem rather than yours, but that's how I read it. As qbrass pointed out, though, a functional language doesn't really save you from (most of) the detail, but only lets you express it somewhat better. (Your foldM reply, if I understand correctly, only eliminates the loop of taking steps. Somewhere you still have to put your hand on the door, turn the doorknob, swing the door open, etc.) So the excessive pedantry is still there. It's just slightly less, because you use a fold[M] rather than explicitly write the for loop. That's... a bit of improvement. It's a detail you don't have to pay attention to when you don't need to, which is most of the time. But (at least in this example), the vast bulk of the detail remains, even in a functional language.
- KirinDave 9y ago
  It's true: we'd need a way to describe the tiny imperative steps. The benefit is that we DON'T need all the glue between them. Few languages and methodologies can deliver on this problem as well as Haskell can. Consider what my example is folding over and how those elements must connect. I'm not sure we could really do that monoidally. For a sequence of steps: probably. For opening doors and other conditional actions: we might need a more flexible strategy (I'm sure at the end though we'd call sequenceA on it!)

AnimalMuppet 9y ago

Well, to me at least, you came across as more than just saying "here's a solution to the excessive pedantry". I read your response as being more judgmental than that. Perhaps that's my problem rather than yours, but that's how I read it. As qbrass pointed out, though, a functional language doesn't really save you from (most of) the detail, but only lets you express it somewhat better. (Your foldM reply, if I understand correctly, only eliminates the loop of taking steps. Somewhere you still have to put your hand on the door, turn the doorknob, swing the door open, etc.) So the excessive pedantry is still there. It's just slightly less, because you use a fold[M] rather than explicitly write the for loop. That's... a bit of improvement. It's a detail you don't have to pay attention to when you don't need to, which is most of the time. But (at least in this example), the vast bulk of the detail remains, even in a functional language.

KirinDave 9y ago
It's true: we'd need a way to describe the tiny imperative steps. The benefit is that we DON'T need all the glue between them. Few languages and methodologies can deliver on this problem as well as Haskell can. Consider what my example is folding over and how those elements must connect. I'm not sure we could really do that monoidally. For a sequence of steps: probably. For opening doors and other conditional actions: we might need a more flexible strategy (I'm sure at the end though we'd call sequenceA on it!)