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 ]
to this fairly typical seeming example of quicksort implemented in Java:
http://www.augustana.ab.ca/~mohrj/courses/2004.winter/csc310/source/QuickSort.java.html
Once you read up on the fundamentals of haskell you realize (I did,
anyway) that the haskell code expresses the idea that you have a pivot
point and you put everything greater than the pivot on one side and
everything less than the pivot on the other side...and then you do it
again. Until you have the whole list sorted. The java code seems to
offer more places to screw up, more loops, and more head scratching
while we figure out all of the manual incrementing and decrementing that
goes on.
A politically interesting aspect of purely functional programming: Since
it is actual math that we are specifying here some people have
implemented algorithms which are protected by some sort of
patent/copyright/whatever in a purely functional language and
distributed it on the basis that you cannot apply any of these methods
of protection to math. I can't wait to see how that fairs in court some day.
--
Tracy R Reed Read my blog at http://ultraviolet.org
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
