Matt Raible: Why is Clojure better than Scala or Groovy?
Matt Raible - Spring Expert and Java consultant posted the following entry to Twitter: Why is Clojure better than Scala or Groovy? http://twitter.com/mraible/status/7793457551 He went on to say: Let's try that again: I like Scala and Groovy and see no compelling reason to learn Clojure. Am I missing something? http://twitter.com/mraible/status/7794565786 I know that I think - but I thought the awesome community here could help answer this question. -- 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
Re: Cond, and abusing or
Hi, Am 16.01.2010 um 01:48 schrieb Scott Burson: Certainly, this is a very common idiom in Common Lisp and other older dialects. I guess there are a few people who don't like it, but a lot of us do it routinely. You'll even see stuff like (or (try-to-construct-a-foo) (error Couldn't construct a foo)) Just be aware that if a nil or false is a valid answer this approach will fail. Sincerely Meikel -- 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
Re: Creating an object given a class object
On Tue, Jan 12, 2010 at 2:50 AM, Konrad Hinsen
konrad.hin...@fastmail.net wrote:
On 11 Jan 2010, at 23:09, .Bill Smith wrote:
Every class object has a newInstance method:
user= (Class/forName java.util.HashMap)
java.util.HashMap
user= (.newInstance (Class/forName java.util.HashMap))
#HashMap {}
user=
Is that what you are looking for?
It seems close, but it doesn't work for me. From experimenting I have the
impression that this works only for constructors with no arguments.
I found some stuff in the Java docs on reflection that could work, but this
is getting very complicated... I'll first see if I can do without.
Since Clojure already does this, you can borrow its implementation,
found in clojure.lang.Reflector. In this case, see invokeConstructor.
(clojure.lang.Reflector/invokeConstructor (class (ref foo)) (to-array [42]))
= #r...@6ad3c65d: 42
Rich
--
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
Re: Compilation-aware code?
On Thu, Jan 14, 2010 at 12:22 PM, ataggart alex.tagg...@gmail.com wrote: Some people have had issues with c.c.logging in that it looks for a suitable logging implementation at macro-expansion-time (by simply trying to import the necessary classes), which thus also occurs during AOT compilation; the down-side is that if the desired logging lib is not on the classpath during compilation, the java.util.logging implementation gets selected into the compiled code. There are solutions to move this choice to runtime, though it adds some overhead to every invocation, even if the respective log level is disabled. It occurs to me it would be very nice indeed if I could provide alternate implementations depending on whether the clojure code was being executed as a .clj or an AOTC'd .class file. Knowing this would further allow the specification of env vars to influence the resulting code, e.g., telling c.c.logging that even though it's being AOTC'd, it can choose the logging impl right away since it's on the classpath (thus negating the performance hit of a runtime selection). Does anyone have a sense of whether or not this is possible already or, if not, worth doing? (doc *compile-files*) Rich -- 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
Re: Matt Raible: Why is Clojure better than Scala or Groovy?
On Fri, Jan 15, 2010 at 8:22 PM, Julian juliangam...@gmail.com wrote: Matt Raible - Spring Expert and Java consultant posted the following entry to Twitter: Why is Clojure better than Scala or Groovy? http://twitter.com/mraible/status/7793457551 He went on to say: Let's try that again: I like Scala and Groovy and see no compelling reason to learn Clojure. Am I missing something? http://twitter.com/mraible/status/7794565786 I know that I think - but I thought the awesome community here could help answer this question. I would very much like to discourage the bashing of other languages here. It is tedious and pointless. Should anyone be provoked into responding to this, please keep your comments to attributes/deficits of Clojure. Thanks, Rich -- 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
Re: Compilation-aware code?
On Jan 16, 6:17 am, Rich Hickey richhic...@gmail.com wrote: On Thu, Jan 14, 2010 at 12:22 PM, ataggart alex.tagg...@gmail.com wrote: Some people have had issues with c.c.logging in that it looks for a suitable logging implementation at macro-expansion-time (by simply trying to import the necessary classes), which thus also occurs during AOT compilation; the down-side is that if the desired logging lib is not on the classpath during compilation, the java.util.logging implementation gets selected into the compiled code. There are solutions to move this choice to runtime, though it adds some overhead to every invocation, even if the respective log level is disabled. It occurs to me it would be very nice indeed if I could provide alternate implementations depending on whether the clojure code was being executed as a .clj or an AOTC'd .class file. Knowing this would further allow the specification of env vars to influence the resulting code, e.g., telling c.c.logging that even though it's being AOTC'd, it can choose the logging impl right away since it's on the classpath (thus negating the performance hit of a runtime selection). Does anyone have a sense of whether or not this is possible already or, if not, worth doing? (doc *compile-files*) Rich Rich, why do you insist on making things simple and obvious? ;) Thanks. -- 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
Re: Many foolish questions
2010/1/15 Rayne disciplera...@gmail.com: Ignore this. ;) deftype and reify and all of that good stuff are now in the Clojure master branch. Rich pulled new into master a few days ago. Ah, good to know :) The last time I checked it was not yet in master. -- Michael Wood esiot...@gmail.com -- 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
Re: Matt Raible: Why is Clojure better than Scala or Groovy?
One third main selling point, just for you ;-) : Clojure has a rooted in it a development paradigm suited to manage state of identities over time. That is, clojure embraces the functional paradigm for most of the development process, but does not leave you naked when time comes to write those parts of your application which require dealing with state, time, concurrency, parallelism, etc. Rich's videos are particularly enlightening concerning this point: * a (mostly) clojure agnostic explanation of the problem and a general solution to it: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey * a more clojure-oriented talk which complements the above with clojure detail: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey 2010/1/16 Shantanu Kumar kumar.shant...@gmail.com: On Jan 16, 6:22 am, Julian juliangam...@gmail.com wrote: Matt Raible - Spring Expert and Java consultant posted the following entry to Twitter: Why is Clojure better than Scala or Groovy?http://twitter.com/mraible/status/7793457551 He went on to say: Let's try that again: I like Scala and Groovy and see no compelling reason to learn Clojure. Am I missing something?http://twitter.com/mraible/status/7794565786 I know that I think - but I thought the awesome community here could help answer this question. I wrote about benefits Clojure (v1.0) some time ago: http://bitumenframework.blogspot.com/2009/09/benefits-of-using-clojure-lisp-in.html The best benefit of Clojure is, I think, the power-to-weight ratio. The language is so much devoid of syntax and semantics bloat that whatever code you write in Clojure is pure productivity. Concurrency- handling makes it suitable for current-day development and as Chouser noted, the Macros feature is a game changer. Regards, Shantanu -- 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
Re: Matt Raible: Why is Clojure better than Scala or Groovy?
On Saturday 16 January 2010 18:10:15 Shantanu Kumar wrote: The best benefit of Clojure is, I think, the power-to-weight ratio. That's a really good description for a low barrier to entry. :-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e -- 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
Re: Lazy recursive walk.
For the non lazy version , maybe using clojure.zip would help not blow up the stack ? (using clojure.zip/zip + a loop with recur on clojure.zip/next) ? 2010/1/15 Nicolas Buduroi nbudu...@gmail.com: Hi, I'm still not familiar with laziness and I'm trying to make a function recursively walk arbitrary data structures to perform some action on all strings. The non-lazy version is quite easy to do: (use 'clojure.walk 'clojure.contrib.str-utils) (defn recursive-string-walk [f form] (walk #(if (string? %) (f %) (recursive-string-walk f %)) identity form)) But it blow up the stack quite rapidly, I've tried to inject some laziness inside, but only came up with a slight improvement. It can take forms that are a little more than two time as deep. (defn recursive-string-walk [f form] (walk #(cond (string? %) (f %) (seq? %) (lazy-seq (recursive-string-walk f %)) :default (recursive-string-walk f %)) identity form)) Is there a way too make a fully lazy version of this function? Thanks - budu -- 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
Re: Lazy recursive walk.
On Jan 15, 1:44 pm, Nicolas Buduroi nbudu...@gmail.com wrote: On Jan 15, 3:25 pm, Sean Devlin francoisdev...@gmail.com wrote: Did you try wrapping everything w/ a call to lazy-seq? Yes, it doesn't seem change anything. I suspect that just wrapping everything in a call to lazy-seq cannot work in this case. In the implementation of walk, the branch for handling seqs contains a 'doall', which I think will realize the entire sub-sequence at that point (while holding the head of the sub-sequence in memory too), defeating your attempts to make it lazy by wrapping the recursion. Just my suspicion...I'm still trying to get a grasp on lazy sequences myself. cheers, -tom -- 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
Re: Lazy recursive walk.
Sorry, I forgot to ask: how rapid is rapidly? Can you provide a simple example that rapidly blows the stack so we can experiment with lazy solutions? -tom On Jan 15, 1:21 pm, Nicolas Buduroi nbudu...@gmail.com wrote: But it blow up the stack quite rapidly, ... ... - budu -- 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
Re: ANN: dgraph 1.0, a dependency graph library for Clojure
On Jan 16, 4:01 am, mac markus.gustavs...@gmail.com wrote: I am just now in a situation where I have to do some swing programming and this seems like it has great potential! Since it's already version 1.0 you should put it on Clojars so that it is easier to use from leiningen or maven etc. Good call. I just put it up on Clojars: http://clojars.org/dgraph. Let me know how using dgraph works out for you. -- 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
Re: Lazy recursive walk.
On Jan 15, 1:21 pm, Nicolas Buduroi nbudu...@gmail.com wrote: Hi, I'm still not familiar with laziness and I'm trying to make a function recursively walk arbitrary data structures to perform some action on all strings. The non-lazy version is quite easy to do: (use 'clojure.walk 'clojure.contrib.str-utils) (defn recursive-string-walk [f form] (walk #(if (string? %) (f %) (recursive-string-walk f %)) identity form)) - budu One more thought (sorry, I'm having too much fun with this problem) I notice that since walk does not traverse anything except collective data types, your recursive-string-walk will not call the function f on just a string argument: user= (recursive-string-walk reverse hello) hello This, of course, may be exactly the behavior that you desire, but a version which handles strings might be useful for a string walking function: (defn rsw [f form] (if (string? form) (f form) (walk (partial rsw f) identity form) ) ) Unfortunately, this is also non-lazy and will probably still blow your stack. :) -tom -- 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
