On Fri, Feb 22, 2013 at 3:43 AM, Marko Topolnik <marko.topol...@gmail.com>wrote:
> > My 5-year experience with Clojure (since 0.9) hasn't helped me to see it > that way. > I've been doing Clojure for about 5 years as well. Optimizing Clojure in the early days was pretty tough stuff, and resorting to Java was pretty much necessary. Today I think Clojure does pretty well at exposing a subset of the language that is fast and no more cumbersome to write than Java (or JavaScript) when performance is key. > > >> Christophe's version also has the advantage that it can pretty much >> compile down to efficient JavaScript via ClojureScript and probably an >> efficient ClojureCLR program as well. This may or may not matter to you. >> > > In a Java project it clearly does not matter. In library code it quite > likely could matter a lot. That is of course a subject completely separate > from the discussion on the pitfalls involved in getting Clojure performance > right. > Fair enough. My point was simply that Clojure implementations have a small learnable subset that performs well when performance is desired - primitives, loops, arrays, deftypes, etc regardless of host. It's unfortunate that the host, in this case the JVM, requires quite a bit of thinking about type hints and casts. I think most of the challenges around are writing fast Clojure JVM code lie here. I note these issues are not present in ClojureScript ;) > Apparently even Cristophe broke quite a bit of sweat to come up with his > second solution, and did also wander around searching for bottlenecks (like > .equals against =). ^:unsynchronized-mutable is something I've never > layed my eyes on before and I've spent quite a bit of time working on > optimized Clojure, googling for any trick I could find. What is the most > trivially obvious way to solve a probelm in Java takes the most obscure > features of Clojure to emulate. > It's right there in the docstring of deftype, but OK. Finally, Cristophe's solution, as well as all other optimized Clojure code, > seems to be just barely making it for the use case involved. In my code, > for example, I struggle with such things as an array of Strings (received > from a Java method) failing when used in amap, which needs an array of > Objects. I'm sure I could come up with yet another layer of obscurity which > would make this work, but, as I said, after several months of struggling > I'm ready to settle for 100 lines of clean, elegant, obvious Java. > Perhaps it's because I lack considerable experience with Java that I don't find it so challenging. Yes it's a bit finicky, yes it could be improved, but it still beats writing Java in my mind. David -- -- 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.
