1. What is the justification for using a map as a function? I find this to be very confusing.
In math, a function is a mapping from one set to another, so from that perspective it makes good sense for a clojure-map to be a function from its set of keys to its set of values. The justification here is mathematical convention. Same thing with vectors being functions. 2. In practice, I find myself wincing when needing to decide whether or not to type an open-paren. Is that a common thing? Normally this isn't a problem for me because I always look at the bottom of my emacs window and am able to see the arguments whatever function I'm working with requires. 3. Is there a compendium of recursive idioms, ideally expressed in clojure? Including indentation conventions! (Is there an opportunity for a python inspired pre-processor that interprets indentation as parens?) You might try SICP (http://mitpress.mit.edu/sicp/) because Professor Sussman is awesome. Also try the clojure cookbook (http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Cookbook) 4. Why don't long-running clojure programs monotonically increase in heap usage if all data-structures are immutable? If every reference to an immutable structure disappears than that structure can be garbage collected. Therefore, loops that create intermittent structures aren't that much of a memory hog since java garbage collects the structures every turn of the loop. ;;Memory : 0 (let [a (range 50000)]) ;; Memory: "big" while the let is "executing" ;;Memory : 0 -- no reference to a anymore ! 5. In the REPL, isn't it redundant to always have to type the top- level parens? not for (let :) 6. Is there a place to get guidlines on macro idioms? The feature is so powerful that it seems like it would be easy to misuse it and crack a programmers head like a nut with a badly structured macro. Try Stuart Halloway's book, Programming Clojure. I liked it, at least. 1. Isn't the world actually imperative? And mutable? Collaboration *is* a messy proposition in real life. It's hard to fix your car, and even harder to have lots of people fix your car. I find the "it models the real world better" justification for functional programming rather confusing. (Indeed, the CPU and physical memory also have an imperative relationship!) The amount of mutability depends on your level of granularity. Let's say you want to add two numbers --- if you consider all the robotic actions the arm in your hard disk must do to load the memory into the CPU, the flow of electrons in the wires, etc, then there does seem to be mutable state everywhere. But, addition itself is a pure function, so the mutable state is incidental complexity that doesn't really matter in the long run. You can tell it doesn't matter because you can change all the mutable physical stuff and it won't affect the computation. You might use an abacus, a hydraulic computer, your brain, etc, but 2 + 2 is still 4 no matter how you get there. Just as Greens Theorem can transform a surface integral into a line integral and save a lot of work, it's important to circumscribe as much mutable state as possible with abstraction barriers to make our lives simpler. 2. 'Side-effects' are treated almost as a bad word by most functional programming advocates. And yet, aren't ALL programs executed for their side-effects? Does "side effect" perhaps then require a qualification or a tighter definition? Or perhaps side-effects "aren't that bad"? What is a side effect and what isn't depends again on your level of granularity. Too many side effects is a warning of "badness" because it means that you might be working at the wrong abstraction level. Incidental mutability should be removed because it just clutters everything up, but truly necessary mutability is just fine. 3. What is the relationship between the "shape" of a clojure program and the runtime call stack? (I ask because a clojure program looks strikingly similar to the callstack of an ordinary program when you 'pause' a thread.) 4. Is it possible (and/or advisable) to introduce a typing system on top of clojure? E.g. a macro-form along the lines of (fnif type_function function args) Try out defrecord to make your own java objects. Hope you have fun, --Robert McIntyre On Mon, Dec 6, 2010 at 8:40 PM, Stuart Halloway <stuart.hallo...@gmail.com> wrote: > 1. Isn't the world actually imperative? And mutable? Collaboration > *is* a messy proposition in real life. It's hard to fix your car, and > even harder to have lots of people fix your car. I find the "it models > the real world better" justification for functional programming rather > confusing. (Indeed, the CPU and physical memory also have an > imperative relationship!) > > I think it is important not to conflate Clojure with functional programming, > since the latter is very broad. > The world is a series of immutable states, and the future is a function of > the past. > See http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. > Cheers, > Stu > > -- > 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 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
