4 ms·
Why don't you deal with specifics? I am not talking about its attractiveness, I have already made clear that I think Haskell is more elegant. But, why is this
by louthy 9y ago
Why don't you deal with specifics? I am not talking about its attractiveness, I have already made clear that I think Haskell is more elegant. But, why is this "not viable" or "does not fit the requirements"? I have already shown how a totally generic version of mconcat can be implemented - so how is this not writing "code that is generic on Monoid"?
- marcosdumay 9y agoOne very specific. I create a logging module on Haskell. There I put some high order functions like this: module Log where -- | Runs the code inside a catch, logs any exception exceptions :: IO a -> IO a -- | Logs every code execution access :: IO a -> IO a -- And so on, for several different kinds of logging Then on the main code I do: import qualified Log as Log main = do -- Lots of stuff Log.errors . Log.access $ readSomeData Log.errors $ whateverThatCanFail Log.access $ shoudlntFailButICareAboutRunning On C# each use of those logging functions will be more verbose than copying the entire function body in place. And almost as brittle.
- louthy 9y agoSorry, where did I say C# is less verbose than Haskell? And what has that got to do with implementing polymorphic return values?