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?
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.
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.
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.
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)
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.
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.
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.
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...
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?
The more a piece of a system has been used to build things, the more confident you can be that it doesn't have bugs that will be getting in your way. The more similar these things are to what you're planning on doing, the more confident you can be that things won't get in your way. What the thresholds should be depends on the particular tech, your particular project, and the world around it. Maturity is absolutely something that should be traded away when there is sufficient reason.
This is by no means lazy or unintellectual unless you're using it as an excuse not to work (or learn) or not to think.
Regarding your implicit concern about no one being the one to step up and shoulder the burden of trying new things in production, I reiterate my assertion that maturity is just one factor that should be used in determining technology choice, and there's nothing wrong with those first venturing to new things those who have the most to gain by their use.
For what it's worth, I'd like to note that I am presently writing a web application in Haskell, so I obviously don't think it's a poor fit for all web projects.
"Make it explicit for me, how many page views/month do I need before haskell has been declared gremlin free?"
There is no such thing as gremlin free. As something is tested in various environments, we become gradually more confident that there are no gremlins.
A gremlin might look like:
I spent weeks building this system, and now I realize that it can't ever really be robust because I built it all around lazy IO and have no good method of controlling where exceptions happen when they are triggered.
That would be an example of Haskell - as a language and ecosystem - being immature. This is not what anyone recommends doing anymore, because the people have realized there be dragons there. Dragons are worse than gremlins, as it happens.
The odds of similar troubles go down over time, especially for areas anyone has done work near.
I'm sure we could quantify, with sufficient data, but I don't have the resources and I'm not sure it would be a good use anyway. How many resources did you put into investigating the other pros and cons, when you made the decision to use Haskell? Like anything else, it's a concern I give some thought, and weigh against other concerns, investing as much time into it as seems appropriate - estimating from what I've observed on other projects, what I've heard from other people, &c.
Just because I acknowledge that something can be a legitimate concern doesn't mean I'm lazy and unintellectual for not pouring way more resources than I have into it - eventually we have to get work done, and doing yet more investigation of the details of a particular decision has diminishing returns.
No, I want to argue (constructively, I hope) about things people say that I disagree with, in the hopes that at least one of us learns something.
"Your position is a strawman."
This is nonsensical. I'll assume you meant "You are arguing with a strawman." I'm not sure that's the case, but feel free to clarify any of your above arguments if you think I misinterpreted something.
'The original poster I replied to was literally saying "can't use haskell cause academic norealworld". That is lazy and unintellectual.'
On reviewing the thread, I understand you to be speaking of part 3 of https://news.ycombinator.com/item?id=6109593
What was literally said was, "I don't know what mature means, but they are not used by high-profile applications", where "they" referred to "3. Mature libraries for web development: frameworks, templating languages, ORMs" from the parent comment. Is that right?
I would say that "can't use haskell cause academic nonrealworld" is a substantial mischaracterization of that, and the parent point is something I would agree with - so far as I am aware we have not seen the haskell web frameworks exposed to tremendous real-world load.
"I wasn't talking to you, so constantly trying to re-frame my statements as though they were directed at you is not productive."
You were replying to me, so I'm confused who you were talking to. If you simply mean you weren't talking about me, I'm not sure I agree, as you seemed to be speaking in broad terms about those who might hold views I think are at least reasonable. I didn't so much think you were calling me out specifically.
Generally, this comment seems disingenuous at best, and I may not reply if you follow up, unless you raise the level of discourse - your earlier comments were better.
You might also be interested in the work of Galois. They've got some slides on Haskell in industry: http://www.scribd.com/doc/19502765/Engineering-Large-Project...
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.