Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Haskell

Name: Anonymous 2009-03-15 0:26

It's the biggest sham I've ever seen. I finally know why this entire board is so obsessed with it: It's the perfect language for insane trolls.

The evaluation order is nondeterministic, so trying to make programs run fast is like feeding Schrödinger's cat. The syntax is so arcane and impossible to remember... Sure it looks deceptively simple at first but the punctuation WILL make you insane. And if I have to modify another goddamn program to pass YET ANOTHER parameter into every single function that needs to know the current state (and a real program has a LOT of these, remember) I swear I'll marry Hans Reiser so he'll kill me as brutally as humanly possible, just to vent my fucking rage.

Oh, and you're all assholes.

Name: Anonymous 2009-03-19 3:25

Look at Haskell's OpenGL bindings, for example. They are consistently about a decade out of date.

Read Lennart Augustsson's comments about using LLVM from Haskell, in particular, the bit where he explains the showstopping bugs he found in GHC's FFI:

http://augustss.blogspot.com/2009/01/performance-update-ive-continued.html

"The GHC FFI is broken for all operations that allocate memory for a Storable, e.g., alloca, with, withArray etc. These operations do not take the alignment into account when allocating. This means that, e.g., a vector of four floats may end up on 8 byte alignment instead of 16. This generates a segfault."

Frag and Topkata are the only two notable graphical programs ever written in Haskell and both are prone to segfaults because of problems with Haskell's FFI.

There are hundreds more counter examples, of course.

EDIT: I found another graphical application written in Haskell called Raincat but, err, it dies at startup when trying to interact with ALSA.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List