Re: Road to Clojure Survey

* André Thieme [2009-02-21 13:27+0100] writes:

Helmut Eller schrieb:

I also don't understand how those collections can improve concurrency
control beyond ordinary Java libraries.

Java offers low level building material.
That is used along with a STM (with MVCC) and immutable data structures.
When you have data that can not change then of course any number of
threads can use them concurrently without producing inconsistencies.
Immutability is the default in Clojure. Typically a Clojure programmer
will know how to do most things without changing state.

But if you can't always choose the data structures you'd like. If you
use Java frameworks you have to use whatever is used by those libraries.
And AFAICT, Clojure tries to use Java libraries whenever possible.

A workmate of mine now started to use it as well. At some point, when he
wanted to make use of one of the mutable constructs offered by the
implementation, I had a short look with him over his code, and we were
able to remove them.
*Of course* all CL/Java programs could be written in the same style.
But this has to happen by convention and could easily be circumvented,
by introducing a setf here or an infc there.

How is that different in Clojure? Using Clojure's data-structures
exclusively is just another form of convention. It is not enforced,
right?

Clojure makes it difficult. For example, if you want to change several
pieces of data outside of a transaction you will get an error. Refs
can only be changed in a (dosync ...) block. At least until today it
is not typical CL/Java style to write programs in such a way. One
could make the change and program the Clojure way in CL also. Although
I see no point in doing so if one wants program in that style. I would
suggest doing it in Clojure. As well one can sit down a few days and
write up an imperative lib for Clojure, with setf, push, incf and
friends and do CL style coding in Clojure. Possible yes, but why?
There already is CL waiting for me if I want to do that.

It seems to me that those
classes fall in the same category as the java.util.concurrency package.
Useful for sure, but claiming that those classes "ensure clean, correct,
multithreaded designs" seems a bit far fetched.

Concurrency is a hard problem.

Of course it is. And therefore those statements like "ensure correct
multithreaded designs" are almost certainly wrong.

This video is well worth to be watched:
http://rubyconf2008.confreaks.com/what-all-rubyist-should-know-about-threads.html

Thanks, for the link. Have to watch it later.

Yes, it is about a Ruby guy, but what he says applies to 99% of all
programming languages. Outstanding exceptions would be Clojure, Haskell
and Erlang.
Those langs also allow us to make tons of mistakes and they can not do
magic. The hard concurrency problem does not go away. But they do a good
job in making it easier.
Immutability by default, a STM (or similar mechanism) and some
corresponding abstractings/tools in the language make it possible, and
often even trivial.

Well, Erlang and Haskell live in their own isolated worlds and don't
claim to have "seamless integration with Java". I doubt that it's
possible to have easy Java interop and easy concurrency at the same
time. It's bit like saying that you can freely call C++ functions and
that there will be no segfaults.

Helmut.
.

Relevant Pages

  • Re: Road to Clojure Survey
    ... Java offers low level building material. ... Immutability is the default in Clojure. ... The hard concurrency problem does not go away. ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... Just as a point of fact, the Clojure data structures implement the ... Java, at least for any Java code that respects immutability. ... But I doubt someone could use this after having used Clojure. ... author, and more important, neither do existing algorithms defined in ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... Java, at least for any Java code that respects immutability. ... Now we get to learn solid information about Clojure from The Man Himself, all in the fun context of a modest flamewar. ... And the interface specifications ...
    (comp.lang.lisp)
  • Re: Road to Clojure Survey
    ... I am several orders of magnitude more productive with Lisp than with Java for the kinds of things I am interested in. ... Clojure, or better (if you want to do ... We will now see if functional programming can do better. ... Because Clojure has the same access to all libs that Java also has, ...
    (comp.lang.lisp)
  • Re: Clojure vs Java speed
    ... vectors in C/C++ and Java. ... The JIT can't, but the coder can. ... You cannot write code that is both that short and that efficient in Clojure. ... You are on the JVM to interoperate with Java. ...
    (comp.programming)