Functional programing languages

>>21
Darcs, xmonad, yi
Let's examine these, shall we? I think you'll see that your so-called argument falls apart like a house of cards in a thermonuclear hurricane. No exceptions.

Darcs is a slow, buggy, unusable version control freak system. Every project that has ever used it has gotten fed up with its shitty performance and switched to something written in an imperative language. I guess you could consider that a real application in about the same sense that a steamroller is a real car.

Xmonad is a tiling window manager, which menas it has an incredibly niche audience to begin with. But apparently, even in that niche audience, it's looked down on by everyone who knows anything about window managers. For example: "On the other hand xmonad has great defaults, key bindings and xinerama support but is crippled by not being written in C." — http://www.scrotwm.org

Yi is a slow, buggy clone of a text editor that nobody uses (vi). It's easily the most blatant example of the three of the problems that come from writing an interactive application in a functional language. Every time you input text, it has to rebuild all of its immutable data structures from scratch, because it can't destructively update an array containing the text. And it does this on every keypress. I might as well be using head, tail, and cat to edit my files for all the good it's doing me.

Haskell's goal is to avoid success at all costs
And that's the one thing it will succeed at. Permanently.

>>22
No you_'r not. You can't even fix you^are BBcode.

[i]AM I DOING IT RIGHT?[rem][/i][/rem]

>>24
And this children, is why you shouldn't troll without adequate training.

Good lord, do we have to discuss the usefulness of functional languages every fucking day? Can't we just let them be?

I'll just leave this right here
.

>>29
And this children, is why you shouldn't break /prog/'s hymen without adequate training.

>>29
D
o
i
n
g

i
t

w
r
o
n
g
.