in reply to Re^9: Thread on Joel on software forum : "I hate Perl programmers."
in thread Thread on Joel on software forum : "I hate Perl programmers."

Well you can do a pretty decent job of functional programming in Perl. The main concepts are trying to avoid side effects, and using higher order functions (like map and grep) when appropriate. I'm not sure what you mean by 2D syntax, but I'll give it a stab using Haskell (since I've noticed you've mentioned it before). Every FP tutorial on the planet must use the factorial function to demonstrate the features of the language, this one is no exception. Here's the easy definition...
fac n = product [1..n]
Haskell syntax for defining functions is very lightweight. No "sub" keyword or curley braces necessary. The lone '=' sign is what gives away that this is a function definition. The above code creates a function called "fac" of one argument (called "n"). The product function takes a list and multiplies each element together. Brackets are used to create lists, and the ".." operator is somewhat similar to perl's. So the factorial is the product of the numbers from 1 to n. Here's a recursive version...
fac n = if n<1 then 1 else n * (fac (n-1))
"if" is a function in Haskell (like most things), very similar to the ternary ? operator in Perl. As for 2D syntax, maybe you're refering to pattern matching? (like multi-methods in Perl6)...
fac 0 = 1 fac n = n * fac (n-1)
This merely means that if you call fac with an argument of 0, the answer is one, anything else compute n*fac(n-1). Haskell also has pattern gaurds. The pipe ('|') symbol introduces a set of alternatives to check on each invocation of the "fac" function. If it finds one of the conditions evaluates to true, then it returns the value of that alternative ("otherwise" is equal to "true")...
fac n | n == 0 = 1 | otherwise = n * (fac (n-1))
In perl, it would look something like...
sub fac { $n = shift; if($n==0) { return 1; } else #otherwise { return $n*fac($n-1); } }

Replies are listed 'Best First'.
Re^11: World's shortest intro to function programming
by BrowserUk (Patriarch) on Jun 18, 2005 at 02:23 UTC

    Yeah! I get all that no problem, but that is as useful in understanding how to program in FP as HelloWorld.(c|pl|etc.) is in teaching you how to program in an imperative language--basically nil.

    FP is far more than the use of high order functions and functional composition and recursion, which can be crudely approximated by:

    P:\test>p1 perl> sub prompt { printf "What's your name?: "; } sub getAnswer{ chomp( $_ =<STDIN> ); return $_; } sub greetings{ print "Hello $_[ 0 ]. Welcome to functional programming +!\n" } sub main { prompt , greetings getAnswer };; perl> main;; What's your name?: BrowserUk Hello BrowserUk. Welcome to functional programming!

    The real essence and subtlety of FP is the typing system, but there is a dearth of documentation on this that isn't couched in complex theoretical explainations and references to research papers that you need a subscription to download, in pdf form (which I hate vehmently because the Adobe reader and GhostSscript UI's are so crap). And when you do download them, you need a greater-than-grad-level-degree of understanding of math notation to even begin to understand. I didn't do math at that level.

    Example:

    And didn't that translation at the bottom really clarify everything!


    Even the gentlest of the tutorials splits it time between

  • Saying the same things in the same way, but repetatively and slowly (like an Englishman speaking to a "foreigner" :).
  • Propagandising the benefits and dogmas of FP. Even the "Haskell tutorial for C programmers" somehow falls into the trap of justifying FP, rather simply explaining how to use it (well).
  • Uses syntax in the examples that you can't simply type into the "runloop interfaces" without modifying it.

    A picture (demo) is worth a thousand words (and 1000 trivial examples). My biggest single problem with all the "tutorial" material for FP languages, (and I think that I have read/scanned/attempted to follow all the commonly available ones for Haskell, Ocaml and Oz over the last few months), is the total absence of a fully worked, practical example. Something that starts with a real world practical problem, including all the "messy stuff" like IO, retained state (even better if a little FFI and concurrency was thrown in), and then takes you through the development process step-by-step without all the propaganda.

    What I mean by "2D syntax" the Python-style required whitespace--2d alignment rules. The FP guys appear to think this is elegant, and I guess it is compared to Lispish, but the always-moving-right, "hanging indents" formatting, looks anything but elegant or even structured to my eyes.

    Examples:

    Lisp

    defun generate-tree (phrase) "Generate a random sentence or phrase, with a complete parse tree." (cond ((listp phrase) (mapcar #'generate-tree phrase)) ((rewrites phrase) (cons phrase (generate-tree (random-elt (rewrites phrase))))) (t (list phrase))))

    Haskell:

    take m ys = case (m,ys) of (0,_) -> [] (_,[]) -> [] (n,x:xs) -> x : take (n-1) xs

    Ocaml:

    #let rec member x btree = match btree with Empty -> false | Node(y, left, right) -> if x = y then true else if x < y then member x left else member x right;; val member : 'a -> 'a btree -> bool = <fun>   #let rec insert x btree = match btree with Empty -> Node(x, Empty, Empty) | Node(y, left, right) -> if x <= y then Node(y, insert x left, right) else Node(y, left, insert x right);; val insert : 'a -> 'a btree -> 'a btree = <fun>

    And what is 'a? Where did that come from? "a" seems to be a "generic type placeholder" generated by the type inferencing, but what is the ' doing? Is it a function that tests the value of the type represented by the "a"?

    I (vaguely) recall that in math, ' is often used to indicate the derivitive of a term or expression, but in that case it is usually used postfix, not prefix as here.

    This sort of stuff pops up early and ubiquitously throughout the tutorials without any explaination. I think I tracked it down that ' is just-another-character used to create identifiers, like "_" in perl or C, but why is it used/generated here?

    The Haskell tuts never explain what '$' does that I have found, but if you look at any non-trivial Haskell code, it pops up all over the place. (I know what it does now through trial and error!).

    And '.'. This is explained, usually as f . g x = f( g( x )) or f . g x = (f (g x ) ) depending upon flavour, but what that doesn't tell you is when you need to use it! In most dialecs, simple abutment of functions f g x achieves the same thing--except when it doesn't and the '.' is required!

    Enough ranting, (sorry you caught me after another fruitless search for information and examples, and several long and ultimately useless downloads of PDFs that I had to search manually because the stupid UI won't let me search for stuff that wasn't bloody indexed. Grrr!).

    For now, I'm making best progress with Oz which has a more traditional syntax and some very nice concurrency features--despite it coming with a emacs interace (Nice OS, shame about the editor!).

    I think Ocaml will (eventually) be my favorite, despite all the same charges applying, because of it's balance of FP, imperative and OO features and very efficient standalone programs. Just a shame about the aweful windows runloop interface.

    I'd like to like Haskell with it's purity and laziness and monads and generics and FFI, but doing anything useful in it seems to be much harder to start with.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
      The real essence and subtlety of FP is the typing system
      Ah, ha. Now we're getting somewhere. I could definitely see where one could go astray, if they start following the reasearch guys too closely. They *love* proposing new additions to the type system to see what results (that's their job after all). Here's where I'll heartily recommend the book The Haskell School of Expression: Learning Functional Programming through Multimedia. I found I needed an actual text to use in my journey into FP. While PDF's might be good enough to learn a new language if it is sufficiently close to one I already knew, I found learning FP from PDF's to be mostly unworkable. "The School of Expression" book covers the Haskell-98 standard, which ignores the bleeding edge type system extensions (this is a good thing). Also, as a side note, I'm obligated to mention that while static typing might be used in the more popular FP languages like Haskell and OCaml, it is by no means the essence of FP. You can do FP in Scheme and Perl if you so desire (I'll also mention my new favorite untyped functional language,Joy, although it is pretty much completely impractical at the moment).
      Uses syntax in the examples that you can't simply type into the "runloop interfaces" without modifying it.
      The Haskell interpreter prompt is inside an implicit "do" block (which is what sequences IO actions in a lazy language like Haskell). I could see where that could be confusing. What that basically means is that you have to use the 'let' keyword to introduce a new definition. (Not to be confused with "let .. in" construct you use in regular code).
      What I mean by "2D syntax" the Python-style required whitespace--2d alignment rules.
      That's probably just one of those "matters-of-taste" things. Some folks like curley braces, others don't.
      And what is 'a? Where did that come from? "a" seems to be a "generic type placeholder" generated by the type inferencing, but what is the ' doing? Is it a function that tests the value of the type represented by the "a"?
      I know nothing about Ocaml, but I'll take a stab at it anyway. In Haskell, there's nothing too special about the single quote, so you can use them as part of your variable names. When used that way, it is pronounced "prime". Also in Haskell, use of lower case names in a type signature indicate a type variable (the type signature shows what the types of the arguments and return value are for a function). A type variable can represent any type, as opposed to a specific type instance like Integer, Float, String, etc. (note the capitalization). For example, the type of "map" is...
      map :: (a -> b) -> [a] -> [b]
      ...which means that "map" takes two arguments (ignore currying for now). The first argument (a -> b) is a function which takes elements of type "a" and returns elements of type "b". The second argument ([a]) that "map" takes is a list of elements of type "a". And the return type is a list of elements of type "b". For instance, if...
      strlen :: String -> Integer strlen x = length x example = ["dog", "cat", "orange"]
      ...then "map strlen example" would evaluate to the list [3,3,6].
      The Haskell tuts never explain what '$' does that I have found, but if you look at any non-trivial Haskell code, it pops up all over the place. (I know what it does now through trial and error!).
      Yup. That's a legitimate complaint. The '$' application function is under explained and mainly used to eliminate parenthesis.
      And '.'. This is explained, usually as f . g x = f( g( x )) or f . g x = (f (g x ) ) depending upon flavour, but what that doesn't tell you is when you need to use it! In most dialecs, simple abutment of functions f g x achieves the same thing--except when it doesn't and the '.' is required!
      Yeah, function application precedence was a little tricky for me at first in Haskell (and curried everything doesn't make it easier), but you'll get the hang of it with a little practice.
      Enough ranting, (sorry you caught me after another fruitless search for information and examples, and several long and ultimately useless downloads of PDFs that I had to search manually because the stupid UI won't let me search for stuff that wasn't bloody indexed. Grrr!).
      No problem! Ranting is par for the course when undertaking any new exercise. Hang in there, it'll get easier the more you do.
        Here's where I'll heartily recommend the book The Haskell School of Expression: Learning Functional Programming through Multimedia

        Well. As an interim measure I read the lecture slides. From that cursory glance--that actually went at about the right pace (4 or 5 slides representing a few 10s of pages)--it does at least appear to attempt to deal with (what I term) real-world problems.

        However, and here's the reason I will want to browse the book before purchasing rather buying on line, it (appears) to skips the nasty little details.

        For example, the treatment of the trivial, but strongly indicative example of the unix wc program. (Which I had to type in because it doesn't come as part of the source file distribution with the book)

        import System wcf :: ( Int, Int, Int ) -> String -> ( Int, Int, Int ) wcf ( cc, w, lc ) [] = ( cc, w, lc ) wcf ( cc, w, lc ) ( ' ' : xs ) = wcf( cc+1, w+1, lc ) + xs wcf ( cc, w, lc ) ( '\t' : xs ) = wcf( cc+1, w+1, lc ) + xs wcf ( cc, w, lc ) ( '\n' : xs ) = wcf( cc+1, w+1, lc+1 ) + xs wcf ( cc, w, lc ) ( x : xs ) = wcf( cc+1, w, lc ) + xs wc :: IO() wc = do name <- getLine contents <- readFile name let ( cc, w, lc ) = wcf( 0, 0, 0 ) contents putStrLn ( "The file:" ++ name ++ " has " ) putStrLn ( show cc ++ " chars " ) putStrLn ( show w ++ " words " ) putStrLn ( show lc ++ " lines." )

        Compiling and running that fails because it has no main. Okay, it's off a slide, so add  main = wc. Compile and I get a (500kb!) executable. Try running it--on a file with 2 lines of 30 spaces:

        C:\ghc\test>wc 60sp2l.txt wc: interrupted C:\ghc\test>wc 60sp2l.txt The file:60sp2l.txt has 62 chars 62 words 2 lines. C:\ghc\test>wc p:\test\1GB.dat The file:p:\test\1GB.dat has Heap exhausted; Current maximum heap size is 268435456 bytes (256 Mb); use `+RTS -M<size>' to increase it.

        Impressed? Not! Doesn't handle command line parameters. No prompt. Counts spaces and newlines as words. Can't handle a big file.

        Yes. I know it's only a demo. I should be able to add a prompt easily enough:

        wcf :: ( Int, Int, Int ) -> String -> ( Int, Int, Int ) wcf ( cc, w, lc ) [] = ( cc, w, lc ) wcf ( cc, w, lc ) ( ' ' : xs ) = wcf( cc+1, w+1, lc ) x +s wcf ( cc, w, lc ) ( '\t' : xs ) = wcf( cc+1, w+1, lc ) x +s wcf ( cc, w, lc ) ( '\n' : xs ) = wcf( cc+1, w+1, lc+1 ) x +s wcf ( cc, w, lc ) ( x : xs ) = wcf( cc+1, w, lc +) xs wc :: IO() wc = do putStr ( "Filename; " ) name <- getLine contents <- readFile name let ( cc, w, lc ) = wcf( 0, 0, 0 ) contents putStrLn ( "The file:" ++ name ++ " has " ) putStrLn ( show cc ++ " chars " ) putStrLn ( show w ++ " words " ) putStrLn ( show lc ++ " lines." ) main = wc

        Compile:

        C:\ghc\test>ghc -o wc.exe wc.hs wc.hs:9:8: Parse error in pattern

        Hmmm. Informative!

        So, skip the prompt, and try and get the argument from the command line. Scan the library docs. System looks promising. But there is nothing that looks like it gives me access to the commmand line? Okay, skip that. Try dealing with the "words are spaces" problem. In an imperative language I'd simple 'remember' the previous character and treat consecutive spaces (and newlines) as a single delimiter for the purpose of counting words...but of course, that's state!

        So, how about dealing with the memory issue? I thought the beauty of Haskell was that it was non-strict or lazy. That it dealt with infinite lists. Then why does getContents insist on loading the whole darn file?

        Another example drawn from the same source.

        From Chapter 8, containsS for Rectangles is defined as:

        Rectangle s1 s2 `containsS` (x,y) = let t1 = s1 / 2 t2 = s2 / 2 in -t1<=x && x<=t1 && -t2<=y && t2<=t2

        But there is a classical GUI problem here. If you divide the screen into a grid, of say 10 x 10 pixels, then by the above definition any point on the right edge of one rectangle also appears on the left edge of the adjacent rectangle to its right. Likewise for points on the other three edges and their corresponding neighbours. This leaves a point at the crossroads between 4 adjacent squares testing as being contained within all four squares simultaneously! Might work for a Corner bet in roulette, but it surely doesn't work well for the majority of hit-testing purposes in graphical applications.

        And that's the problem. All the demos are the same. They concentrate on (laborious formal) examination of Haskell's strengths and completely skip over all the messy edge cases.

        All languages have their strengths and weaknesses. What defines a languages usability is the way in which it deals with it's weaknesses. What puts the P in Perl, is the practical way in which it has built-in mechanisms for dealing with the messiness of the real world--the edge cases--even where that means it has to eshew orthoganality and purity in order to achieve that practicality. Where the same problem in usability crops up frequently, the language has been extended and "special cased" to deal with that situation in a reasonable and usually quite intuative way. And the special cases are the subject of extensive documentation in the FAQ.

        My problem with trying to get to grips with FP is that the FP language documentation reflects their theoretical origins by expounding on the formalism of their definitions extensively, but (from what I've seen so far) leaving the messy detail of dealing with the edge cases to .... I don't know yet. I haven't found the answer.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.