i love haskell, what do?

/program/, help me. I'm learning Haskell, and I love it. What can I do to rectify my correct opinion that functional programming is a wonderful and powerful tool?

>>6
the only interesting response to OP and it gets no responses.

What I will say is that you are mostly wrong for a couple of reasons. First, your argument depends on the assumption that premature optimization is a good thing. Second, it's just incorrect. Declarative programming ideally ONLY leaks in performance, and with a "sufficiently intelligent compiler", not by much. Otherwise, declarative programming IS the abstractions that you are trying to express, and that's just one small part of what makes it so powerful. I honestly have trouble approaching a project in an imperative language without first going "ok, how do I get the effects of closures, garbage collection, lazy lists, data-as-code, code-as-data, persistent data structures, interned strings, destructuring, etc etc" Most of times the work arounds for the lack of these features are not worth my time or are inefficient (eg, for persistent data structures, just doing a naive linear copy) and I think, "OK, I'd honestly rather implement a better language than work in this one."

These general purpose abstracts REALLY ARE general purpose. There are VERY FEW applications for which they leak, and when they do it is ONLY in performance.

The answer to life, the universe and everything.

>>41

"ok, how do I get the effects of closures, garbage collection, lazy lists, data-as-code, code-as-data, persistent data structures, interned strings, destructuring, etc etc"

Note that none of these amazingly useful things is declarative programming.

praimu GET

Who was my moronic predecessor?

Why DUBya.

>>41
Why does the argument depend on when you optimize?
Also I wouldn't even call it optimizing if you merely try to get the same performance an imperative program would have without the programmer even thinking about performance.

As for the "sufficiently smart compiler": Compilers do almost nothing to optimize algorithms.

fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

fib n = fib' 0 1 n
  where
    fib' a _ 0 = a
    fib' a b n = fib' b (a+b) (n-1)

Here we have 2 times the exact same declarative program (also the same as the one in >>6). The first one will run in exponential (not by much??) time and the second one in linear time. In an imperative language anyone would implement it as a simple iteration without thinking about optimization:

a = 0; b = 1
n.times { a, b = b, a + b }

In haskell you can't write this, because you don't have assignment and state, but the haskell programmer has to think of this imperative program first and then he has to know enough about the implicit imperative semantics attached to haskell (which do make sense if you think about how computers work but are completely arbitrary from a declarative perspective) to be able to translate it to exactly the right declarative program.

Also what >>43 said

haskell is baby lisp

Fibs is, was and will always be the worst example of anything ever.

>>47

Actually I agree with you. Fucking hate 'em Fibo numbers.

Fibs is the best demonstration of the capabilities of a language/library.

Jackson fifty get.

Bump for being Haskell.

>> 25

Here:
data Brainfuck = Brainfuck { ll :: [Int], lf :: Int, lr :: [Int], out :: String }

gr :: [Int] -> (Int, [Int])
gr [] = (0, [])
gr (x:xs) = (x, xs)

brainfuck :: Brainfuck -> Char -> Brainfuck
brainfuck (Brainfuck ll lf lr out) '>' = let (f, r) = gr lr in Brainfuck (ll ++ [f]) f r out
brainfuck (Brainfuck ll lf lr out) '<' = Brainfuck (init ll) (last ll) (lf : lr) out
brainfuck (Brainfuck ll lf lr out) '+' = Brainfuck ll (lf + 1) lr out
brainfuck (Brainfuck ll lf lr out) '-' = Brainfuck ll (lf - 1) lr out
brainfuck (Brainfuck ll lf lr out) '.' = Brainfuck ll lf lr (out ++ [chr lf])
brainfuck bf _ = bf

eval :: String -> Brainfuck -> Brainfuck
eval [] bf = bf
eval (x:xs) bf = eval xs $ brainfuck bf x

main = do
    args <- getArgs
    print $ out $ eval (args !! 0) $ Brainfuck [] 0 [] ""

A bit longer, but referentially transparent. Just whipped it up in 5 minutes, I'm sure it can be made shorter.

Anyways, LOC for a simple brainfuck interpreter doesn't say anything meaningful about a language.