On Mon, Mar 25, 2013 at 4:13 AM, Richard A. O'Keefe
It's "Backus", people. He was never the god of wine.
I cannot detect any trace of Backus's FP in Haskell at all. FP is strict. Haskell is not. FP is typeless. Haskell is highly typeful. FP does not name formal parameters. Haskell often does. FP has roots in APL. Haskell doesn't.
I don't see any trace of Backus's FP in ML, Clean, or F# either.
The idea of writing programs by composing lots of small functions is common to them both, but the idea of combinators preceded them both.
I really wonder about this whole discussion -- not the details… the perspective. Its like saying the Ford T http://1.bp.blogspot.com/-KGhxacA_p1k/TV0g_qeHOFI/AAAAAAAACF8/5t8NRxpzUCo/s1... is an unsafe car http://1.bp.blogspot.com/-7gEOpb7-9IU/TV0g-88-dZI/AAAAAAAACF0/u3dh8CXAAGI/s1... and should be equipped with airbags. To the OP: I believe that FP has much to contribute to programming, whether you identify yourself as an FPer or not. - Not the fancy type hackery of modern haskell - Not the math hackery of Backus Just basic stuff like http://blog.languager.org/2012/10/functional-programming-lost-booty.html [Sorry its only an outline and is skimpy] For the most part I agree with the foll -- except the type-classes.
As for "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" the idea is that this ought to be *easier* to understand than an imperative loop because all of the parts are separated out instead of being graunched up together.
inner_product :: Num a => ([a],[a]) -> a
inner_product = foldr1 (+) . map (uncurry (*)) . uncurry zip
_is_ expressible in Haskell, although
inner_product :: Num a => [a] -> [a] -> a
inner_product = sum . zipWith (*)
would be more idiomatic.
Personal note: I recently taught a course in Erlang and I did what Ive done for 25 years -- start with FP. In the past its always more or less worked well - in 1988 it was scheme - in 1992 it was gofer, the predecessor of haskell - in 2001 it was scheme. This time I used haskell and the results were not so good, primarily because of typeclasses