http://en.wikipedia.org/wiki/Strict_programming_language
"Haskell's the one that insists that I have to do it Haskell's way."
... when you're writing Haskell. But I am the one who sometimes wishes I could manipulate actions in that way when I am writing C.
"But I suppose you'd say that I have the choice to not use Haskell, so stop complaining."
I'm saying that it obviously doesn't make pragmatic sense to require things in contexts where they don't make sense, but that 1) some things can make sense in more contexts than you might think, and 2) that you would do well (for pragmatic reasons) to actually learn about this stuff before deciding you don't need it.
Absolutely.
> you would do well (for pragmatic reasons) to actually learn about this stuff before deciding you don't need it.
I keep learning about it. I still haven't seen any need for it. But then, my whole career is in a context where it doesn't make sense...
Well, like I said, applicability can be occasionally surprising. What is your background like?
Incidentally, you can write Haskell to write your embedded C: https://hackage.haskell.org/package/atom
I haven't actually played with it, but understand it's used in production.
OK, if you have non-strict semantics (by which I presume you mean non-sequential), then you need some way to make things sequential when they have to be, and you have no ordinary (non-jumping-through-hoops) way to make them so.
> "You have to do things my way, or you're not pragmatic!" seems to be your dogma.
Shoe's on the other foot. Haskell's the one that insists that I have to do it Haskell's way. I complain, and you accuse me of being dogmatic. Doesn't work that way.
But I suppose you'd say that I have the choice to not use Haskell, so stop complaining. And in fact, I take that choice, precisely because I consider the language's dogmatism to be less pragmatic (and therefore useful) than a multi-paradigm approach.