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.


Reply via email to