(Caveat: I have never seen *any* Clojure presentations, even on Youtube.) (1) Others may disagree, but ... although I love Lisps, think that purely functional programming is cool, and have come to see that there are situations in which FP is *great*, I am not someone who thinks that FP is always clearer (easier to understand) or as clear as imperative programming. For some jobs, one can be be made clearer than the other. Maybe, in addition to providing examples in which FP is clearer, you would want to provide an example in which it's less clear. Since so many people go around promoting the latest, greatest thing that will solve all of your programming problems, it might build trust to show that you understand that there are tradeoffs.
(2) The REPL. Show how easy it is to stop your program and inspect data structures, or to try out a new function with different arguments, or to chain some functions together in an experimental way. (3) pmap. I had a program that was mapping a function over a sequence of data structures to produce the next sequence of data structures. Then I added "p" to two instances of "map", and got a 2-4X speedup. It would have been more if I'd had more cores. Then I rearranged the code a little bit so that I only needed one map or pmap call, and got a little more speed. Occasionally, during debugging, I replace pmap with map so that I can see the sequence. Easy peasy. Multiprocessing in Clojure isn't always that easy, but I'd guess that it's it's never that easy in other popular languages. (4) Discussions of the advantages of FP often neglect to mention that it can foster modularity. I wrote a program in Common Lisp that had a main loop which repeatedly updated the state of data structures. I need various sorts of output from each iteration of the loop, but I didn't need any one kind of output all of the time. So I embedded calls to output functions wrapped in 'if' statements at various places in the loop. Messy. When I rewrote the program in Clojure, I made the loop into a lazy sequence using 'iterate'. When I want output, I "embed" it in the sequence by mapping one or another function over the sequence produced by 'iterate'. The "main loop", i.e. the function that 'iterate' calls, is free of any output functions, so it's simpler, and I can add or combine output functions as needed by mapping them over the lazy sequence--or not, as needed. (Of course I have to be careful since I'm mixing laziness and side effects, but in this particular case it's easy to avoid problems.) (5) Which reminds me: Going back to point (1) about building trust, maybe it's worth mentioning that you will need side effects some time, and Clojure is going to make you mix it with laziness simply because so many of the useful functions generate lazy sequences. This can be a pain, and *will* generate annoying bugs, at least at first. But as with any programming style, you have to develop good practices in order to avoid gotchas. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
