>>7
this is what south park fans were not creative enough to come up with on their own.
Name:
Dubs Guy2012-03-17 15:48
DUBS,DUBSEVERYWHERE!
Name:
Anonymous2012-03-17 19:13
Haskell is unsuitable for real world work.
Yes it's fine for small implementations of toys like fizz buzz, but that's it, this is also the reason why there doesn't exist any significant software written in Haskell none at all.
"Avoid success at all costs."
Peyote `Simon` Joints
Significant software would doom Haskell to be shit like any popular language.
Name:
Anonymous2012-03-17 19:24
>>13
Haskell is shit because it's unsuitable for any kind of work, except shitty toys, which better languages already got covered.
Name:
Anonymous2012-03-17 19:29
>>14
With ``dynamic'' languages everything turns into a big buggy mess; with C it's just tedious to write anything big.
Haskell is the perfect language for large applications because of the ease of abstraction, type system, modular programming, etc.. If you disagree I direct you to scrub another toilet you mental midget.
Name:
Anonymous2012-03-17 19:34
>>15 Haskell is the perfect language for large applications
That's funny, there are no large usable or significant applications that use Haskell.
It's shit, if you want to defend shit it's fine, but don't act surprised when someone tells you that your shit is shit.
ease of abstraction
This part actually confuses me. I was always under the assumption that "abstraction" is a process that is established by the developer, not the language (unless it really is so bad that calling it a "language" is being generous). Yes, the code itself is already an abstraction of something and often creates the ruleset for abstraction (of code), but I have yet to run into a situation where preparing abstraction is difficult for reasons of "unworkable language."
More often, I have to tell people I work with to hold back and not turn something simple into an unnecessary exercise.
Name:
Anonymous2012-03-17 19:55
>>16
A big shitty application requires a thousand minimum wage developers (unless it's written in Haskell where it'd only require two) and a proud Haskell developer would never write a big shitty application.
A Haskell programmer instead writes a thousand single-purpose applications and composes them into a final product that's bug-free and perfect in every way imaginable.
>>19
That. Most abstraction is just bullshit made-up by bad programmers to make them feel more important.
Name:
Anonymous2012-03-17 19:58
>>19
Haskell is like Lisp but with a compiler and a type system.
Name:
Anonymous2012-03-17 20:04
>>22
You can put lipstick on a pig, but it's still a pig.
Name:
Anonymous2012-03-17 20:06
>>22
Irrelevant. Lipstick and pigs have nothing to do with programming.
Name:
Anonymous2012-03-17 20:08
You can put Lisp on a Lisp, but its still an PHP!
Name:
Anonymous2012-03-17 20:10
>>21
A common pattern is to transform every value in a list. The regular method is to use an index and run a program to mutate the indexed elements of the list. Here's how your favorite languages do it:
FOR INDEX = 1 TO 10
' ...
NEXT INDEX
Here's Haskell's solution:
map = flip foldr [] . ((:) .)
Name:
Anonymous2012-03-17 20:11
what do i do when a haskell program is running slow
how do i figure out where to optimize
also OP is a fag:
1. Haskell is purely functional.
No.
haskell.org:
Haskell is an advanced purely-functional programming language.
Name:
Anonymous2012-03-17 20:14
>>27 GHC comes with a time and space profiling system, so that you can answer questions like "why is my program so slow?", or "why is my program using so much memory?".
>>28
So is GHC the only implementation of Haskell? How can GHC profiling help you beyond telling you how poor of a job GHC has done handling your code?
Name:
Anonymous2012-03-17 21:25
>>24
That's a conditional statement, the condition is hidden but still there.
>>30
There are many implementations, such as Hugs, which does not have optimizations up to par with ghc.
Name:
Anonymous2012-03-18 4:55
>>30 So is GHC the only implementation of Haskell?
Yes.
How can GHC profiling help you beyond telling you how poor of a job GHC has done handling your code?
If you have to profile you are doing it wrong. Haskell makes testing much easier, so you can just test one function at a time, and when you are done the function will be perfectly bug-free, reusable, and predictable in performance.
Vector addition in Lisp: (defun vecadd (&rest vecs)
(apply #'mapcar #'+ vecs))
--obvious use of map.
Vector addition in Haskell:
vecadd ::(Num n) => [[n]] -> [n]
vecadd = foldl vadd []
where vadd x y = zipWith (+) x y
--You have to reinvent the wheel all the fucking time and you still have to pass a list of lists, whereas in Lisp you can use syntax as for normal addition. Not that map wasn't used even if this is textbook example of its use.
Or, TYPECLASS CLUSTERFUCK if you want to be able to use standard syntax.
Name:
Anonymous2012-03-18 8:16
>>37
Here's a simpler implementation which actually works:
vecadd = map sum . transpose
If you want a polyvariadic function this works (by Oleg):
class BuildList a r | r-> a where
build' :: [a] -> a -> r
instance BuildList a [a] where
build' l x = reverse$ x:l
instance BuildList a r => BuildList a (a->r) where
build' l x y = build'(x:l) y
--build :: forall r a. (BuildList a r) => a -> r
build x = build' [] x
>>38
Except that transpose you did there takes some time, so it's not equivalent solution. The CL solution or the trivial Haskell solution I showed only need to traverse the list of vectors once.
And as I said, if you want to use something that at least resembles standard syntax of the language for addition, you have to use ugly hacks and you still have some $ build there that serve nothing obvious from the point of whoever will read the code.
Haskell is ugly as fuck and limits its users in many ways, therefore it shouldn't be used by anyone. Oh, wait, it isn't.