4 ms·

I would say that the difference is that the Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as

by SiVal 13y ago

I would say that the difference is that the Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable. There are many programs that run on servers, grinding away on deep questions for extended periods with no more than the bare minimum of communication with the rest of the universe---maybe just a terse "42" at the end of a long run. But the Web is about talking to users thousands of times per second, sending it all in a hurricane of streams to a database, fetching data for each of them from various databases, streaming it out to a third-party credit card processor, sending the results back to the users.... Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams.

asdasf 13y ago
>Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable. That isn't what haskell does though, that is the "I've never bothered to learn haskell and want to spread FUD" version of it. I/O is not "a ghetto" in haskell, it is first class. Haskell just makes I/O explicit, it doesn't make it unpleasant. My app is literally nothing but I/O, just plumbing between postgresql and browsers. Haskell has done nothing to make that difficult or unpleasant, and has done much to make it easier and simpler, especially in regards to error handling and form processing, which frankly is most of the code.
- carterschonwald 13y ago
  well said. I do very very imperative things in haskell. Including very very high quality numerical algorithms where i'm writing vectorized math that uses the cpu ports well (the things that let you get instruction level parallelism), the cpu caches well, etc. Basically, I know how to write fast code. Haskell supports writing sophistcated algorithms using these gnarly bits of code i wrote as primops in a really nice way. this code is more imperative than most "web" code ever written ever, and competes favorable with state of the art alternatives written by dedicate experts. Point being, anyone who says haskell can't do IO is an idiot and needs to finish their computer science education, or get one :) (or, get a refund)
dragonwriter 13y ago
> I would say that the difference is that the Web is almost entirely about I/O That's true in the trivial sense, in the same way that "the desktop" is about i/o, or "the command line" is, in that all of those specify an i/o channel. But web apps or services aren't all about i/o any more than any other applications/services, they just differ in that the main user-facing i/o channel is HTTP. > Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams. Monads aren't ghettos isolated from the real work of the program. Monads are tools for doing the real work of the program -- whether its i/o, or dealing with mutable state in a transactional, concurrency-safe manner, or, well, lots of other things.
- asdasf 13y ago
  >That's true in the trivial sense I think it is true in the actual real world practical sense too. Consider how many web applications are just plumbing between a database and a browser. 95% of my app is in a MonadIO.
dmytrish 13y ago
<i>Web is almost entirely about I/O</i> — I think it's not quite correct, the web is half about IO and half about parsing, and parsing is where Haskell shines. Haskell does not avoid IO because it's an unfortunate aspect, it avoids IO to simplify things, to minimize the surface that can break, to make it more easily optimizable to a compiler. "Pollution" is just an emotional term used in teaching beginners to emphasize usefulness and beauty of pure functions.

by SiVal 13y ago

asdasf 13y ago

>Web is almost entirely about I/O, which Haskell treats as an unfortunate aspect of programming that is to be made as unpleasant as possible so it will be avoided except where unavoidable. That isn't what haskell does though, that is the "I've never bothered to learn haskell and want to spread FUD" version of it. I/O is not "a ghetto" in haskell, it is first class. Haskell just makes I/O explicit, it doesn't make it unpleasant. My app is literally nothing but I/O, just plumbing between postgresql and browsers. Haskell has done nothing to make that difficult or unpleasant, and has done much to make it easier and simpler, especially in regards to error handling and form processing, which frankly is most of the code.

carterschonwald 13y ago
well said. I do very very imperative things in haskell. Including very very high quality numerical algorithms where i'm writing vectorized math that uses the cpu ports well (the things that let you get instruction level parallelism), the cpu caches well, etc. Basically, I know how to write fast code. Haskell supports writing sophistcated algorithms using these gnarly bits of code i wrote as primops in a really nice way. this code is more imperative than most "web" code ever written ever, and competes favorable with state of the art alternatives written by dedicate experts. Point being, anyone who says haskell can't do IO is an idiot and needs to finish their computer science education, or get one :) (or, get a refund)

dragonwriter 13y ago

> I would say that the difference is that the Web is almost entirely about I/O That's true in the trivial sense, in the same way that "the desktop" is about i/o, or "the command line" is, in that all of those specify an i/o channel. But web apps or services aren't all about i/o any more than any other applications/services, they just differ in that the main user-facing i/o channel is HTTP. > Haskell's ideal of minimal I/O isolated in a ghetto so the "real" work of the program can remain unpolluted doesn't seem an ideal match for the case where the real work is almost entirely about routing I/O streams. Monads aren't ghettos isolated from the real work of the program. Monads are tools for doing the real work of the program -- whether its i/o, or dealing with mutable state in a transactional, concurrency-safe manner, or, well, lots of other things.

asdasf 13y ago
>That's true in the trivial sense I think it is true in the actual real world practical sense too. Consider how many web applications are just plumbing between a database and a browser. 95% of my app is in a MonadIO.

dmytrish 13y ago

<i>Web is almost entirely about I/O</i> — I think it's not quite correct, the web is half about IO and half about parsing, and parsing is where Haskell shines. Haskell does not avoid IO because it's an unfortunate aspect, it avoids IO to simplify things, to minimize the surface that can break, to make it more easily optimizable to a compiler. "Pollution" is just an emotional term used in teaching beginners to emphasize usefulness and beauty of pure functions.