> I'm just saying that the vast majority of programmers are nowhere near prudent enough to appreciate the strength of a correct/lawful system That seems like a

> I'm just saying that the vast majority of programmers are nowhere near prudent enough to appreciate the strength of a correct/lawful system That seems like a failure of education. Imagine if we put up with bridges that collapsed because "most engineers are nowhere near prudent enough..." People use what they were taught to use. Programming languages form part of that teaching. Bad programming languages teach people bad habits. > after all there are many C programs that are sort of correct but not easily written with standard, total, and sound types For example? I suspect there's a kind of all-or-nothing mentality behind this. I would bet you can easily write the sort of programs you're thinking of in a good functional language, if you don't get hung up on perfection. It would still be a significant improvement. There are many examples of this - XMonad comes to mind, which you can compare to i3 which is written in C. It seems to me that most of what you're saying boils down to simple unfamiliarity. I would suggest that you're suffering from a kind of inverse expert blindness. You discount the amount of learning that went into your ability to understand a phrase like "race the futures," and this leads you to reject systems that are different enough that you can't easily apply that existing expertise to. Your difficulties in reading miso code without, apparently, consulting any documentation is a little silly, I'm afraid. What programming language, that is significantly different from the ones you already know, allow you to read its code without any background knowledge? If you're actually working with the language, there are easy ways to answer all the questions you're asking. Short of gasp reading the docs, you can query the functions or operators you're interested in at the ghci prompt. For example: > :t div_ div_ :: [Attribute action] -> [View action] -> View action This helpfully points out that the first argument to `div` is a list of Attributes. If there are no attributes, that list would be empty. That wasn't so hard! You could also read the docs: https://hackage.haskell.org/package/miso-1.5.2.0/docs/Miso-Html-Element.html#v:div_ https://hackage.haskell.org/package/miso-1.5.2.0/docs/Miso-H... Or look it up in Hoogle: https://hoogle.haskell.org/?=&hoogle=div_%20package%3Amiso https://hoogle.haskell.org/?=&hoogle=div_%20package%3Amiso > Similarly, when I look at servant's documentation I wonder how come a such powerful language, but to model 'GET /user/:userid' it can't - or doesn't - use /user/:userid, but "user" :> Capture "userid" Integer It's expressing the route in the language rather than in an untyped string. :> is just the operator servant defines to separate route components. But here (and in some of your other observations) you seem to be conflating a decision that the servant authors made, with the language itself. > So, all in all, I'm just a lazy ... That's your choice. You should just know that your critiques are off the mark - they're the stories you're telling yourself to justify not having to learn.