Well I'll just say that my opinion on this matter is not well formed at the moment since this is the first time I have encountered this issue. For now I've stuck with the Java algorithm so I can move on with my project, but I do plan to revisit this at some point. In fact, it may be important for my project to keep it all Clojure.
At the moment I don't find the Clojure solution simple, but again this may simply be to lack of exposure. Have you written a lot of performance optimized Clojure? On Sunday, February 24, 2013 8:50:01 AM UTC-5, bernardH wrote: > > > > On Thursday, February 21, 2013 10:27:11 PM UTC+1, Geo wrote: >> >> Man, this is exactly how I feel after all this tinkering! It was great >> for learning Clojure a bit more in depth, but in the end I am going to >> stick with the Java solution. Especially since it's so easy to mix Java and >> Clojure in the same project! I just specify :java-source-paths ["src/java"] >> in my project.clj and I just call that one method when I need it and the >> rest of the project is in Clojure. I think when performance if critical >> idiomatic Clojure is to just drop down to Java :) >> >> Christophe's second function actually achieves Java speed or very close >> (within 5-10%), but it's ugly and there's a bit more to my algorithm which >> would make it even uglier if I were to go that route. >> >> > There would be no point in me to argue with you whether Chrispohe's > version really is "ugly" or not for you, but I'd like to rephrase it as > "hard on the eye". Because I find this "performance oriented Clojure" vs > Java fits quiet well in the "easy" vs "simple" mindeset.[*]. Adding Java > code in a Clojure project is certainly easy if you happen to already know > the language, while no amount of prior experience in idiomatic Clojure will > help you in writing perfomance oriented Clojure as it can be a completely > new idiom. But I do believe that the resulting code (as a whole, not just > the small performance critical bit of code) is simpler with two idioms in > one language than with two languages. > > FWIW, I, for one, am really glad that Clojure allows us to select > precisely which nice tools we want (have to) throw away (persistent data > structures, dynamic typing, synchronized) when the need arises. Reminds me > of the "don't pay for what you don't use" motto of C++ except done right > (i.e. the other way around, because you don't want to pay wrt simplicity > rather than performance, cf. "premature optimization…") > > Cheers, > > Bernard > > [*] https://www.youtube.com/watch?v=rI8tNMsozo0 > -- -- 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/groups/opt_out.
