6 ms·

Looks like a good overview of Clojure and functional programming. Anyone have a review?

whichdan 14y ago
I would be interested in a review as well. Coming from an OO background, I've been looking for books/articles that focus more on "here's how you'd do that using functional programming" instead of just exercises going over syntax.
- verroq 14y ago
  If anything, functional programming gives you too many ways to achieve the same thing. How many ways can a reasonable programmer write the factorial function imperatively (without using the closed form formula or any dynamic programming). A maximum of two. A for loop or use recursion. But just look at how many ways you could write factorial in a functional programming language. http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html It is truly unfortunate when your ability to program functionally is directly proportional to how much of the standard library you have memorised. This makes functional programming much harder to learn. edit: I don't really care if you downvote. I come here discuss programming.
  - glassx 14y ago
    > How many ways can a reasonable programmer write the factorial function imperatively This page is a terrible example. Most of these are not not what a "reasonable programmer" would do. An unreasonable programmer would be able to screw up on any paradigm. You'd probably have even more ways to screw up like this with an OO language, creating classes for recursive functions, trampolines, a pattern matching class, implement an language interpreter inside your factorial implementation, etc.
    - verroq 14y ago
      > You'd probably have even more ways to screw up like this with an OO language My example was about imperative languages. You assertion on how many ways one could screw up on OO is irrelevant and besides, you'd really need a good understanding of OO to even try implementing those. I didn't mean to use to imply any of those methods were bad. I have revised my post so people can't miss the point. That is > It is unfortunate when your ability to program functionally is directly proportional to how much of the standard library you have memorised. This makes functional programming much harder to learn. Now, addressing your concerns. > This page is a terrible example. Most of these are not not what a "reasonable programmer" would do. All of the examples except for few particularly egregious ones seems reasonable to me. For example -- one, need n+k patterns but so what fac 0 = 1 fac (n+1) = (n+1) * fac n -- two fac 0 = 1 fac n = n * fac (n-1) -- three fac n = foldl (*) 1 [1..n] -- four facs = scanl (*) 1 [1..] fac n = facs !! n -- five fac = foldr (*) 1 . enumFromTo 1 -- six fac n = product [1..n] Six fairly distinctive ways. I'm sure there's more that's as elegant if not more elegant ways to do the same thing.
      - deleted 14y ago
        [deleted]
      - jwdunne 14y ago
        After the first 2, the rest are based on common and very useful abstractions. You could translate those to an OO language quite easily too, though with a lot more code. For example, what foldl does, from my understanding, is to recursively apply a function to both a starting value and the first element of a list, and then the same thing again, where the result from the last call becomes the starting value and the rest of the list becomes the list we're working on, up until the list is empty. Not sure if I've explained this well but I've not been into this long. If you see the second function, that's what it's doing, except it's working just with numbers and not a list. Since foldl works on lists, you need an enumerator, which in this case is just 1 through to n. The sixth example is great here. Product could easily be an abstraction on something quite similar to three, which itself could very well be an abstraction quite similar to two (using lists, functions to deal with lists and a given function). Please correct me if I'm wrong at any point here. I'm looking to improve these skills quite a lot so it'd be very, very welcome.
  - viscanti 14y ago
    This list is a joke, based on a similar list for imperative programmers writing a "hello world" program. There are certainly a number of ways to write write something in either paradigm. The number of ways you can write something is a horrible metric to evaluate languages on. Any sufficiently clever programmer can come up with a number of bad solutions. The useful imperative techniques are more obvious to you because you have more experience with that framework. Experienced functional programmers would just as quickly narrow their list of useful solutions. In order to be productive in a functional style, you don't need to know much of the language's standard library. You simply write small functions that can be applied in a number of areas. You'll probably end up re-inventing the wheel though, as most functional languages come with most of the essential functional constructs included in the standard library. If anything, functional programming is more beginner friendly, because you don't end up dealing with mutable state and you can easily work on the level of abstraction that you're most comfortable with (you're just composing ever more advanced functions from simpler ones).
  - ufo 14y ago
    BTW, since we are takling a bout Haskell, an interesting thing I noticed about it is that precisely I don`t need to memorize the whole standard library. Whenever I have a though like "man, I whished that there was a function that gor me a Bar from this list of Foos" I can just pass the "[Foo] -> Bar" type to Hoogle[1] and it will magically find the name of all the functions in the standard libraries that have compatible or similar type signatures. [1] http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/
- andrewcooke 14y ago
  i always thought that sicp (the book here http://mitpress.mit.edu/sicp/ http://mitpress.mit.edu/sicp/) was a pretty good intro to fp for oo people. in particular, chapter 3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html#%_chap_3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html... shows the similarity between closures and objects, which (apart from just generally become familiar with the ideas in fp) is the main "aha" in bridging between the two. having said that, in my experience (perhaps i am just dumb, or old) fp takes a while to get used to. i first looked at haskell some 16 years ago (i can still remember reading the intro while staying in a b+b in edinburgh), before using sml and ocaml, but the first time it really felt natural to me was with clojure this year. i don't think that's much to do with clojure - it just took multiple attempts before things really stuck. perhaps the biggest help was python's slow drift (despite gvr) towards fp idioms.

I would be interested in a review as well. Coming from an OO background, I've been looking for books/articles that focus more on "here's how you'd do that using functional programming" instead of just exercises going over syntax.

verroq 14y ago
If anything, functional programming gives you too many ways to achieve the same thing. How many ways can a reasonable programmer write the factorial function imperatively (without using the closed form formula or any dynamic programming). A maximum of two. A for loop or use recursion. But just look at how many ways you could write factorial in a functional programming language. http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html It is truly unfortunate when your ability to program functionally is directly proportional to how much of the standard library you have memorised. This makes functional programming much harder to learn. edit: I don't really care if you downvote. I come here discuss programming.
- glassx 14y ago
  > How many ways can a reasonable programmer write the factorial function imperatively This page is a terrible example. Most of these are not not what a "reasonable programmer" would do. An unreasonable programmer would be able to screw up on any paradigm. You'd probably have even more ways to screw up like this with an OO language, creating classes for recursive functions, trampolines, a pattern matching class, implement an language interpreter inside your factorial implementation, etc.
  - verroq 14y ago
    > You'd probably have even more ways to screw up like this with an OO language My example was about imperative languages. You assertion on how many ways one could screw up on OO is irrelevant and besides, you'd really need a good understanding of OO to even try implementing those. I didn't mean to use to imply any of those methods were bad. I have revised my post so people can't miss the point. That is > It is unfortunate when your ability to program functionally is directly proportional to how much of the standard library you have memorised. This makes functional programming much harder to learn. Now, addressing your concerns. > This page is a terrible example. Most of these are not not what a "reasonable programmer" would do. All of the examples except for few particularly egregious ones seems reasonable to me. For example -- one, need n+k patterns but so what fac 0 = 1 fac (n+1) = (n+1) * fac n -- two fac 0 = 1 fac n = n * fac (n-1) -- three fac n = foldl (*) 1 [1..n] -- four facs = scanl (*) 1 [1..] fac n = facs !! n -- five fac = foldr (*) 1 . enumFromTo 1 -- six fac n = product [1..n] Six fairly distinctive ways. I'm sure there's more that's as elegant if not more elegant ways to do the same thing.
    - deleted 14y ago
      [deleted]
    - jwdunne 14y ago
      After the first 2, the rest are based on common and very useful abstractions. You could translate those to an OO language quite easily too, though with a lot more code. For example, what foldl does, from my understanding, is to recursively apply a function to both a starting value and the first element of a list, and then the same thing again, where the result from the last call becomes the starting value and the rest of the list becomes the list we're working on, up until the list is empty. Not sure if I've explained this well but I've not been into this long. If you see the second function, that's what it's doing, except it's working just with numbers and not a list. Since foldl works on lists, you need an enumerator, which in this case is just 1 through to n. The sixth example is great here. Product could easily be an abstraction on something quite similar to three, which itself could very well be an abstraction quite similar to two (using lists, functions to deal with lists and a given function). Please correct me if I'm wrong at any point here. I'm looking to improve these skills quite a lot so it'd be very, very welcome.
- viscanti 14y ago
  This list is a joke, based on a similar list for imperative programmers writing a "hello world" program. There are certainly a number of ways to write write something in either paradigm. The number of ways you can write something is a horrible metric to evaluate languages on. Any sufficiently clever programmer can come up with a number of bad solutions. The useful imperative techniques are more obvious to you because you have more experience with that framework. Experienced functional programmers would just as quickly narrow their list of useful solutions. In order to be productive in a functional style, you don't need to know much of the language's standard library. You simply write small functions that can be applied in a number of areas. You'll probably end up re-inventing the wheel though, as most functional languages come with most of the essential functional constructs included in the standard library. If anything, functional programming is more beginner friendly, because you don't end up dealing with mutable state and you can easily work on the level of abstraction that you're most comfortable with (you're just composing ever more advanced functions from simpler ones).
- ufo 14y ago
  BTW, since we are takling a bout Haskell, an interesting thing I noticed about it is that precisely I don`t need to memorize the whole standard library. Whenever I have a though like "man, I whished that there was a function that gor me a Bar from this list of Foos" I can just pass the "[Foo] -> Bar" type to Hoogle[1] and it will magically find the name of all the functions in the standard libraries that have compatible or similar type signatures. [1] http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/
andrewcooke 14y ago
i always thought that sicp (the book here http://mitpress.mit.edu/sicp/ http://mitpress.mit.edu/sicp/) was a pretty good intro to fp for oo people. in particular, chapter 3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html#%_chap_3 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html... shows the similarity between closures and objects, which (apart from just generally become familiar with the ideas in fp) is the main "aha" in bridging between the two. having said that, in my experience (perhaps i am just dumb, or old) fp takes a while to get used to. i first looked at haskell some 16 years ago (i can still remember reading the intro while staying in a b+b in edinburgh), before using sml and ocaml, but the first time it really felt natural to me was with clojure this year. i don't think that's much to do with clojure - it just took multiple attempts before things really stuck. perhaps the biggest help was python's slow drift (despite gvr) towards fp idioms.