So, I am working thru the "programming clojure" book. My first lisp language.<p>I have been finding it very difficult to implement simple problems. I have become familiar with the syntax (got over the = operator typing every other place from my finger memory). While I am comfortable, I feel like I know few keywords without knowing where to use, akin to learning a new language - saying hi, bye, but unable to form a sentence. That is my ponder stop..almost pushes me into procrastination mode<p>How do I <i>Think</i> in Functional. I catch myself thinking oops(i think of classes,methods..)and i correct myself and end up with something procedural like.<p>With ref to Uncle Bob's link below , how do I think "inside out"?<p>II) instead of having another question, I thought of asking it as a sub question from the same link below - TDD in clojure. for one, I don't see a mock object ever created in clojure...please correct me.<p>I was wondering how to do "TDD" in LISPy languages.<p>http://blog.objectmentor.com/articles/2009/07/19/uncle-bob-jsps-learning-clojure
I think most functional programmers don't use TDD. Instead, they write little functions (and macros) that do useful things and approach the problem bottom up, constantly trying things out on the REPL and rewriting the code they have already written.<p>This way of programming seems incompatible with TDD and I would recommend practicing it in order to start thinking functional.<p>Paul Graham talks about it here:<p><a href="http://www.paulgraham.com/progbot.html" rel="nofollow">http://www.paulgraham.com/progbot.html</a><p>I don't program in Lisp or any other functional language, but I use this style a lot programming in Python and code ends up being pretty functional.
I second the call to SICP; it is, admittedly, <i>very</i> hard to deal with not using recursion after reading the first few chapters, but even outside of that, it will change the way you program.<p>Reading SICP is like taking a freezing shower; it's a bit of a shock at first, but afterward everything is crisp and clear. Colors are brighter and love is lovelier after you read SICP.<p>Ok, maybe it's not gold-and-bunnies good, but it's pretty good, and should help remove your cognitive stumbling block.
I think I'd normally say "read SICP" but Clojure discourages recursion in favor of it's looping constructs (due to the non-ability to optimize it on the JVM I'm guessing).<p>That said, SICP will still teach you to think in terms of HOFs and functions as abstractions, so it'll definitely help out. And it's free online, so the only investment is time.
I'm kind of in the same boat. There are plenty of resources for learning Clojure, but I haven't found any that help with the transition from object oriented programming to functional programming. I read <i>Programming Clojure</i> and I feel like I know the language, but I'm still working on thinking in terms of functional programming. Interestingly, <i>Programming in Scala</i> has helped some. The hybrid functional/object oriented approach has helped introduce functional concepts with a language that doesn't seem so foreign. It can be difficult to pick up a completely different language (different from C-like languages, anyway) as well as a new programming model at the same time. <i>JavaScript: The Good Parts</i> is also good for the same reason.<p>There's also an F#/C# book scheduled to come out later this year that looks like it might be good for learning the functional thought process: <a href="http://www.amazon.com/Functional-Programming-Real-World-Examples/dp/1933988924/ref=sr_1_2?ie=UTF8&s=books&qid=1248098702&sr=8-2" rel="nofollow">http://www.amazon.com/Functional-Programming-Real-World-Exam...</a><p>I found this blog post from Stuart Halloway to be informative as well: <a href="http://blog.thinkrelevance.com/2008/9/25/pcl-clojure-chapter-17" rel="nofollow">http://blog.thinkrelevance.com/2008/9/25/pcl-clojure-chapter...</a>
The Mock objects in TDD are there so that after a test you can check that the code under test caused side-effects in dependant objects. (At least, most of the time this is why they exist.)<p>Functional programming is very much about decoupling "pure functional" computation and side-effects. Using pattern matching you can quite easily write a little machine that performs side-effects given different values. These things are simple and about as useful to unit-test as accessor methods are in oo code. Static typing checks do fine. Also, if it is broken, it tends to be severly broken and not lead to undetected or hard-to-find bugs but simply not work at all.<p>The interesting code to test is that which is given a bunch of parameters and returns a value that would instruct the side-effectful machine about what to do. This function can be tested with lots of inputs, and you check that it gives the correct instructions (without executing them).<p>This style of programming exists in OO as well.<p>Another reason to use Mocks is that they are queried for values that one need control over to rig the unit test. I.e. just a disguised parameters. FP simply doesnt do that.
Some generic advice:<p>1. Read lots of clojure code. There is clojure-contrib which has lots of little libraries, read through them and see how things are done.<p>2. I will second the SICP suggestion, atleast the first few chapters. Bottom up programming, building layers of abstraction, is a natural way of doing things in the lisp world.<p>3. The REPL is your friend. Having a really good working environment is crucial to initial learning as well as later development. I would strongly recommend taking the time to set up one of the clojure working environments(Slime/VimClojure/Enclojure) as a first thing, if you have not already done so.<p>4. It takes a while, but it gets easier. Keep at it.
You should be careful you're looking for something that doesn't exist. That keeps you wondering why you don't find it forever. Perhaps you already have the hang of it, but the purists are getting you down, making you think you don't get it. In practice, there is no such thing as purely functional code, just like there is no such thing as purely object oriented code. If you succeed at avoiding state/mutability and side effects and end up with (less) code that you think is easier to understand, then you are simply doing a good job.
a couple things that i have seen help get into a more functional state of mind:<p>make everything you can immutable. find a problem where you can build most of it without changing 'the state of the world'. function takes data, spits out answer which is feed into the next.<p>refactor commonalities from part 1 by passing around functions, closures, etc etc. all your good functional fun toys.<p>add your mutable core around the outside.
Little Schemer, then SICP. For sure. As for TDD, take a look at SchemeUnit, which I've found very handy in testing the exercises in Little Schemer.<p>SICP is one of the single most valuable and important texts in CS. Little Schemer is structured as a real training regimen to get your mental muscles ready to handle that theory.
Use clojure.test for TDD. There's a bit of documentation here:<p><a href="http://java.ociweb.com/mark/clojure/article.html#Testing" rel="nofollow">http://java.ociweb.com/mark/clojure/article.html#Testing</a>
Learn how to implement integers, booleans, pairs, tuples, lists, and trees in lambda calculus (and, more specifically, System F)... and you will be able to think functionally.