On 6/27/07, Tracy R Reed <[EMAIL PROTECTED]> wrote:
I've been reading: http://www.amazon.com/Haskell-Craft-Functional-Programming-2nd/dp/0201342758/ref=pd_bbs_sr_4/002-2734458-9768026?ie=UTF8&s=books&qid=1182930851&sr=8-4 And learning some interesting things and really starting to get my head around purely functional programming. One of the things that attracts me to this style is the succinctness and the idea of specifying the mathematical formula which describes *what* you want done and not so much the implementation of the algorithm which describes *how* to do it. A neat example is to compare quicksort in haskell: quicksort :: (Ord a) => [a] -> [a] quicksort [] = [] quicksort (p:xs) = quicksort [ x | x <- xs, x <= p ] ++ [ p ] ++ quicksort [ x | x <- xs, x > p ]
I haven't digested the other thread on functional languages yet, but when I investigated functional programming on my own last year, I was really impressed with the quicksort algorithm. It's like you're really looking at the algorithm itself. Then I was disappointed to learn that even in modern implementations of functional programming it runs significantly slower. I *think* it's about 2 X slower in Haskell than in Java, but my memory is fading. The other impression I came away with was that people who were touting how much faster Haskell and friends had become over the years were framing the current performance against older versions--not against current imperative languages (Java, C#, C++). Tracy, do you have any specific numbers on speed of execution, or a URL? Many of the most interesting areas of computing (to me) are evolutionary computation, artificial intelligence and simulation. All of these feel the need for speed. -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
