
Ongoing · Concur.next — Hard-Core Clojure - wglb
http://www.tbray.org/ongoing/When/200x/2009/12/15/Osborne-WF2-Clojure
======
jimbokun
Just finished reading Osborne's actual write up, and it's one of the better
tutorials I've read on how to optimize code. Write things in the simplest way,
measure, then optimize the bottle necks. We've all heard that, but here is a
very concrete example of how to do it in practice. He puts in type annotations
and fiddles with the underlying Java bits only where necessary, and wraps it
in a way that the code calling the optimized code is mostly idiomatic Clojure.

It also reflects well on the pragmatism behind Clojure's design. The type
annotations and dropping into Java, while not as pretty as pure Clojure, are
still prettier than regular Java and can be isolated to the performance hot
spots.

I appreciated this little bit of editorializing:

"The -> and doto macros save us from having to name each intermediate step and
from the unreadable nesting you’d get if you tried to do the same thing in a
typical curly-brace language.

    
    
        BufferedReader reader = new BufferedReader(new InputStreamReader(new BufferedInputStream(
                              new FileInputStream(filename).skip(startByte), 131072), "US-ASCII"));
    

Oops, FileInputStream.skip() returns a long, so that doesn’t even work. Now
who was complaining about Lisp syntax (looking (like (this)))?"

Nicely done. An informative, enjoyable read. Two thumbs up.

------
jimbokun
"OK, but a Clojure purist would probably see those occasions as maybe
highlighting gaps in that language’s coverage."

A Clojure "purist" is probably still programming Scheme. In other words,
"purist" and "Clojure" do not go well together. As Rich Hickey often says, he
is a "practitioner." He wants to Get Things Done, and Clojure reflects that.
Dropping down into Java is not "cheating," it's one of the reasons Clojure was
implemented on the JVM in the first place, and I've seen Rich recommend
calling Java code to solve a problem multiple times on the Clojure group.

~~~
icey
This is a great way to describe "The Clojure Way". I think I'm going to co-opt
this explanation for future use (I hope you don't mind).

~~~
jimbokun
Don't mind at all. Go right ahead.

------
oconnor0
I find it fascinating that this Clojure implementation is faster than the
current best Java one. I wonder how much faster a Java implementation could
be.

------
grayrest
Any experienced Clojure people care to comment on why atoms were used instead
of agents? You don't care when the counter is incremented, just that it gets
incremented, so I'd assume that an agent would model the problem more closely.
Is it an overhead thing or what?

~~~
pmjordan
Agents launch the update function in a separate thread, which seems a bit much
for incrementing a counter.

~~~
grayrest
One of these days I'll remember that agents aren't actors, just not today.

