I don't understand what you said, but it sounds like FUD.

- Haskell does not have "a new kind of bugs". It's an ordinary programming language with ordinary bugs.

- The bugs you put in your program are not any more or less undetectable before production compared to unstable than they are in other languages.

Telling that king is naked also sounds like FUD.

FUD is fear, uncertainty, doubt. I corrected your statement by saying there is no reason for that particular fear, uncertainty, or doubt. I don't see how that qualifies as FUD. (I'm leaving this thread now.)

You're mischaracterizing a problem that you can encounter in Haskell as being unique to Haskell and intractable. You can leak space in effectively any language and just like in other languages there are tools and conventions to detect and avoid it.

Of course you can leak space in every turing complete language even on purpose, but in case of languages with lazy evaluation (like Haskell) you are no longer able to trivially reason about your programs behavior until execution on real data in real environment.

I agree that Haskell has some good (old) ideas and it is pleasant to Sunday programmers.

And again, if you play fast and loose with allocations you always shoot yourself in the foot. Carelessly allocating thunks on the heap is no different from carelessly allocating data in that regard. Haskell won't save you from yourself.

Judging from the other comments, it's clear you have an axe to grind. I'm leaving this thread as well.

[citation needed]. Seriously, which kind of bugs are you referring to?

Really? http://stackoverflow.com/questions/21097051/kinds-of-bugs-th...

I am sorry, I fail to see a bug there which "cannot be detected by any test until running in production on real data when it is already too late". It's mainly problems with lazy IO which should be detected by unit tests using test data, right? The first answer is actually a nasty bug, but you should probably not deploy code which sends your test suite into an endless loop no matter in which language it is written. Yes, Haskell does not solve all programming problems, but I don't see anything which could not be found by testing here.

Unit test will not detect everything. You need real data under heavy load for Haskell. This is a _fact_.

Most of you here should stop writing BS about Haskell and how it is going to save the world.

> I never said that. Your argument was that this is specific to Haskell which is not.

It is specific to lazily evaluated languages, especially Haskell. To test Haskell program you will need a real environment under heavy load - maybe Google or Amazon could afford it. Tiny unit tests which are perfect for strictly evaluated languages won't detect these kid of bugs.

> Unit test will not detect everything.

I never said that. Your argument was that this is specific to Haskell which is not.

> You need real data under heavy load for Haskell.

How is this different from other languages?

> This is a _fact_.

Using "_" does not replace an actual argument ;)

> Most of you here should stop writing BS about Haskell and how it is going to save the world.

I fact, I wrote the opposite in the parent of your post.