2 ms·

Of course, Haskell is right, the jargon is precise. That doesn't mean underlying concepts are not what everyday programmers use. The jargon has given proper nam

by pas 6y ago

Of course, Haskell is right, the jargon is precise. That doesn't mean underlying concepts are not what everyday programmers use. The jargon has given proper names to the general concepts, it reified them, made them first-class citizens. I'm not saying they are not useful. (On the contrary, they are invaluable for high level discussions about certain aspects of programming, including control flow, data structures, and programming techniques.) Every async/await implementation is basically a monad with fancy syntax. > Conflating the generic concept with specific instances will mislead you. Yeah, agreed, no questions there. I'm just saying that the vast majority of programmers are nowhere near prudent enough to appreciate the strength of a correct/lawful system, plus they usually have other powerful concepts in their heads (after all there are many C programs that are sort of correct but not easily written with standard, total, and sound types, plus the required assumptions are not expressed in the source code). Also, another angle I think might help to convey what I'm trying to say is to look at how much jargon is needed to explain things like for-comprehensions execute the monad steps in sequence, but if you use mapN and an applicative then you can execute independent steps in paralell. Whereas it's just "race the futures" (or Promise.all, or whatever) in common programming parlance. > Perhaps you've had this experience from experimenting with functional languages [...] > What language are you thinking of? Sounds like Scala maybe. Yes, I don't know Haskell, I have a few years of Scala with some Scalaz experience. And maybe you're familiar with mypy and TypeScript, and it's obvious how problematic is to build the bridge between existing semantics and a correct/sound type system. (And of course, it's very much impossible, because you either have soundness or not, and so TS is unsound to be useful, and mypy is useless unless you rewrite many things.) > [...] and I find functional languages to be models of elegance by comparison I haven'got the hang of any pure functional language (yet?). I like to think it's not because of lack of trying. I see where concepts can be useful (eg. how TS and Rust would benefit from HKT, and how many people are waiting for a more expressive type system to create better abstractions, better libraries, better APIs), but to me all Haskell code looks like something like a dadaist poem with strange symbols sprinkled here and there. (Eg I'm looking at the sample app for miso https://github.com/dmjio/miso#sample-application https://github.com/dmjio/miso#sample-application and I have no idea what is what, no idea about shapes, what's <#, what's >>, why div_ and button_ have underscores after them, why div_ takes an empty list, what's {..}? And sure, most of these can be found, but still a lot harder than even the most damned FactoryFactoryBean in Java. And sure, I appreciate that lenses and the Transition interface helps with stuff, but that's simply a very small incremental ergonomic enhancment compared to what I wish. 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. The type is nice, and whatever :> is, I'm sure that's nice too, but I'm not finding the elegance that TSed has - https://github.com/TypedProject/tsed#create-your-first-controller https://github.com/TypedProject/tsed#create-your-first-contr... ) So, all in all, I'm just a lazy party-pooper when it comes to Haskell (or FP in general). And mostly just because the pain of debugging TypeScript and the myriad "any"-s everywhere still seems the lesser one than trying to grok the the cryptic symbols.

antonvs 6y ago
> 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.

by pas 6y ago

antonvs 6y ago

> 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.