6 ms·

If you like hammers you can make them do anything. Or is the analogy nails? I forget. The real question is why use Haskell instead of something else that most

If you like hammers you can make them do anything. Or is the analogy nails? I forget. The real question is why use Haskell instead of something else that most people generally consider targeted at the web?

asdasf 13y ago
>The real question is why use Haskell instead of something else that most people generally consider targeted at the web? That applies to any language. Why use perl? Why use PHP? Why use ruby? Why use java? Web development isn't magical, it is just ordinary, general purpose programming. So people use ordinary, general purpose programming languages. Like perl, PHP, ruby, java, and haskell.
dragonwriter 13y ago
> The real question is why use Haskell instead of something else that most people generally consider targeted at the web? An equally "real" question is why people think "the web" is special in such a way that it requires a different programming language for back-end applications than other server applications use.
- dllthomas 13y ago
  That seems like a far more real question.
- 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.
egonschiele 13y ago
Off the top of my head: 1. Built-in concurrency makes your backend scale better. 2. Type system reduces bugs in your code. 3. Mature libraries for web development: frameworks, templating languages, ORMs. I'll admit there are some downsides: 1. Harder to hire devs that know Haskell. 2. Smaller community. But it seems like those are getting resolved quickly. The Haskell community is growing, and there is better documentation and support thanks to companies like FPComplete. O'Reilly has been publishing a bunch of books in Haskell, the Stack Overflow community is active and helpful...
- hbbio 13y ago
  1. Concurrency makes applications scalable, not fast. 3. I don't know what mature means, but they are not used by high-profile applications. 1'. This is probably balanced by their high-motivation to work on a Haskell project.
  - asdasf 13y ago
    >I don't know what mature means, but they are not used by high-profile applications. Does that mean that if my website becomes "high-profile" next month haskell will have suddenly become a better language than it is now, without the language changing at all?
    - jmgrosen 13y ago
      It's evidence that it's viable, whereas now it might be great in theory, but there's no direct evidence that it works in practice for large-scale projects.
      - asdasf 13y ago
        That seems like a very bizarre way for technical people to behave. "I'll assume this general purpose programming language must have some weird problem that somehow makes it unusable, but people can only find out about that problem if they write a popular project in the language". Why not assume every general purpose programming language is capable of being a general purpose programming language baring evidence to the contrary? Shouldn't tech people be capable of examining the language and determining if there's evil "large-scale" goblins lurking within?

asdasf 13y ago

>The real question is why use Haskell instead of something else that most people generally consider targeted at the web? That applies to any language. Why use perl? Why use PHP? Why use ruby? Why use java? Web development isn't magical, it is just ordinary, general purpose programming. So people use ordinary, general purpose programming languages. Like perl, PHP, ruby, java, and haskell.

dragonwriter 13y ago

> The real question is why use Haskell instead of something else that most people generally consider targeted at the web? An equally "real" question is why people think "the web" is special in such a way that it requires a different programming language for back-end applications than other server applications use.

dllthomas 13y ago
That seems like a far more real question.
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.

egonschiele 13y ago

Off the top of my head: 1. Built-in concurrency makes your backend scale better. 2. Type system reduces bugs in your code. 3. Mature libraries for web development: frameworks, templating languages, ORMs. I'll admit there are some downsides: 1. Harder to hire devs that know Haskell. 2. Smaller community. But it seems like those are getting resolved quickly. The Haskell community is growing, and there is better documentation and support thanks to companies like FPComplete. O'Reilly has been publishing a bunch of books in Haskell, the Stack Overflow community is active and helpful...

hbbio 13y ago
1. Concurrency makes applications scalable, not fast. 3. I don't know what mature means, but they are not used by high-profile applications. 1'. This is probably balanced by their high-motivation to work on a Haskell project.
- asdasf 13y ago
  >I don't know what mature means, but they are not used by high-profile applications. Does that mean that if my website becomes "high-profile" next month haskell will have suddenly become a better language than it is now, without the language changing at all?
  - jmgrosen 13y ago
    It's evidence that it's viable, whereas now it might be great in theory, but there's no direct evidence that it works in practice for large-scale projects.
    - asdasf 13y ago
      That seems like a very bizarre way for technical people to behave. "I'll assume this general purpose programming language must have some weird problem that somehow makes it unusable, but people can only find out about that problem if they write a popular project in the language". Why not assume every general purpose programming language is capable of being a general purpose programming language baring evidence to the contrary? Shouldn't tech people be capable of examining the language and determining if there's evil "large-scale" goblins lurking within?