Incidental mutability is the key. Functional programming doesn't eliminate mutability, it manages it: only the parts of the system that truly need to change state do so. Everything else is pure and easy to write and test. Contrast that with imperative programming where it's hard to tell which state changes are incidental and which are truly required. That's why Clojure provides identity objects: immutability is the default, and you have to ask for state change. That makes it a red flag that other programmers maintaining your code can observe.
Idioms should be functions or macros. That's the beauty of symbolic programming: no boilerplate. Thanks, Alyssa On Dec 6, 9:19 pm, Robert McIntyre <r...@mit.edu> wrote: > 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
