3 ms·

I'm only arguing about naming conventions here -- I probably wasn't clear enough about that. I know what the IO type constructor does. My point was merely that

by codeflo 13y ago

I'm only arguing about naming conventions here -- I probably wasn't clear enough about that. I know what the IO type constructor does. My point was merely that if no one ever says "getChar is an IO", then maybe its type shouldn't be called IO. For all of Haskell's beautiful concepts, it does have some flaws. I think that overly cute (and, as I explained, sometimes inconsistent) names are one of them, because that's at often odds with readability. Haskell's identifiers are not Perl-level bad, but they are not shining examples of clarity either. I hope I didn't offend you with this. I don't actually think we'd disagree much if we had discussed this face-to-face.

nbouscal 13y ago
Nope, no offense taken at all. I just disagree with the verbosity approach to writing software. You referred a couple of times to the name as a "description", but there's a big difference between names and descriptions. They serve different roles. IO is a good concise name, and if someone wants to know more about it, they can go read its description in the Haddocks or other supplementary texts. People don't say "getChar is an IO", but they (when typing) would probably say that "getChar is an IO ()", or when speaking "getChar is of type IO unit". Reading it as "IO action" is useful pedagogically, to answer questions like "what is an IO?", but typing out IOAction every time is annoying and unnecessary. Especially because then MonadIO would have to become MonadIOAction, which is just silly. One of the worst trends in contemporary software engineering is to conflate names and descriptions, so you end up with absurdities like SimpleBeanFactoryAwareAspectInstanceFactory or InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter* . Yes, I'm picking on Java and these are extreme examples, but it's just the exact same principle applied to a much greater extent. *Found in Spring and JDK, respectively.

by codeflo 13y ago

nbouscal 13y ago

Nope, no offense taken at all. I just disagree with the verbosity approach to writing software. You referred a couple of times to the name as a "description", but there's a big difference between names and descriptions. They serve different roles. IO is a good concise name, and if someone wants to know more about it, they can go read its description in the Haddocks or other supplementary texts. People don't say "getChar is an IO", but they (when typing) would probably say that "getChar is an IO ()", or when speaking "getChar is of type IO unit". Reading it as "IO action" is useful pedagogically, to answer questions like "what is an IO?", but typing out IOAction every time is annoying and unnecessary. Especially because then MonadIO would have to become MonadIOAction, which is just silly. One of the worst trends in contemporary software engineering is to conflate names and descriptions, so you end up with absurdities like SimpleBeanFactoryAwareAspectInstanceFactory or InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter* . Yes, I'm picking on Java and these are extreme examples, but it's just the exact same principle applied to a much greater extent. *Found in Spring and JDK, respectively.