Hi, 2009/7/7 Chouser <chou...@gmail.com>: > > On Tue, Jul 7, 2009 at 8:08 AM, Roman > Roelofsen<roman.roelof...@googlemail.com> wrote: >> >> (0 until 100) map (_ * 2) filter (_ % 3 == 0) >> >> I can easily read this line from left to right (just like english) and >> instantly see whats going on. By contrast, I have to read the clojure >> version a couple of times to understand it: >> >> (filter #(= 0 (rem % 3)) (map #(* 2 %) (range 100))) >> >> Is this just a matter of pratice? Do you find it easy to read the >> clojure version? > > Practice, yes. It often helps if you try to not get too > much detail out of the initial left-to-right read, but > instead just a sense of what's going on. Something like > "filter something from a map over a range". Now you know > where you're headed, and can read inside-out (or > right-to-left) for the details. > > FWIW, I think it takes less knowledge to read most Clojure > snippets. As with most syntaxy languages, that Scala > example requires knowledge of precedence rules, grouping > rules, etc. > >> Also, would it make sense to have a function like this: >> >> (apply-chain (range 100) (map #(* 2 %)) (filter #(= 0 (rem % 3)))) > > Perhaps. The idea has certainly been kicked around some. > http://groups.google.com/group/clojure/browse_thread/thread/66ff0b89229be894/2e206c645c2c34e2 > >> * Parametrization of "function groups" * > (snip) >> >> Currently I can think of 2 approaches to implement this in clojure: >> >> a) Each function also defines a database parameter >> The downside is that the caller needs to fill in the value every time. >> >> b) The function invocation needs be part of something else, e.g. (do- >> with-db "mydbname" (db-write) (db-read) ... ). >> Here, the caller still needs to be aware of this setting. > > (a) is most like OO, and a perfectly valid option. Instead > of mydb.read(x) the user would call (db-read mydb x) -- same > args, just bit different order. > > (b) is also reasonable, and not an option in most OO > languages. This allows you to mention mydb once for a whole > group of calls to db-* functions. The same functions could > even allow both -- (db-read x) with one arg would use > *the-db* and (db-read mydb x) with two args would use mydb. > >> * Real-world macros * >> >> Correct me if I am wrong, but it seems that people often use macros >> for lazy evaluation of parameters. In Scala, it is quite easy to >> accomplish the same via by-name parameters. E.g. >> >> def maybe(lazyarg: => Unit) = if (...) lazyarg >> >> lazyarg will be evaluated in the if clause, not when the method >> 'maybe' gets invoked. I know that macros in clojure are much more >> powerful. But what are selling points in pratice? What is a unique >> feature of clojure's macro that you don't want to miss? > > Lazy args are an approachable example, but probably not my > main usage of macros. If that's all you want, 'delay' might > be a better option. > > I use macros anytime I have patterns in my code that I want > to factor out but for which functions are insufficient. > I know that's a bit vague, but I'm not sure how else to > generalize it.
Higher order functions, multimethods, etc. are already doing a great job of making Design Patterns (as per "the gang of four") a non issue in clojure. And macros can be seen as the ultimate tool to help remove the extra boiler plate, making the last x % of Design Patterns (note I wrote x and not xx, since I guess most Design Patterns issues will be solved by just using higher order functions and multimethods, so x is probably < 10%) vanishing as well. I'm still not using clojure on a daily basis at work, but one of the promises one can also get from a lisp is this real opportunity to endlessly build abstraction levels over abstraction levels, without the need to quit the language and switch to new ones. Ultimately, one could entirely get rid of all those UML *editors* + XSLT/Velocity,etc. XMI-to-Java transformers just to have the "big picture" expressed in an hypothetically more readable and maintainable "high level language" (UML graphics). With clojure, you could still find values in UML *viewers* by automating the creation of "high level pictures" of your code. But stay with one language (clojure) for high level and low level parts of your application. -- Laurent --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
